Re: Bits from the Release Team - Kicking off Wheezy
Hi Raphaël,
On Wed, Apr 13, 2011 at 08:50:04AM +0200, Raphael Hertzog wrote:
> On Sun, 10 Apr 2011, sean finney wrote:
> > My suggestion/feedback would be that we find a way where releases aren't
> > managed so linearly, and can be be handled in a more parallel manner
> > without such disruptive stoppage in unstable.
>
> +1 I also mentionned this in my feedback mail (although much more
> quickly/shortly).
>
> > I've been mulling this idea over quite a bit, but with all the CUT
> > discussions I've been hesitant to bring it up because it's sort of
> > taking things in a different direction.
>
> Why are you thinking this? On the contrary, this is something that was
> suggested to implement the "rolling" distribution. I would very much like
> to form a group of developers ready to put some work towards this goal.
> And I would be glad if you could be part of it.
I was only 50% at the last DebConf and missed the CUT BoF, but thought
reading blogposts etc afterwards that people weren't as focused on the
"branch out stable" approach that I'm talking about, and rather were
more interested in stuff like "snapshot testing", "alternative testing
from unstable", etc). But I could be mistaken.
> > * create new release
> > * instead of freeze, "branch" testing to new release
> > * testing is now release+1 and continues to be fed by unstable[1]
> > * use release-proposed-updates for uploader-targeted changes earlier than
> > usual.
> > * -release team can use $tool[2] to "merge"/"cherry-pick" collecitons
> > of source packages (rebuild+version bump) and/or binary packages
> > (no change).
> While I think this is the long-term goal, it might be more sensible
> to start with rolling and testing in parallel. And I also think it
> requires us to become involved in release matters and to develop
> new tools to streamline the process.
In the way I had thought of things, "rolling" == "testing". That's to
say that nextstable branches off the main line of development, gets it's
own staging area for updates, and the testing/unstable duo function just as
they did before. So from what I see we would need the nextstable-testing
area, plugged into the autobuild system, and an independant instance of
the release infrastructure as a starting point.
But either way, i agree tools and processes would need to be hammered
out well in advance, to show that the idea works in practice as well
as principle. But one of the benefits I see for how I'm proposing
things is that since it doesn't involve any fundamental changes in how
the rest of the project works[1]. It would be very easy to do several
"dry run"/"mock" releases where we improve tools/processes and explore
the problem further.
> > I guess the real concern here is whether there's enough person-power to handle
> > the extra work/overhead.
>
> And also whether release-proposed-updates is workable earlier in the cycle
> as the release manager like to pick updates from unstable because it gives
> some good prior-testing that release-proposed-updates might not provide.
They shouldd still be able to pull from testing/unstable as well, until
it gets to the point that their own freeze criteria prevents them from
migrating in packages. So that's the same as before. But being parallel
and all, the delta (and thus likelihood of such conflicts) will by design
grow faster and earlier than it currently does. Thus the exceptional
case of needing -p-u becomes less exceptional. So any potential solution
would need to address making that easier to manage as well as ensuring
that there's sufficient people using the p-u/nextstable-testing area.
I don't think I've heard anything back from anyone who's actually on
the release team regarding this, but if they were at least non-comittedly
open to the idea, I'd be willing to throw my hat into the ring to help
put something together.
sean
[1] maybe modulo solving the problem of getting better test coverage on
the nextstable-testing area, if we can't find a good solution for
that, which I'd hope we could.
Reply to: