[Building Sakai] 2.8.x kernel version
Adrian Fish
a.fish at lancaster.ac.uk
Tue Aug 16 07:16:02 PDT 2011
Thanks for the in depth clarification Anth. Useful for everybody running
.x releases I'd say.
Cheers,
Adrian.
On 16/08/2011 15:03, Anthony Whyte wrote:
> 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
>> <mailto: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 <mailto: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
>>>>> <mailto: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
>>>>> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org>
>>>>> with a subject of "unsubscribe"
>>>>>
>>>>> _______________________________________________
>>>>> sakai-dev mailing list
>>>>> sakai-dev at collab.sakaiproject.org
>>>>> <mailto: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
>>>>> <mailto: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 <mailto: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 <mailto:sakai-dev at collab.sakaiproject.org>
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email tosakai-dev-unsubscribe at collab.sakaiproject.org <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"
>>>
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org <mailto:sakai-dev at collab.sakaiproject.org>
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email tosakai-dev-unsubscribe at collab.sakaiproject.org <mailto: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 <mailto: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
>> <mailto: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
>> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a
>> subject of "unsubscribe"
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110816/a7c8dc0d/attachment.html
More information about the sakai-dev
mailing list