RFC: ideas on Restructering the dist
Last week, I posted some ideas to debian-private, however, it seems to have
been read widely, as not a lot of people have responded to it, and the
people that have, have mostly been about the language used. I am therefore
resending it, however, this time to debian-devel (which is probably more
appropriate). I have included some of the language changes that were
proposed on debian-private in this document, and have made some other
changes in the Q/A areas. When it comes to version numbering, don't infer
anything from what I say about major/minor # releases, that just's the
lanugage I'm using, this scheme can fit into our release/revision scheme.[1]
Also, as I'm now posting this to debian-devel, please cc: any responses to
me as well, spotter@kby.netmedia.net.il, as I only get debian-devel-digest,
and it will be much easier for me to reply to messages directly cc'd to me.
So without further ado
-----
Shaya's thoughts on restructering the way debian views it's distributions.
1) "Stable" and "Unstable" (what I will call in the future, "development")
should be decoupled from each other.
Q. How do I expect to acheive this?
A. Right now we have to dists, "stable" and "unstable". I reccomend
changing "unstable"'s name to "Development", and create a new dist,
"unstable" totally rethinking what we use it for.
so we have.
STABLE, This will remain the same as it is now, a well tested system.
UNSTABLE, This will be only used for minor # releases, and it will only
act as an update to the original major release, i.e. with bug
fixes and fresh code, but no new programs, layout or schemes.
DEVELOPMENT, This will be the same as unstable is now, our dist that
we can experiement on, and what all major changes will be
done on. It will be the basis for the next major release of
debian.
Q. Why do I want to do this?
A. Because, I believe, that if we give more time for DEVELOPMENT to
ferment, we can do more inovative things. I believe 6 months straight, is
longer than 3 months + 3 months for us to do development. Also, big
inovations, by definition, can mean that we are doing things that are
incompatable from what we had before. However, if we allow more time to
develop Development, it means stable gets old, as we have seen with 1.3.
It's also means that back porting packages, such as we are doing now with
bo-unstable, can be difficult if a maintainer made drastic (or inovative)
changes to his package. To avoid this, I would like to view development as
taking place on 2 planes. One plane (the unstable one) could essentially be
viewed as just taking the previous debian patch file and fitting it in with
the new upstream source and fixing bugs, while the other plane, would allow
us to make inovations, such as including COAS or Linuxconf (had to get that
in, :)), GGI, Berlin.....
2) The work on development will be planned in advance and follow the
"Debian Road Map"
Q. What do I mean by the "Debian Road Map".
A. Before we start work on Development after we release 2.0 (and any other
major release afterwards), we plan what we want to be in the next major
release, and what other goals we have for it. This will become the "Road
Map for Debian 3.0"
Q. How do you plan to accomplish everything on the "Road Map", from past
experience it's hard to get things done when their are lots of goals.
A. The "Road Map" will be divided up into steps that we feel can be
accomplished within 1-2 months. During this period, we focus on that step,
all the other goals will be left for later. When we are finished with that
step, we can call it alpha-1, and ask people to test it if we feel it's
worth it, while we go on to step 2,3.... When we are finished with all of
the goals on our road map, we release development as beta, after we put it
through rigourous testing, and we are happy with it's stability, we release
it as the next major version of debian.
3) One of our main problems with 1.3 is that the code has not been updated
for a while and has become "stale" and old. I propose to fix this by
rethinking what our unstable distribution is, and pushing for minor releases
about every 2-3 months.
Q. What do I mean by "rethinking" what our unstable distribution is?
A. Right now our unstable distribution is where we do all the work, that
presents 2 problems.
1) If a user wants fresh/new code, they have to use a system that
might have changed drastically from what they have now, and might be
incompatable.
2) It can take us a while to actually release the fresh code as
stable because of all the changes taking place.
I propose to fix this by rethinking how we use unstable. What is now
unstable will become development (as I described above), and unstable ill
become more of a replica of stable, with bug fixes, and updates to programs
that are in stable, but no new programs
Q. Why do I want unstable just to be a "fresher" version of stable.
A. Their are 2 reasons, the first is because, I am of the opinion that
minor releases shouldn't really introude any new features or schemes
into Debian, changes should be left to the major release. The second reason
is, that I hope that this will help in testing unstable, since we aren't
making major changes to it, hopefully we will be able simplify the testing
of the minor releases.
Q. How easy do I believe "point upgrades" should be for users.
A. I believe all a user should have to do is point his installation tool at
an archive, and press install, and his system will be updated. However,
we are not their yet. What can we do now? We can make it so that a
person doesn't have to select any packages in the "select" screen of
whatever tool we are using, just has to make sure that they are all
marked "install", and then press install, and answer what ever questions
the post-inst scripts ask him. In the future, we should make it, that
point upgrades won't have to ask any questions and will be able to use
all the information that was originally collected on initial installation.
Please comment. And remember, I'm really open to comments, so criticize
away. Also, give me some time to respond, as e-mail time for me is really
limited, and the only days I have significant amount of times to e-mail are
Friday, and Saturday night after the sabbath.
Shaya
[1] Personally, I feel we should have major releases, such as 2.x, we then
during our work on "DEVELOPMENT" have about every 2 months minor number
releases, which introduce fresh code, and generic bug fixes. And we can
have an unlimited amount of revisions, that just provide security fixes and
Important bug fixes. (If changing Debian Linux to Debian GNU/Linux, is
important is another debate). However, as we have already made a decision
on this, I'm willing to stick by it and I feel my ideas expressed above fit
into it. If you ask why I didn't respond to the thread when we were
discussing it at the end of August, it's because I was very busy packing for
my year here, though I did find it some what amusing, it a perverted sort of
way. ;)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: