[sakai2-tcc] Moving forward with releases

Wed Nov 9 19:25:44 PST 2011

Comments inline!

On Wed, Nov 9, 2011 at 6:02 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> <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
>
>
I think umich *was* doing some 2.7 branch management over the summer. I
know Indiana was doing it last year. I don't know anyone specifically named
to either 2.7 or 2.8 branch management though and Anthony was doing most of
it. I think there were 1-2 people that were going to be involve in 2.9
after it was actually branched. Maybe they can fill in for some of the 2.7
or 2.8 work.

> 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.
>

Yea, ideally we would be there for sure. Sakai has a big problem right now
as I see it. (Please correct if I'm mistaken) More and more things got
pulled off into indies, but they are not really *indies*. They aren't
because they really needed shared dependencies (specifically in the
components) but I don't see anywhere in the components loader where it
includes any shared directories. [1] In Tomcat 5 (and the pattern that
weren't retaining for 7) the pattern was that system/common and shared were
"shared" directories for webapps, so it seems like at *least* common and
system should also be shared to components. [2] This seems like it would
allow us to rely on the log4j and kernel-util being in shared.

Horwitz said back at one time that we couldn't have kernel-util in shared
because of the DB classes but never explained why. It seems like getting it
out or not relying on it really needs to happen somehow.

That way, an indie can (in theory) be built off of the "lowest" version of
purepoms that it's compatible with and it will be forward compatible with
all other versions of Sakai.

Otherwise we'll have to have crazy stuff like
lessonbuilder-2.9.x
lessonbuilder.2.8.x
lessonbuilder.2.7.x

Which is something I don't want, it's something that nobody wants. We want
lessonbuilder-1.3.x and we want it to work in sakai 2.8, 2.9. 2.10 whatever
and packaged up. As release managers, we don't want to re-release every
indie when we cut a new alpha or change the kernel. The kernel is a shared
piece that's (in theory) backward compatible. Yea, sometimes the api in
interfaces change and it a bummer, even more so when they're backported to
minor releases, like when a new method was added by SAK-18838.

I want indies to work like you're describing, but it seems like we're at
the point where if we *don't* do indies like we all want then we're better
off just making everything point back to base (or the combined master and
base) and release it all as one big 2.6 style chunk.

What would we need to do to avoid this?
1) Either get kernel-util out of components into shared, or just say we
don't care if kernel-util is a completely different version.
2) Keep track of the minimum compatible pure-poms version of each tool and
release indies against that
3) It seems like if tools wanted to take advantage of new features they
would need to reflect or wrap the old features.
4) I dunno what to do about the interface changes, but I remember reading
about some pattern ideas that seemed good?

Thanks for getting the discussion started, Steve! ;)

[1]
https://source.sakaiproject.org/svn/kernel/trunk/component-manager/src/main/java/org/sakaiproject/util/ComponentsLoader.java
[2] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html

> 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 <http://unc.edu/>unc.educopying 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>
> 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
>
>
>
> _______________________________________________
> 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/20111109/d3df49bf/attachment.html 