[Building Sakai] 2.8.x kernel version

Tue Aug 16 07:03:28 PDT 2011

Adrian has every right to enquire.  We had a couple issues with the latest kernel releases and rather than leave 2.7.x/2.8.x relying on them we chose to bind to a snapshot.  A kernel snapshot is actually a rather stable creature; David and I serve as kernel branch managers and our approach to kernel branch management is conservative.  Mistakes do occur and occasionally a regression slips in.  This has occurred as we ramp up for the 2.7.2 and 2.8.1 releases.

But as David has pointed out it, maintenance branches operate in a snapshot state--only tags represent stable artifacts.  Of course, stability of the latter presumes that sufficient QA has been injected into the release process; at present we are challenged in this area. 

Now for some pedantic paragraphs.  :)

The majority of CLE project maintenance branches (core/contrib) such as those for announcements, assignments, osp, rwiki etc. do not depend on stable versioned artifacts in the repo (indeed, they don't exist).  Code can be merged to these branches at any time and is usually done so without prior warning to deployers.  These branches evolve over time, some at a glacial pace, others rather more quickly.  Whether or not one regards such branches as "stable" depends on the level of trust that one has both for the maintaining team and for the level of QA that each bug fix merged to a maintenance branch receives.  Nevertheless, they remain SNAPSHOT in nature and should be approached as such.

Both 2.7.x and 2.8.x include dependencies on "indie" projects such as the kernel, msgcntr, profile2, samigo, etc.  Not counting the kernel snapshot dependency at present (an anomalous situation) the master pom of each maintenance branch points to stable "indie" binaries that reside in our repo.  

From a stability standpoint this suggests goodness but in practice it means that we are handling indies differently than other CLE projects--fixes destined for maintenance branches require an explicit non-snapshot release, an extra set of steps that is absent currently from the bulk of CLE projects where fixes can be merged to their maintenance branches at any time and are available via svn update.  

Moreover, the stability and usefulness of the indie binaries released depends crucially on the QA each release receives--an area that, as I hinted above, we are in need of a rethink as regards practices.

From a consistency standpoint, we should actually be pointing our 2.7.x and 2.8.x master poms to indie maintenance branch snapshots; these can be refreshed by Jenkins after polling for new code commits.  We will need to create new jobs to generate maintenance branch snapshot artifacts for some indies--a simple task.  One advantage of doing this is that indie fixes will be available quicker than is currently the case.  But quicker can have its downside.

Cheers,

Anth

On Aug 16, 2011, at 9:35 AM, Bryan Holladay wrote:

> I think it's a good conversation to have... not pedantic.  With the TCC allowing minor feature's into maintenance branches and the occasional bug fixes that require API changes, there are situations that come up where pointing to a non maintenance kernel branch doesn't work.  The current solution seems to be:  add the fix to kernel, release a new kernel, then add the fix to the ".x" branch for that tool.  This is just a lot of work, but luckily doesn't need to happen often.
> 
> -Bryan
> 
> On Tue, Aug 16, 2011 at 9:28 AM, Adrian Fish <a.fish at lancaster.ac.uk> wrote:
> I've never managed to catch a SNAPSHOT kernel in a 2.8.x update before, hence my asking. The perceived stability of the .x branches comes from the fact that bug fixes are supposed to be the only things that go in. That used to be the case anyway.
> 
> I feel like I'm being pedantic now; that isn't my intention.
> 
> Cheers,
> Adrian.
> 
> 
> On 16/08/2011 14:15, David Horwitz wrote:
>> 
>> Well the whole branch is a SNAPSHOT and by definition not stable - the tag is. While we're conservative about what goes into branches       they do change ...
>> 
>> D
>> 
>> On 08/16/2011 03:11 PM, Adrian Fish wrote:
>>> 
>>> The advantage is that whenever you take a 2.8.x update, you can have faith in its stability. Snapshots are developmental snapshots and by implication potentially buggy.
>>> 
>>> Cheers,
>>> Adrian.
>>> 
>>> On 16/08/2011 13:34, Bryan Holladay wrote:
>>>> 
>>>> Is there an advantage of having a maintenance branch depend on a stable kernel?  There's obviously a disadvantage.
>>>> 
>>>> -Bryan
>>>> 
>>>> On Mon, Aug 15, 2011 at 7:51 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>>>> Yup, the issue arises when a fix goes in to the kernel, which a tool then depends on. Previously the kernel being deployed with the branch was a stable release, but things then got out of sync as the tools in the branch had the fix but the deployed kernel did not. Hence the snapshot.
>>>> 
>>>> cheers,
>>>> Steve
>>>> 
>>>> 
>>>> On 16/08/2011, at 1:25 AM, David Horwitz wrote:
>>>> 
>>>> > There's been a bit of instability as we head towards the 2.8.1 tag -
>>>> > hence the branch binding to snapshot (seing the branch is itself a
>>>> > snapshot this is not wholly unexpected).  There should be a kernel
>>>> > release shortly at which point the branch will merge to that
>>>> >
>>>> > D
>>>> >
>>>> > On 08/15/2011 05:22 PM, Adrian Fish wrote:
>>>> >> I've just updated my 2.8.x source and it's pulling the 1.2.5-SNAPSHOT
>>>> >> kernel.
>>>> >>
>>>> >> Is that right? Should the stable 2.8.x be pulling a developmental kernel?
>>>> >>
>>>> >> Cheers,
>>>> >>
>>>> >> Adrian.
>>>> >>
>>>> > _______________________________________________
>>>> > sakai-dev mailing list
>>>> > sakai-dev at collab.sakaiproject.org
>>>> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>> >
>>>> > TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>> 
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>> 
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>> 
>>> 
>>> -- 
>>> ==================================
>>> Adrian Fish
>>> Software Engineer
>>> Centre for e-Science
>>> Bowland Tower South C Floor
>>> Lancaster University
>>> Lancaster
>>> LA1 4YW
>>> email: a.fish at lancaster.ac.uk
>>> 
>>> http://confluence.sakaiproject.org/display/YAFT/Yaft
>>> http://confluence.sakaiproject.org/display/CLOG/Home
>>> http://confluence.sakaiproject.org/display/BBB/Home
>>> 
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> 
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> -- 
> ==================================
> Adrian Fish
> Software Engineer
> Centre for e-Science
> Bowland Tower South C Floor
> Lancaster University
> Lancaster
> LA1 4YW
> email: a.fish at lancaster.ac.uk
> 
> http://confluence.sakaiproject.org/display/YAFT/Yaft
> http://confluence.sakaiproject.org/display/CLOG/Home
> http://confluence.sakaiproject.org/display/BBB/Home
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110816/1eacc0aa/attachment.html 