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

[Anthony Whyte]

> . . . If that means moving to github and working via that model, then so be it. 


https://github.com/arwhyte/octocat-cle

Noah and Steve have already had a look at the above, but others may enjoy the bit of fun I had imagining what a single CLE Github repo might look like.

Anth



On Jun 1, 2013, at 3:29 PM, Steve Swinsburg wrote:

> 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
> 
> _______________________________________________
> 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/20130601/4d938b97/attachment.html