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
try.
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
freeze.
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
period.
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
that.
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
freeze?
> > 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: