[sakai2-tcc] Thoughts on 2.9.1 schedule

[Matthew Jones]

Back a year ago (01-2012) on the technical side of the release after
Anthony left when we started 2.9 we had ~1 FTE/wk from Michigan, ~1 FTE/wk
from IU, ~0.50 FTE/wk from Longsight actively involved in the release.
 (2.0-2.5 FTE/wk). Noah, Gonzalo, Chris and Greg were all involved from
Michigan and IU.

Today there is ~0.50-1.0 FTE/wk from Longsight,, ~0? from Michigan and
~0.25/wk FTE from IU. (0.75-1.25 FTE/wk)

This doesn't consider effort on 2.8, which I'd say is currently ~100% Steve
even though we're supposed to be officially supporting it. 2.8 hasn't come
up at the release meetings in the last few months. I don't know how much
time Steve spends per week. Ideally we wanted to look back at 2.8 after 2.9
was in good shape but 2.9 has still kept us busy even 2-3 months after
release.

This also doesn't consider the non-technical effort of Neal or anyone else
spends on managing jira, confluence, or the sending of long emails.

I'm not going to come right out and say it but I agree that it is a major
issue. I don't see Sam or I being "re-tasked" through 2.9 and Longsight
will support the 2.9 release with the current process for the foreseeable
future, but makes no guarantees of release effort beyond 2.9. I believe
that keeping up with everything in maintenance releases is achievable with
around the current effort but keeping up with a new release (2.10) a
previous release (2.8) and improving the process is a lot of time that is
risky to count on volunteer effort exclusively for.

On Tue, Jan 22, 2013 at 7:02 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

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