Re: Bits from the Release Team - Kicking off Wheezy
Hi!
(accumulated replies FTW)
On Fri, Apr 29, 2011 at 11:20:31PM +0200, Andreas Barth wrote:
> > * unstable always feeds to testing
> > * "release N" == "testing", until the "freeze".
>
> You know that we had once "frozen", and have given up since as that
> didn't scale even back then?
I think it has already been pointed out at some point that it's not a
complete analog. Specifically (AIUI), way back then, "frozen" was
basically a snapshot of unstable, with all the bugs problems, etc.
Indeed, it was a large part of the motivation for having testing in the
first place.
What most of the proposals here are suggesting is that we have something
similar, but based off of a "testing" snapshot instead.
> This concept needs double or tripple man power from what we currently
> have. That's the show-stopper.
I don't totally agree with that estimate but as I've pointed out before
it *will* be more work, just lke maintaining two branches in a VCS instead
of one would be. Additionally, the proposal would suggest that:
* much of the extra work could be done by the package maintainers themselves.
* much of the additional overhead could be automated/scripted.
Whether it actually *could* is of course another question, but that's
why it's part of a hypothesis.
On Fri, Apr 29, 2011 at 11:48:53PM +0200, Andreas Barth wrote:
> On the other hand, the entry barier into the release team isn't too
> high. If someone is willing to work e.g. only on encouraging packages
> fixing important bugs to testing faster, please get in contact with
> one of the release managers (or me), and we can certainly arrange
> something in the interesst of all.
>
> But just making more mess in testing for PR reasons doesn't sound like
> a good idea to me.
I don't think it's for PR reasons. It's because currently, when Debian
is in the middle of forming it's rock-solid stable release, EVERYTHING ELSE
slows down too. When AJT introduced testing he referred to it as a
"sludgey" alternative to frozen, but when the entire project is sludgey
for extended periods of time, it affects the number of fun and innovative
things happening in Debian. I'm a big proponent of the "when it's ready"
camp, but also think we could come up with a way that lowers the collateral
damage to other parts of the project.
On Fri, Apr 29, 2011 at 11:22:54PM +0200, Andreas Barth wrote:
> I don't think the plan is straightforward, but just "not working".
> It's easy to write down things that other people need to do - but that
> won't work.
>
> Please show the man power necessary to get your plan implemented -
> otherwise, all is moot.
As I've said before, I'm willing to do more than throw popcorn from
the armchair here :) My biggest hesitation for rolling up my sleeves
and getting right at it is that I wasn't sure whether it would fall on
deaf ears and be a collossal waste of time. And note that I'm not
pinning "waste of time" to "accept/reject" for the proposal--I think this
is a very intresting experiment, and regardless of the outcome we'd
probaly walk away with some new ideas/tools/questions.
To kinda put my money where my mouth is, I'd be willing to sign up as
some kind of release assistant, helping with the current release processes
while working on this proposal.
On Fri, Apr 29, 2011 at 06:50:04PM -0400, Michael Gilbert wrote:
> Actions speak a whole lot loader than words and design by committee is
> unlikely to get you anywhere. And a GR (as mentioned in your blog
>
> So, really what I'm saying is just go for it. Prove that its
> something worthwhile so the project has a basis for adopting it.
I think the best way forward at this point is something along those lines.
I'll take out a DEP for starters, so we can have authoritative place
with a "project plan" (i.e. not scattered across ML's and blog posts).
sean
--
Reply to: