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

RE: My first message... more of a mad mans rant...



<snip>
>My topics were..
>1) Lets try a version of Debian Etch without the binary firmware

Go for it. If it is something you want to see, then there is nothing
stopping you from trying.

<snip>
>3) Lets try a medium ground between stable and testing.

Why? I don't really see your point.

>From my perspective on what you have said in your email, I think this is
a really bad idea.

We all know how it works right now, but let's just go and follow the
logic of the current release method.

The journey begins in Sid (Unstable). After a predefined and well
regulated set of criteria are matched we get Testing. When testing has
gotten to the point of a good release, the code base is frozen and we
get Release Candidates. After the kinks are worked out in the RC's we
move on to Stable and when the life cycle runs again we end up in
oldstable. 

What you are proposing is that packages move from Unstable, to a Testing
alpha package, then to Testing which would be the basis of the RC's, and
then onward to Stable.

But what has that gotten us besides an extra layer of hassle for the
developers? What new criteria and standards will be required to make the
move from testing alpha to testing beta? You say "no major
block/crash-like problems", but isn't that what Testing is for already?

>From my understanding, Testing was and is never meant to be an 'always
usable always working' OS. Testing is for /testing/ purposes. Stable is
for production. If you want to run /Testing/ on a "production" system
then you are on your own. If you want a stable environment, use stable!
If you need packages in testing, then risk having things in a bit of
turmoil.

I understand completely the need for packages that are in testing and
may not be in stable. I have a certain server that I was unable to build
with Debian Stable as there were too many conflicts with the 64bit
drivers in Stable. So I built the server with Testing. I have to be much
more careful with that system when I do upgrades because I can't afford
to be happy-go-lucky with it. However, I have another system that was
explicitly built for upgrading and updating Testing to /test packages
before deploying them/. Quite the idea, I know. Too bad I can't claim
credit for it. :-) 

Trust me, I understand how frustrating things can be when Testing
breaks. Yet, I just don't see the solution in maintaining another level
of packages that may or may not break within testing. From your email it
sounds like you think it will be a simple extra package layer, but from
my understanding of how things work in Debian...I think it is going to
be a lot of work to implement and maintain. Then again, I am not one of
the big developers who knows the complete ins and outs of the process so
maybe I am wrong.

Personally, I would feel bad for the developers who would be forced to
upkeep an unstable, a testing alpha (may or may not break), a testing
(may or may not break), and a stable release version. It would be like
having a version of testing as a perpetual Release Candidate. I don't
really care to wish that on the developers.

I would like to see a well standardized release system. I think that is
one thing that Mark Shuttleworth is doing right over at Ubuntu. I
personally think that a 6mo release cycle is a bit much, however, would
it be really difficult to pick a date once a year and just state
something like "Every August 1rst testing is frozen and a release will
be made by the end of September!"? That way the time frame between
stable releases isn't absurd and everyone knows when they need to have
their code in place. It isn't an arbitrary date that developers may or
may not be aware of.

Again, this is my opinion, but I think that would be much easier on the
developers then a perpetual RC and I am all in favor of making the lives
easier for the developers.

If I completely misunderstood you, please correct me. I just don't see
your suggestion as just a simple extra package to maintain.

Just MHO.
Chris Stackpole


Reply to: