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

[Noah Botimer]

Some interesting ideas in there for repackaging to be sure. I worry a little about Maven maintenance, but by not squashing modules, it amounts to adjusting only parent paths and module lists for aggregator POMs. It's a relatively cheap reorg.

No judgment on what is the best long-range plan, but here is another idea/test I've done in Github:

https://github.com/botimer/sakai-cle

This repository is effectively a mirror of trunk-all. In fact, I use an SVN working copy and a Git working copy in the same folders so I can continue to synchronize rather easily. Note that master/src never gets fresh commits, only syncs from SVN.

I can attest that this pattern has worked well for me over the past four months, keeping the Spring upgrades in sync to trunk. It was a beautiful thing when the commit went in. I even took a pull request (thanks, Zach!).

I ended up using an svn diff and patch on a separate sparse working copy before merge, but that was so everything could be in a single commit, rather than across every external.

By sparse working copy, I mean using `svn co --depth empty` at the root, and `svn up --depth empty` at the modules tracked by the externals, and `svn up --set-depth infinity` on the trunk for each module. This does not use the externals and gives a unified working copy that offers some nice options... But it's really a hack around our externals anti-pattern.

Thanks,
-Noah

On Jun 1, 2013, at 9:08 PM, Anthony Whyte wrote:

> 
>> . . . 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/89f4948a/attachment-0001.html