[sakai2-tcc] Thoughts on 2.9.1 schedule

[Steve Swinsburg]

> As I've said often in the past, Longsight runs the 2.9.x branch. We have interest in contributing time back for our clients toward specific ticket QA and merge/branch process, but really have no need to ever see a 2.9.1 or future numbered release (other than 2.10). It's a nice milestone for the community but no local value. And each release actually causes us *more* local effort because I have to go update master and update the versions of all customized indie tools for all our clients. 

You've just outlined a major issue in the release process. If one day Longsight sees no value in continuing the 2.9 releases, or if you or Sam are retasked to a different area, then there is a real risk that releases wont continue. We should never be in a position where we are totally reliant on a commercial organisation to donate time and money - priorities change and thats just business.

Which is why I strongly feel that the task of the releases needs to be owned by the Foundation. The code can be maintained by the community as it is now, and troops rallied for bug fixes, QA, and merging, but the actual releases should be done by Foundation staff.

cheers,
S


On 23/01/2013, at 2:01 AM, Matthew Jones <matthew at longsight.com> wrote:

> The only staff currently paid by the foundation for CLE is Neal, and he was hired specifically for a community coordinator role. Anthony also performed this role, but over time picked up more technical roles both because he (seemed to be) interested in them and because nobody else was consistently doing it then.  If Neal were to pick up these technical tasks he would need training (likely from one of us? any other volunteers?) and considerable practice before he could take it over. There could also potentially be time funded to an SCA to guarantee that these roles are fulfilled. This is what I wanted during the hiring process, but others on the TCC were less interested in. Like Neal said, taking time from one thing (in his case coordination/communication) to put on branch management is a trade-off. And my time (and others) spent on technical aspects of release management is time that could be spent fixing bugs and getting contributed community patches (of which there are many) into Sakai. Trade offs for everything!
> 
> And I agree, svn merging is occasionally easy (if there's no conflicts) but often either requires you to pass the issue back to the developer or spend time resolving conflicts. The actual release process, even if it wasn't complicated by Jenkins, Maven and occasional svn reverse merges or commits also has some complexity.
> 
> For 2.9 the only consistent branch manager right now is Sam with Greg occasionally picking up merges. (We're around 20 issues behind merging so not a huge amount of issues)
> For 2.8 you (Steve) are the only person I know of that does merging regularly with Sam occasionally doing merges when needed by Longsight.
> 
> Most of the tools that have project teams don't even do their own merging.
> 
> I agree about too much time on the emails, but from threads like this (and even your reply) there is a misunderstanding in the TCC about what actually goes on with the release, who actually does the work and who is (or more likely isn't) getting things done.
> 
> As I've said often in the past, Longsight runs the 2.9.x branch. We have interest in contributing time back for our clients toward specific ticket QA and merge/branch process, but really have no need to ever see a 2.9.1 or future numbered release (other than 2.10). It's a nice milestone for the community but no local value. And each release actually causes us *more* local effort because I have to go update master and update the versions of all customized indie tools for all our clients. If the api's in master were a constant 2 digit version (2.9) then this wouldn't happen as master wouldn't update every release. Though I'll still fire off a 2.9.1 when the the CLE Release Team says it's good to go is right because survey says 50% of people care about the numbered release. 
> 
> I think if we just distributed 2.9.x-2013-01-21-bin.tgz it would be just as useful to anyone running binaries or demos. Sakai is too big and complex that I don't think we'll ever see a time where 2.9.1 is *guaranteed* more reliable than 2.9.1 + 1 week. The only usefulness I can see of the version is to have something static to put in jira affects/fixed version fields.
> 
> On Mon, Jan 21, 2013 at 6:03 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> No, I haven't done a lot for the 2.9 release, and I apologise for that and muchas gracias to those that have. But it seems to me that the release process is still far too complex and time consuming that no one wants to commit to doing it. And thats fair enough for volunteers. But we have paid staff and I believe the release role needs to be undertaken by those staff. 
> 
> This was what Peter Knoop did and what Anthony Whyte did. We had a separate group of branch managers to handle the merges, and if things weren't getting merged, we'd get an email from Peter or Anthony to do it. Anthony also did branch merging (maybe Peter as well) but thats because his SVN mojo is strong. 
> 
> SVN merging is complex, especially if there are conflicts and you need to go into the code to see whats going on. So I'd prefer that merging is left to those that know the code. Releasing is just pushing buttons and maybe running some commands - but its a time consuming part and I'd much rather donate my limited time to fixing code than pushing buttons.
> 
> Summary:
> * Branch managers merge fixes (though project teams should handle their own branches).
> * Neal coordinates QA people and does the release and communication.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130123/35d43010/attachment-0001.html