[sakai2-tcc] Moving forward with releases

Wed Nov 9 15:02:06 PST 2011

<Taking this to a new thread since it needs discussion>

Who do we have in branch management roles for both the 2.7 and 2.8 branches? I am hoping to finish all of the merges for 2.8 today:
https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12536

I won't be able to do 2.7, but there are only 31 outstanding resolved issues that have the merge flag set for a 2.7 merge:
https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12212

Now, something that really needs discussion is how these releases are performed. It should not take two days to learn a process simply to push out a release. It should be as simple as pushing a button, running a script or using Jenkins.

At least half of the modules are indie releases and more are coming online as indies all the time. Project teams should be making their own releases of these tools. They should also be making their own branch merges for fixes. Assuming that is all done, then all it takes is picking the correct version to include in the release and updating the master pom. If that is *not* done then it makes the branch management task monstrous, fixes get stale and difficult to merge and regressions occur.

That brings me to the pom setup. I see no reason why master pom and the base pom should not be combined. Then we have only one pom that needs to be kept up to date.

The master pom is then updated with the stable versions of all of the artifacts, and the release (and all of the source modules) tagged using the Maven release plugin.

More on poms: each module should be adjusted so they they use versions for dependencies from properties, rather than explicitly listing them in their poms. I noticed yesterday that site-manage is now using commons lang 3 (which has a package change too) yet commons lang 2.5 is in shared. Why? There is no need for that. The particular fix used a class from commons-lang that had been around for ages.

I think we need some rules/guidelines for developers around the use of Maven (and how they push their own releases) to make CLE releases easier.

Finally, does anyone know what is happening with QA? 

thanks,
Steve

On 10/11/2011, at 1:30 AM, Noah Botimer wrote:

> Sam,
> 
> I think you are absolutely right. I still contend that having a majority of the community running unmodified branches at different points indicates a real need for more releases. It's even worse if it's hard enough to bundle local releases that people have to vendor drop huge chunks of code. It's even worse if they are vendor dropping old stuff simply because newer releases haven't been announced.
> 
> You are also quite right to point out that we have to stand on our own, with at most a pointer here and there from Anthony. It's also right to set priorities. The branches could really stand to be released and the release process could really stand to be improved. But these should not stop each other -- we just need to pick what's most important and do it first. If it's so hard to do it current way, maybe the cleanup happens first, but I've got to believe that someone(s) issuing a release in the standing way would result in a more predictable release and better insight into what should be refactored.
> 
> So, in the interest of being clear, here is what I think needs to be done (and I do understand that offering plans without resources only goes so far):
> 
>  * Find someone who can be guaranteed for the uninterrupted time (I think two days is a good guess but maybe low)
>  * Release 2.8.2
>  * Release 2.7.3
>  * Secure another bit of guaranteed (ideally for a couple of people) to plan/try refactoring for a 2.9 alpha, to take advantage of the QA sanity check that would not be available for a maintenance release. 
>  * If it goes well for a couple of 2.9 alpha releases, apply it to 2.8 and 2.7 (at least once, to catch up before 2.9 final and synchronize everything in case more are needed).
> 
> Thanks,
> -Noah
> 
> On Nov 9, 2011, at 8:52 AM, Sam Ottenhoff <ottenhoff at longsight.com> wrote:
> 
>> We need this for maintenance branches that are still active. Where is
>> the current 2.9 documentation? Could Anthony help with differences in
>> current maintenance branches?
>> 
>> -1 for announcing 1-month old 2.8.1 and 2-months old 2.7.2
>> 
>> 
>> +1 for pushing 2.8.1 and 2.7.2 out the door ASAP.  2.8.1 is a significantly better release than 2.8.0, and we are reducing our chances of growing our community when new members are still reaching to 2.8.0 as our best release.  When I see big schools like unc.edu copying 2.8.0 to their msub it bums me out, because it seems inevitable that they will run into the same bugs we have been fixing for the past several months.  2.8.0 has some *severe* deficiencies including Email Archive and Citation Helper being completely broken (!), Announcements with three large regressions, and Samigo with a list of fixes including a security fix.
>> 
>> If you are new to the Sakai community, you should not be using Sakai 2.8.0.  
>> 
>> Anthony is longer available for CLE tasks.  He graciously worked until 2am one night to push out 2.8.1 and 2.7.2 in his non-OAE time.  We can no longer lean on Anthony to do another release for us because this announcement is one month old.  Anthony seems plenty willing to help out with growing our capacity, so if there are people who have questions about the release process, I am sure he will help out.
>> 
>> Pushing out a 2.8.2 is not easy, and if someone is up for learning the process, we will probably need two full days of that person's uninterrupted time to learn the process, release all of the indies, release the core, write new release notes, document the changes, *and* test the release.  
>> 
>> Part of the difficulty of transitioning to a community-supported release is that community members have various responsibilities and local responsibilities always take precedence.  Anthony was a gigantic part of keeping CLE releases running smoothly for many years and without those dedicated resources from the Foundation, cranking out releases is going to be a lot harder until we can simplify the process.
>> 
>> Here are Anthony's notes on generating a Sakai 2.x release:
>> 
>>   https://confluence.sakaiproject.org/display/~arwhyte/Generating+a+Sakai+CLE+2.x+release
>> 
>> +1 on announcement #2.
>> 
>> --Sam
>> _______________________________________________
>> 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/20111110/6f47a195/attachment-0001.html 