Build streams; preparing for 8.2 release.

[Dennis Gilmore]

On Thursday 12 June 2008, Chris Ball wrote:
> Hi Dennis,
>
>    > from your initial email: Stable: Stable builds are specified by
>    > their release name (e.g. 8.1.1,   8.2), and the procedure for
>    > packages moving from Testing into Stable   releases involves the
>    > Unscheduled Release Process:    
>    > http://wiki.laptop.org/go/Unscheduled_software_release_process
>    >
>    > that indicate you intend to move updates from a F-9 base to a F-7
>    > base.  I dont know how else to read it.  if im wrong please tell me
>    > how i should interpret it.
>
> The interpretation should be that we'll have an F-9 base in testing, and
> then we'll make a release called, say, 8.2 that contains that build.
> For the release after that, we'll have an F-10 base in testing, and
> then we'll make a build called 8.3 that contains that.  There is no
> overlap between the 8.2 stable build and the 8.3 stable build; they're
> independent.
>
> Perhaps you're having trouble because you're imagining "stable" as
> existing permanently, rather than once per release.  Stable is just a
> symlink to the latest build that made it out of testing into a named
> release.  There would never be a reason to have stable be a different
> base to the testing build that it came from.

so what happens when we have 2 or stable releases to support.  how do i get 
updates into the older ones?  this is the workflow that i am envisioning.  

>    > We constantly seem to be having the debian does it this way so lets
>    > do it that way discussion. rather than asking how fedora does it.
>
> I don't think we're borrowing anything from Debian other than the names
> "unstable", "testing" and "stable".  We aren't giving them the meanings
> that Debian assigns to those names.  We aren't proposing any
> modification of our build process, even, except for a separate build
> that takes changes less regularly than Joyride so that it can have
> stronger change control.

I don't have an issue with the naming.  its is the fact that we will have 
multiple stable releases to support.  and I don't see how we can do that with 
the proposed format.   to me  and i feel like i'm on the outside here. it 
looks like we have taken the workflow that debian has and said we will do the 
same. 

>    > If we find the fedora way to be lacking then we should work to
>    > improve that.  if it means looking at how Debian does it and saying
>    > thats much better then so be it.  but lets not make it the first
>    > choice.  We should work to improve the fedora process for all of
>    > fedora's users derivatives.
>
> I don't know of a "Fedora way" (or a "Debian way") for creating a
> separate build stream for testing at a slower rate than Rawhide; let me
> know if there is.  It sounds like you're chiefly upset that we're using
> the unstable/testing/stable nomenclature.  I don't much care about what
> we call them; feel free to propose alternate names if it would make you
> happier.

the workflow i'm envisioning releases will be similar to the way that fedora 
unity releases update respins.  in that when we fork from the development 
tree.  we have a series of releases to stabalise the builds.  but we will 
continue development for that branch at a much slower pace.  fixing bugs  
etc.  we will then do periodic spins from it.  

The main difference to what you proposed and what i.m proposing is that we 
will be supporting  multiple stable branches. and some adjustments in 
workflow to accommodate those changes.

We should talk about this tuesday afternoon when im there in person.  It will 
be the only time that i am in the office next week.  The rest of my the week 
ill be doing things for fudcon.  I will be in 1cc 23rd-27th

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080612/e192f941/attachment.sig>