[sakai2-tcc] Proposal: release Sakai 2.9.0 on Friday, November 9 barring any new blockers (Voting now open)

[Matthew Jones]

Replies inline!

On Tue, Nov 6, 2012 at 7:02 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

>
> The release early, release often is more about getting bugs fixed, getting
> individual jiras verified, getting fixes merged into the 2.9.x branches and
> getting all of the changes documented. All of this effort aside from Neal
> is volunteered by the community and some weeks seem to have more time from
> the community than others. The release team will need to determine what
> criteria for making a 2.9.1 release. As of now, everything we expect to
> have in a release (that was verified and ready to merge) is in the release.
> I don't know of anything anyone is sitting on waiting in the wings to
> immediately merge for 2.9.1, but we'll find out.
>
>
> A while back we talked about releases being timed, ie every quarter,
> though that might introduce issues if we cant get testing resources.
>
> Totally agree that we need to draw the line somewhere, cut a release and
> move onwards so its out there and people. Otherwise we end up in the
> situation that was alluded to earlier, where people are running the
> maintenance branches instead of tags, because the tags are few and far
> between and they can get fixes faster in a branch. That means that actually
> making releases is a waste of time since no one uses them. That should be
> reversed so that people are confident to run tags and the community knows
> when they will be coming.
>

Timed, expected releases sound like a good idea, though schools inside and
outside the US have different timings. US schools generally will want to do
major upgrades between the semesters, typically Fall and Winter (Around the
last 2 weeks of December) or Summer and Fall (Around the last 2 weeks of
August). Anytime between May and August is usually good too because of
significantly lower usage. In the past releases have been during or right
before the summer.

2.6.0 - July 2009
2.7.0 - June 2010
2.8.0 - April 2011
2.9.0 - November 2012

This release might have made the summer as well if either Anthony wasn't
moved off the project or a replacement for him. Neal didn't start working
until August and had a lot to catch up on. Perhaps this also signals a
different cycle of releases from yearly releases that don't change much to
large releases every year and a half, with much smaller more frequent
maintenance releases than existed in the past. I think this is something
we'll have to discuss. Based on the survey Aaron sent out a few months ago,
the split between schools running 2.7 (or earlier) and 2.8 (or later) was
*nearly* 50/50. So the upgrade schedule at schools was generally about 2
years anyway. Many of the bigger contributing schools were still running
2.7 (or earlier).

I certainly don't see there being enough content for a 2.10.0 by next
summer though overall. Though some true indies, some like Lessons or
BasicLTI may have a newer version included in a minor release if
progress continues to move forward on them.

>  Re this:
>>
>> Also the actual release process (from branch management, to cutting
>> releases) is almost entirely just Sam and myself which is far from ideal.
>> In the past, Anthony helped out significantly with this, and ideally Neal
>> would be able to assist, but it still feels like this *could* be a few
>> months from happening. I'm planning on spending a day or two in North
>> Carolina next week with Neal and Aaron to start on some of the more
>> technical aspects of the release process. These were the 3-6 month goals
>> the TCC initially set out in the CLECC onboarding.
>>
>>
>> Could we discuss those on list before anything is implemented? I think we
>> rushed though parts of the changes for 2.9 which ended up causing some
>> problems early on. It could be streamlined, definitely.
>>
>
> Discuss what specifically?
>
>
> Any technical aspects that might need to occur.
>

We had published and discussed Neal's onboarding goals among the TCC. The
aspects I'm referring to are part of the 6 month plan. These include.

- Backup for Branch Managers
- Backup for Release Managers
- Backup for Version Control
- Addtional Techincal QA

I don't believe that Neal has much experience with some of the Sakai
basics, bringing up a server on a clean database, setting properties,
checking database tables. Or about how to apply patches and rebuild/update
code to test out fixes. It would have helped Longsight as well as the
community to have someone else involved in this effort that wasn't subject
to local distractions.

>  I don't believe anything substantial would change for the 2.9 process
> but it would be useful to have someone else involved in merging and
> releasing indies.
>
>
> I used to do a lot of this. Merging, easy. Releasing, I have absolutely no
> idea how to do that now. Is the guide still relevant/up to date?
>

I know you were involved quite a bit for the 2.8 release, the 2.9 is
completely different as it uses Jenkins to build, release and deploy all of
the indies to Sonatype. It was rocky going for a few releases, but the last
release went perfect. There are still occasional network problem that
occur, and sometimes the builds server locks up for some reason, and
occasionally there's a pom issue that's only tested during release that can
break everything. But if there's no technical problems then it's generally
pretty smooth. I'd be up for walking some people through this process via
Skype or in person sometime, it's generally about an hour 2 two one day,
then an hour or 2 the next day, but I follow the guide for each release.

https://confluence.sakaiproject.org/display/REL/Sakai+CLE+release+guide

I believe after the release is out, that indies (contrib especially) will
release without using the process. I'd setup a few indies like Delegated
Access on here, so all someone has to do is fill in the version numbers and
hit "Release" and it will release a new tag of that tool. That will be more
of what it would be nice to have people involved in. It's more getting
people with reoccurring available time (at least 5-10 hours a week)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20121107/aced2d70/attachment.html