[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Faster Release Cycle = More Up to date Packages...

Thank you Joey for being so obliging to a constructive proposal, and 
thank you for your polite way of replying to my proposal.

Do you think you could put your 6 year old attitude aside for a few 
moments and take this as a contructive proposal as other normal 
grownups would do?

If you think I have my facts wrong and/or miss information upon which 
I can base my proposal, I would like you to point me to the sources 
of the information I miss.
I have spent some time trying to find all the information I could, 
from web pages and mailing lists, but obviously there is information 
I did not find.

> Johnny Ernst Nielsen wrote:
> > Debian's current problem with old packages can be seen by the
> > fact that a number of vendors have reportedly dumped the current
> > Stable release in favor of the Testing distribution some time
> > ago. That can only mean that currentness of content has become
> > more important than bugs, security and stability.
> > It means that Debian is not in balance with currentness of
> > contents. Debian can not continue down that path without
> > compromising Debians own policy of supporting its users.
> So someone was more interesed in currency than in stability, and
> they swiched from the debian tree that emphases the later to the
> tree that emphasises the former. And what was the problem again?

I am not sure I can explain this in an understandable way, but I will 
The problem seems to be that publicly Debian only supports Stable.
I do not disaggree with this. We can not support both Stable, Testing 
and Unstable.
Thus, vendors that want Debian support must use Stable.
However, the vendors' users are requesting more up to date software 
than what Stable provides.
So vendors are currently trapped between using a Debian distribution 
users find too old, or using a Debian distribution for which there is 
no support.
It all falls back on what the users want.

Have you forgotten point 4 in the Debian Social Contract?
"Our Priorities are Our Users and Free Software"

We are not giving priority to our users if they request up to date 
software and we do not provide that in the only distribution we 
publically support.

> > The package currentness issue is controlled by an other issue:
> > - How long the period of a freeze lasts before all RC bugs are
> > fixed.
> Wrong. You would do well to make sure you're fully up-to-date on
> how debian's release process is currently handled before posting
> half-baked critisism of it. A casual persusual of the last 10
> months or so of postings to debian-devel-announce might be a useful
> first step.

I am as up-to-date on the Debian release process as I have been able 
to make myself, and I do not bake.
Furthermore, I do not critisise Debians release procedure. I happen 
to like it, at least what I know about it so far.
I did not recognize any release process information in either the 
debian-policy mailing list, the debian-devel mailing list, or the 
debian-devel-announce mailing list. Neither did i find such 
information searching the Debian web site, nor reading the Debian 
Policy Manual.
The only information I found was in the Developer's Reference, 
Section 5.6.1.
It basically says that when the Release Manager thinks it is time to 
freeze, Testing freezes. Nice and simple. It gives the impression 
that Testing stops accepting packages from Unstable all together, 
perhaps unless a package from Unstable will fix a RC bug.
As you indicate a bit further below that does not seem to be the way 
the real world process works.

I have done all the searching I can.
Someone need to point me to the information you obviously know 
exists, but which I can't find.
Otherwise I will continue to make bad cakes, to your huge annoyance.

> > The main proposal is to introduce a fixed short Testing
> > development period into the development cycle like this:
> >
> > 1. Feed Unstable packages to Testing for a fixed short period of
> > time.
> So you think that dumping a large number of upstream updates of
> packages into testing in a very short period of time will result in
> a better integrated and less buggy debian. I see.

No. You either do not understand my point, or I phrase my point in 
the wrong way.

I did not propose a "dump". Perhaps the word "feed" was the wrong one 
to use.
I proposed that Testing accepts packages from Unstable according to 
our current rules, but only do so for 3 months, essentially forcing a 
freeze after 3 months.

About "dumping".
The "dumping" I see is the number of Unstable packages that acumulate 
in front of Testing's door while it is closed while Testing is in 
When Testing is released and a new Testing is put behind the door, 
then when the door is opened for a new round of Testing development, 
all the acumulated Unstable packages will fall through the door.

Isn't that exactly what happens today?

The only difference I see between what happens today, and what would 
happen according to my proposal, is that the "dump" of packages from 
Unstable into Testing would be a smaller number of packages with my 
proposal. Simply because a limited time allows a limited set of 
Unstable packages to acumulate. It is all in the lenght of the freeze 
Today, when the new Testing opens for contributions from Unstable 
(after 3.0 is released) there will be about 6 months worth of 
packages waiting in Unstable that will "dump" into Testing from 
Unstable right away.
If the previous freeze period had been only 3 months, as I suggest it 
could be, there would be only 3 months worth of packages that would 
"dump" into Testing. And thus there should be only 3 months worth of 
bugs introduced into Testing as opposed to 6 months worth of bugs.
We can not avoid a "dump" after a release, unless we also stop 
Unstable development during Testing freeze. We are not going to do 
But we should be able to reduce the size of the "dump", that is, the 
total number of packages, that "dump" into Testing when it reopens 
after a release.

Aside from that, we should also be able to limit the number of 
Unstable packages that go from Unstable to Testing during Testing's 
development period, simply by reducing testing's development period.

Show me the facts that prove these principles wrong.

> > For the sake of examples, I could imagine the Testing development
> > period being defined to last for 3 months.
> As, for example, it was planned to be in between the releases of
> hamm and potato, IIRC. And we know how well that worked.

I was not part of Debian back then, and I did not come accross the 
information you imply here on my search for information.
Do you have some mail references to the archives you could give me, 
or some documents you could point me to?

So, between Hamm and Potato there was a rule that 3 months after Hamm 
released, Potato had to freeze?

> > Introducing a fixed short development period for Testing
> > automatically reduces the time between Stable releases.
> > Limiting the time during which Testing is able to recieve RC bugs
> > from Unstable (the Testing development period), should reduce the
> > number of RC bugs in Testing, and thus shorten the freeze time.
> Here's something to think about. Base has been frozen for 8 months,
> tasks + standard have been quasi-frozen for several months, and yet
> we are still getting new release critical bugs filed on those
> sections of the distribution, on a daily basis. Why do you think
> that might be?

One reason could be that nothing is ever perfect. No matter how much 
you test, when a new combination is tried a new bug may be uncovered. 
That is not so strange.
New code has to be written to fix a bug. When new code is introduced 
there is automatically a risc that the new code introduces a new bug.
That is not so strange either.
There is nothing we can do about that. That is part of the bug fixing 
nature of things.
However, the fewer bugs there are to start with, the fewer bugs there 
are to fix. The fewe bugs there are to fix, the less new code has to 
be written. The less new code that has to be written, the fewer new 
bugs will be introduced.

You write "quasi-frozen".
It implies that some sections are only half frozen, still allowing 
new packages to be contributed.
I did not find information about the legality of that during my 
information search.
Could you tell me where I can see the rules about freezing and 
testing and what sections may accept new packages when during a 

> > a lot of time for RC bugs to get from Unstable to Testing, thus
> > prolonging the resulting Woody Testing freeze, thus adding to the
> > age of the packages in Stable 3.0. They will be about 6 months
> > old at the time of release (half a year).
> The versions of mozilla and X in testing are not 6 months old.

Which shows me once again that I did not find all the information I 
needed about the freezing and testing rules and procedures, when I 
searched for them.

I hope for a more polite and helpful response the next time around.

Best regards
Johnny Ernst Nielsen :o)

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: