[sakai2-tcc] Thoughts on 2.9.1 schedule

[Matthew Jones]

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/20130122/f8a7aef9/attachment.html