Re: Bits from the Release Team - Kicking off Wheezy
On Thu, 28 Apr 2011, Stefano Zacchiroli wrote:
> We might disagree with the process Raphael is proposing, but my reading
> of [1] is that he is asking for comments on the *goals* that, in his
> opinion, "rolling" is supposed to fulfill. We can discuss whether those
> goals are worthwhile or not even if there is no plan (yet) on how to
> implement them. Of course people might consider that a futile exercise,
> but from an investigative point of view, it looks like an interesting
> exercise to me.
Ack. Besides that, the plan is relatively straightforward and has been
well described by Sean Finney in another answer here.
Furthermore, I don't want to come up with a proposal where the release
team just says "yes" or "no". I have outlined the goal to have a
distribution that never freezes and I would like the release team
to be involved in the design of the solution because no matter
how we do it, it will have an impact on the release process and I
would really prefer to have some buy-in from the release team.
That's not to say that I want the current members of the release
team to implement this, I am willing to join the team (or create a
sub-team dedicated to rolling/CUT) and put the required effort to make
this a reality. But I would like to do it with the approval of the current
members.
On Wed, 27 Apr 2011, Mehdi Dogguy wrote:
> For example: What would be Rolling's content right after a release?
> (comparing to testing, which starts from the stable just released). I
Rolling doesn't magically change after a release. It's still the result of
the migration of packages from unstable into it.
I said in my blog post[1] that testing is "branched-off from rolling".
This means:
- rolling is the long-lasting distribution where packages migrate
from unstable
- 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
- testing is really a temporary distribution that has a purpose only
during freeze, if you use "testing" when there's no freeze you're
just using "stable" because the testing symlink is still pointing
to the distribution that has been released now
> guess you cannot merge because testng will be lagging behind a bit. You
> cannot just get what's in testing and restart from fresh, because there
> might be users that won't like it. If you continue, there will be no
> relation with testing anymore. The two suites will have their own set of
> problems, I guess.
I guess I should not haved called "testing" the distribution forked
from rolling. This caused some confusion.
Really you must think of rolling as being the current testing with no
possibility to freeze it.
On Wed, 27 Apr 2011, Philipp Kern wrote:
> 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
> 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.
>
> 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.)
Yes, all this is true.
If the release team is open to try this out, I'm volunteering
to help implement this (i.e. at the very least managing transitions
while the rest of the release team is concentrated on patch review for
finalizing the stable release). I'am also happy to invest some effort
on updating our infrastructure to cope better with some of the problems
that we will face. And also on writing documentation to make it easier
to recruit new volunteers.
That said I think we can changes some of our processe to reduce the load
on the shoulders of the release team. More on this later.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: