Re: Suggestion: Skip Slink!
In article <[🔎] Pine.LNX.3.96.990104143207.6311A-100000@leocadia> you wrote:
: The decision to develop Potato while Slink was still unreleased was a major
: mistake.
I think you're making a common conceptual mistake here.
: (i.e. decide never to start a new unstable until stable is out the door)
By definition, *all* development happens in the unstable tree. If it's called
"potato" now instead of "slink", that's irrelevant.
The problem is *not* that work has continued on adding new functionality to
the unstable tree since the slink freeze. The problem is that the process by
which we enact a "freeze", producing a "release candidate" is *ludicrous*. It
essentially guarantees that each release candidate is as far from being ready
for release as possible!
The current process involves picking a date on which to make a copy of the
current "unstable" tree and declare that it is feature frozen and on the way
to release. This just doesn't make sense, and guarantees that the process of
going from the point of freeze to the point of release will be long,
frustrating, and contentious.
I made a relatively thorough proposal for a different approach to handling
the migrate of a package from an unstable-by-definition upload to a released
state a while back. There was some discussion, and a number of counter
proposals and aggregations of thought. Unfortunately, most of this
discussion focussed on implementation details, and missed my fundamental
premise. Let me try to state it again as plainly as I can.
Any upload of a package is, by definition, "unstable" until proven
otherwise.
Therefore, uploads should *always* go into the unstable tree.
The process by which a package is "promoted" from unstable
through one or more stages until it becomes part of a stable release
needs to involve consistency checking, testing, and enough time
elapsed to allow confidence to build in the package.
The promotion criteria should include a guarantee that the release
candidate never has dependency issues, never has a package version
with a truly "release critical" bug known at the time of promotion,
and so forth. Those characteristics will always be part of the
unstable tree... but should *only* be part of the unstable tree!
Some of my previous email details the side-effects of this premise, and
proposes one set of ideas on how to implement this.
: People may not be talking about Debian in these terms in the mainstream
: press, but I think the eyes of a lot of people are watching to see if Debian
: can come up with regular releases in these first tentative months. Since the
: adoption of the constitution, there has not been a single stable release. I
: don't mean that as a criticism, but I think that, more important than X
: 3.3.3, more important than linux 2.2.0, is Debian itself. Will it prove
: itself capable of creating usable releases, or will it just become a domain
: of hackers and be left behind when the world switches to linux?
Don't make the common mistake of assuming that Debian is a single homogenous
group of individuals with a completely common set of goals. I'd think that
anyone who watched our -devel list for a few days would realize that just
isn't so. :-)
There is room in Debian for us to have folks working their hardest to package
new software and new revisions of existing packages as fast as they can. There
is room for folks to dedicate themselves to porting across architectures.
There is room for folks to dedicate themselves to testing and release
management. If we're willing to rework our package management processes, we
can keep these groups from stumbling over each other... as they do today.
Bdale
Reply to: