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

A new way to see versions of Debian REFORMATED



This is the same message as previous, reformated

Well, I hate that when I begin to think,
and think, and everything goes away. I
can't sleep and I'd like to put these
ideas, and eventually share these ideas
with others on a Debian's mailing-list.
But who am I to think that my ideas are
worth to be consider? I don't know, I
don't even use much Debian, and I am not
a maintainer or nothing like that, I
even never made a package. Who cares.

I heard on 'Weekly News' that stuff is
being talk right now about how freezing
should happens. I did not even read
these messages, but my mind is riding...

I came to see the development of Debian,
as a big dependancy tree. But the
freezing process do not seems to see it
the way I do.  If the freezing process
would obey this way of seeing things,
new packages would mostly be seen like
adding stuff on the last version of
Debian, since most packages are just
adding to what is working now. In my
mind, the only way to 'change' a version
of Debian, is to change a package on
which other packages depends. Or
changing stuff (kernels, booting disks,
etc) that other depends on to work. So,
a maintainer that wish to change a
package, (in a perfect world, adding
stuff to a package, would not change the
dependancy tree, just changing the
interface exported to other package
would, but since there is a need to
recompile...), is in fact proposing a
change to the distribution.

How things should work, according to me?
I am not exactly sure. I would probably
suggest something like assembling
complex objects:

-let's have let's say four versions
evolving simultaneously,  v1,v2,v3,v4

-each time it is decided, v2 becomes v1,
v3 becomes v2, v4 becomes v3, and v1
is... discarded?

-everybody can ADD  stuff, anytime, to
any versions as long  every packages on
which it depends  exists and they all
accepts to be based  upon them

-you can modify a package, as  long as
no one depends on it

-once you have decided to accept that
others packages depends on it, you can't
remove it, and you can't modify it (a
bit severe, but short to describe :-))

- if you leave it there more than x
time, you are reputed to have decided to
accept that others packages depends on it

I think, that's the way I see it. So
once in a while, there is an empty v4.
And the kernel maintainer can decide to
add there a new kernel, or the good old
one, if he/she wish. After a little
while, the time that he/she accept that
we add stuff over it, others maintainer
get the same choice, and v4 is build
subtree by subtree.

In this way of seeing, the very up to
date version is the oldest v1. But it
had publicly known bugs. v3 is the last
working version, it have few known bugs,
but have less packages than v2 and v1.
v4 does almost not work since few
packages are there, but it contains very
new features, and no known bugs, or
really almost no known bugs.

Is it a bad idea?


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.



Reply to: