Re: Bits from the Release Team - Kicking off Wheezy
Hi guys,
On Wed, Apr 27, 2011 at 08:23:33PM +0000, Philipp Kern wrote:
> > * RM's can still choose to migrate packages from (not frozen) testing as
> > long as it's practical to do so.
> > * When deps/transitions/etc prevent testing migration, "release N
> > proposed updates" is used for one-off bin-NMU's and/or sourceful backports.
>
> So this requires people to coordinate and finish transitions in parallel to a
> massive load of patch review. And even better we can't even cherry-pick from
> unstable or testing anymore because it got broken through transitions. binNMUs
It does introduce problems, yes, but any parallel solution will. However
I think having a "release N p-u" available for maintainer uploads
will also make it easier to distribute the load away from the RM's and back
to the maintainers.
> are even more fun because then your version in release N proposed updates
> is higher than what's in new testing, which means that it should be propagated
> from p-u to testing which breaks because it would miss the libraries for which
> it got binNMUed in the first place. Which means in turn that you need to
> binNMU into release N p-u and binNMU again with a higher version into testing.
Ugly, yes, but I don't think it would be impossible to abstract away any
new manual overhead with some scripting (i.e. have a script that prepares
both binNMU's)
We would also probaly want to have some kinda early-warning system to catch
cases where manual RM/maintainer error has introduced this versioning problem,
but that ought not to be too difficult to put together.
> The whole thing only seems doable if you add a *lot* more people to the
> relevant points in the process. (And yes, new testing would require transition
> hand-holding from unstable to it as usual.)
I agree that it's more work (as any parallel development will be), but I do think that (a) we ought to be able to reduce overhead significantly, and (b) we would make it easier for package maintainers to support the release *and* get their shiny stuff in unstable.
On Thu, Apr 28, 2011 at 10:48:26AM +0100, Simon McVittie wrote:
> On Thu, 28 Apr 2011 at 11:29:28 +0200, Raphael Hertzog wrote:
> > - at freeze time, instead of freezing rolling, we make a snapshot of
> > rolling (I call it testing) and this is where we do the work left
> > to make it ready for release
>
> So your "testing" is essentially the pre-2000 "frozen" distribution [1], and
> your "rolling" is basically the current "testing" without the need to freeze?
> If that's the case, calling the distributions unstable/testing/frozen/stable
> might make everyone less confused :-)
I think that's what I was getting at as well, though I've been trying to
use these ugly-but-more-clear "quoted" terms.
On Thu, Apr 28, 2011 at 10:43:02AM +0000, Philipp Kern wrote:
> As said forcing is rarely used. It's still the tool to get the next release
> done, as Adam said. Those two goals, given that the next release ought to
> be usable, aren't conflicting that much. Freezing testing and having
> current software in unstable and testing are conflicting somewhat with the
> current tools, though.
>
> (And indeed it's about getting the old frozen back and uploading there
> directly. And regarding your "I'd help with transitions", we'd also need
> people who do the uploads to release p-u together with casing the builds for
> it.)
About getting "frozen" back in place: I want to emphasize that this is
something that would be very easy to start playing with, since it doesn't
put any requirements on how the rest of debian should work. We could
actually dry-run entire release cycles, leaving testing running as it is,
develop better tools for dealing with some of the more burdensome
problems, etc. When done, lift off and nuke the "branched releases"
and autobuilders from orbit. lather, rinse, repeat.
and regarding the uploads: Like I suggested above I think you'll get
a lot (not all, sure, but a lot) of that for free from the maintainers
themselves, since there is a clear and encouraged way to do so.
On Thu, Apr 28, 2011 at 02:55:31PM +0200, Raphael Hertzog wrote:
> Good. I just want to point out that "frozen" built on top on rolling
> (which is what we're proposing here) is different from "frozen" built on
> top of unstable (which is what we had before the introduction of testing).
Or more clearly: frozen built on top of the next release, after it is
snapshotted/branched, you mean, right?
> On Thu, 28 Apr 2011, Philipp Kern wrote:
> We just need to be clear that it's on a best-effort basis and that if
> there are conflicts between supporting stable and supporting rolling,
> stable will have the priority.
Yes. And I'd like to say I'm not against leaving the option open for the
RM's to take action in testing/unstable during a release if it's deemed
necessary, but that we could have another way that we could use in preference
to that--leaving it as more of an exceptional option rather than the default.
On Thu, Apr 28, 2011 at 03:52:28PM +0200, Raphael Hertzog wrote:
> Still, since you seem to insist, here are ideas I'd like to investigate:
Those are indeed good ideas, but i agree that it'll distract from the
current discussion if we try to roll them in :)
On Thu, Apr 28, 2011 at 08:03:32PM +0200, Lucas Nussbaum wrote:
> On 28/04/11 at 12:05 -0400, Joey Hess wrote:
> > And at the same time, having a non-frozen rolling release available
> > during freeze time could easily distract people from working on
> > testing/frozen at all, because a shiny rolling release that they and
> > some users can use is still available. I am unhappy during the current
> > choke point of testing being frozen, but that choke point does serve as
> > an incentive for the whole project to work in the same direction: toward
> > actually getting a good stable release out.
>
> That's not true. It serves as an incentive for a large number of DDs to
> just do something else until the freeze is over and they can start
> working on their packages again. (easy to show by looking at the number
> of distinct uploaders over time, for example).
+1 fwiw.
Whew. So where does this leave things? It's not entirely clear to me
whether release team members are against or just skeptical-but-open-to the
idea. If the latter case, I think the best thing to do would be to formalize
the proposal (DEP maybe?), set up the test archives/autobuilds, and get
right to it. Worst case scenario it would be some wasted effort on our
part, and the release team decides to stick to things, maybe a few
bugs/tools could be kept as a consolation prize. But alternatively the
work might pay off for big improvements Wheezy or Wheezy+1.
sean
--
Reply to: