Re: Debian decides to adopt time-based release freezes
>> Disappointing to see such an announcement without any prior discussion on=20
> I'm disappointed by the decision, the timing and the process.
> I'm especially dissapointed about the "we freeze after less than a year
> of open unstable".
I agree. For myself it would mean i can stop nearly any project for the
archive we have running currently, as all of them have the risk of
breaking something and needing time to fix it up. No source v3, no
debtags, no splitted Descriptions, all can go away thanks to this.
IMO it would have been much wiser to chose next December for the first
freeze, that would leave everyone enough time for their projects and not
cut them all away with the short remaining time.
> This is not something that should be done only by the release team
> without a broad discussion amongst the developers, unless the relaese
> team wants to do it them selves without cooperation from the package
> maintainers.
Here I disagree, even if I hate the way this is announced.
The Debian project did empower the Release Team to manage our
releases. We did not tell them "Manage the release by exactly following
whatever we did in the past". So they are entirely free to chose the way
a release is done.
What I agree with is that the whole announcement of this went out in the
uttermost stupid way that was possible to achieve. This is not to blame
the press team, its their job to send out such stuff when someone in
Debian approaches them and gives them useful content. The blame for this
is entirely on the Release Team which should have learned from prior
mistakes (like mine, hello DD levels).
A much better way of handling this would have been to have the
discussion during their DebConf session and then going to
debian-release@l.d.o and presenting it there. "Here, this is what we
intend to do, please comment, it will be released to the public soon".
(And fuck the press thats too dumb and takes "news" out of random
project lists).
> If we are going to do a yearly release, we need to announce it to the
> developers more than 5 months before freeze. Too many people have too
> many plans.
I agree.
> We also need to coordinate such things with the larger packaging teams
> to see wether it fits their schedules and their upstream
> schedules. For example from a KDE point of view, it is around teh
> worst time.
Well. If the announcement happens a year before (or more), then there is
nothing much needed. Freezes are to be expected and a timeline longer
than this would be ok.
> And what happened to "when it is ready" ?
Its the freeze, not the release. I doubt that this is thrown out, but it
is attached to the release, not freeze.
> I'm considering how we can get this decision undone. Anyone up for
> helping with that?
I object, but feel free to if you really must.
As I already said the Release Team *does* have the power to take such
decisions. If you go on with a GR you effectively take away this
power. Not that good an idea IMO.
Also, as we empowered them to do releases and finding the best way to do
them is one of their tasks - lets try this. If it doesn't work out,
heck, we can always change our minds.
I disagree with the "we announced it, we can't change our mind". Thats
wrong. We can tell people "Hey, we tested it, it doesn't work for us, we
are now going this other road".
Though I really suggest the release team to go and think about dropping
the freeze this December, but making it next one. *PLEASE* keep the
system open for development a bit longer. Thanks.
On 11826 March 1977, Luk Claes wrote:
> Who would you like to propose a release cycle to the project if not the
> Release Team?
This wasn't a proposal, this was a full fledged announcement and
decision. A proposal looks *much* different than a post to -announce.
> To be clear the Release Team cannot just decide what the release cycle
> will be, though we proposed a plan in the team's keynote at DebConf and
> the plan was welcomed by the audience. There were some important
> considerations though.
So, having like 20 (or a hundred) people within one talk room made this
the announce? Uh.
>> If we are going to do a yearly release, we need to announce it to the
>> developers more than 5 months before freeze. Too many people have too
>> many plans.
> We do not plan to do a yearly release, we plan to have a release about
> every 2 years while having a one time exception for next release by
> freezing this December.
Please reconsider this and move the freeze a year later. A freeze this
december *does* block about aall interesting things that we would want
to happen in squeeze. Squeeze wouldnt be more than a lenny+0.8 release
then. And thats really nothing *I* would love to attach my name too.
>> I'm considering how we can get this decision undone. Anyone up for
>> helping with that?
> Very constructive... what plan do you have in mind that will be shared
> by the Release Team and the project as a whole?
Sorry, but this style of announce unfortunately asked for such replies.
>> The text was coordinated within the entire press team, our release
>> masters, the head of the technical commitee and the DPL.
> So that's the new secret cabal taking our decisions?
The release team, and the other people mentioned are hardly a secret
cabal. Don't be ridiculous.
On 11826 March 1977, Sandro Tosi wrote:
> bullshit! we are trading quality for what? We release when it's ready,
> not when the clock ticks. it's completely a non-sense, and it's
> generating only bad feelings in developers and users.
It would be so nice if people could simply behave and keep civil
discussion tone.
On 11826 March 1977, Marc Haber wrote:
> I do sincerely hope that there will be a GR to overrule this decision.
I do sincerely hope noone is that stupid yet.
--
bye, Joerg
00:00:11 <LupusE> goebelmeier: http://ftp-master.debian.org/new.html <-
warum steht hier 'mplayer'? ist das eine whishlist?
Reply to: