[sakai2-tcc] Proposal for scrapping the indies and improving the release process

[Steve Swinsburg]

Hi Noah,

Thanks for the feedback. Yes indeed there remains much more to be done. I
think combining everything into a single trunk is a good move, we just need
to work through some of the issues around how it might work.

For common and edu-services for example, both being indies, I wonder if
they should be split back out again, and back into their respective
projects?

Totally restructuring the source layout is also an option, but also has
issues with how people use msub and pull in fixes and copies of various
tools.

Whatever strategy we choose I think we need to remain committed and make it
long term.

As part of this I'd also like to see code review come to fruition. If that
means moving to github and working via that model, then so be it.

cheers,
Steve




On Sun, Jun 2, 2013 at 3:29 AM, Noah Botimer <botimer at umich.edu> wrote:

> Steve,
>
> Thank you for writing this up in document form. It is very helpful to have
> the background, problem definition, and proposed solutions presented in a
> consistent way.
>
> I think much of what you have proposed aims us in the right direction but
> I do have a couple of things in mind that worry me in that they could be a
> half-step where we want a full step.
>
> For example, adjusting the top-level POM and externals to build everything
> solves the confusion of a split source/binary build, but stops short of
> rationalizing the actual working copy layout. I consider our status quo (68
> externals) a malignant side effect of historically conflating a few goals
> (per-project commit rights and dependencies, mix-and-match installations,
> and a single build-and-deploy tool/command). This doesn't make your
> proposal a bad one at all, but I do want to think through the assumptions
> or patterns we want to uphold or reject (as they serve or harm our goals as
> a project).
>
> Consider the gradual migration of things to common and edu-services for an
> example of something that made perfect sense to those doing it, but was
> confusing and arbitrary to those just building, all to a somewhat nebulous
> and incremental architectural goal. It may be that, for example, combining
> everything in the release into a single trunk serves the community best
> moving forward, if we excuse ourselves from the historical status quo.
>
> I don't think a bunch of bullet-point debate in an email thread will shed
> much light right now, so I plan to follow your lead and pull together my
> thoughts in long form. I'll try to focus on the contextual forces and
> continuum of options we have (deficiencies, goals, and
> minimal-to-comprehensive reform).
>
> This is a great document. Thanks again for getting us rolling.
>
> Thanks,
> -Noah
>
> On May 31, 2013, at 8:06 PM, Steve Swinsburg <steve.swinsburg at gmail.com>
> wrote:
>
> > Hi all,
> >
> > Based on a number of discussions over the past few months I have drawn
> up a proposal for scrapping the indies and improving the release process
> overall.
> >
> > It is lengthy, but I thought it was helpful to paint the entire picture
> as to why this is necessary.
> >
> > I believe this is on the agenda for discussion at the TCC meeting. Have
> a good conference!
> >
> > regards,
> > Steve
> >
> >
> > <cle-release-process-proposal.pdf>
> > _______________________________________________
> > sakai2-tcc mailing list
> > sakai2-tcc at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130602/cba64e87/attachment.html