Re: Status of Potato
On Wed, Nov 03, 1999 at 05:19:39PM -0700, James Pullman wrote:
> While we're looking ahead, why not wait for Gnome 2.x? Maybe KDE 2.x? Kernel 2.4? Xfree86 4? And heck, once we have those in, we'll have Gnome 2.5 to wait for, and Kernel 3.0. And while I'm looking ahead, I want a new Alpha box for christmas :P
>
> See where I'm going? Features WILL be missed. Linux is a work in progress, so is Debian. Bite the bullet, miss some features, add them after release (like how we have October Gnome packages for Slink..)
>
It's exactly the problem. It's why I think we should change the way debian
releases distro :
* I think we shouldn't release a stable and an unstable distro because
there are only inconvenients.
The stable distro is pretty stable, but it's only good for a server or a
computer where the newly updated software aren't necessary. The keywords of
this distro are "stability" and "security". But When a user wants some
features, especially those concerning software like gimp that are in
constant development, he can't ! So, there are 3 possibilities :
* compiling software on his own ! But Debian has a powerful package
management software that makes it superior. If your goal is to compile
everything, just take a slackware, it's the one that is only appropriated to
that.
* Compiling software from source packages provided by the package
maintainer. Great ! But it doesn't always work. For example, on a slink system,
I wanted to compile the new mutt + GnuPG. hmmm.. I had to compile the new
slang before. It worked. Great. But it asked for the new debhelper too !
Aie, I tried to compile the .deb from the sources and it didn't work. It
made an error concerning perl or something like that. AH, so I could maybe
have to compile the new perl, and maybe the new libc, and everyhing. But
because potato isn't only an unstable distro but has a majority or
unstable (or CVS) software (eg Xemacs 21 was CVS a few time ago), my slink
system would become an unstable one ! So, it's not appropriated !
* upgrade to the unstable branch ! And I tried during the unstable
days ( a small time before perl upgrade, when libc2.1 was completly
unstable ) : All my X software were crashing, I had kernel crashes due to
X.... So, it can't be used for a normal platform !
Instead, we should make 3 distro called "server" ; "normal" and "experimental"
The "server" distro would be an extremly stable one ! It shouldn't contain
RC bugs, should wait a long time before upgrading software or kernels. For
example, the "server" distro would only upgrade to kernel 2.2 now, or in a
few months, to be sure ALL security holes, Denial Of Service and such things
that aren't tolerated for a server are avoided. It's server software shouldn't
have BUGS : Apache for example, shouldn't have neither upstream related
bugs, neither DEbian related bugs.
All unstable software like Gnome.... should be removed from this distro,
waiting for upstream stable versions. All CVS software would be removed too
! Remember : No bugs are allowed !
There should be a testing area for this distro, were we could try software
befor adding them to the distro. When a BUG or a security hole is found for
this distro, ALL the developpers must change their priority ! The
stability/security of this distro would have the best priority. Every
developper shouldn't continue working on his package but should help the
maintainer by sending a patch (provided he knows how to do that, of course !) or sending comments... to the maintainer. And if the maintainer is too busy for the moment, another developper should make the upload instead.
Of course, it shouldn't be unecessary outdated. When a policy amendment is
made, the packages should be modifier to (and only to) agree with the
policy. I think that the maintainers of the "server" distro should only have
to deal with ONE package and have at least 6 months of experiences.
The second distrib would be called "normal". To summarize, it would be a
distrib that contain the stable upstream versions, and, if the software or
the maintainer thinks it's useful, the unstable one. But the upstream stable
version must be present ! For example, for a software like Gimp, it would
contain the stable because we must have a stable version for machines
dedicaced to production and the unstable version because there are a LOT of
new stuff that are really useful. This would contain the stable Xemacs for
the users + the unstable one for the fans.....
But for small packages like a small ridiculous game, it should only contain
the stable one if it's used by someone.
BUT THIS DISTRO MUSTN'T CONTAIN ONLY CVS / UNSTABLE SOFTWARE. IT MUST BE
USEABLE BY ANY NORMAL USER THAT ONLY WANTS A NORMAL MACHINE, LIKE IF HE HAD
A RED-HAT OR a SuSE. (concerning the software update, not anything else)
this would be the distro that would be called as Official Debian. When a
computer magazine would speak about debian, he would certainly speak about
this one exept if it's a Server related magazine.
This distrib would inherits software from the "experimental" one. An
experimental package would be able to go into these section if and only if
1 ) It's mainly useful. We shouldn't add there the new dpkg v2 or a
thing that is only necessary to the experimental developpers.
2 ) It hasn't too much Bugs, nor security holes
3 ) It's not a testing package, just a pakage that has already been
tested in the experimental stage.
I think you have now unserstood the general goal of this distrib, so let's
speak about the "experimental" one
This distrib wouldn't have the same goal as the actual "experimental". It
would be a distrib were all new software would be added first. The Beta
testers would test the software, repourt bugs.... It shouldn't be a distrib
that is usable by itself, only a distro that is necessary for testing.
To sum up, it would be a complete CRUFT ! Everything would be tolerated
here, provided that the Bugs are reported and that the maintainer do his job
: Bug fixing.
A maintainer that doesn't fix his bugs for any reason should be fired ! When
a developper thinks another developper doesn't do a good job, he could send
a mail to debian-devel, with a subject like "Intend to fire : Name Of The
Guy" and explain his reasons. ANd if the man doesn't explain his attitude,
and if at least 50 developpers (for example) agree with the IT fire, the man
is fired ! As a result, we would only have developpers that trust in debian
and want debian to be a better distro. But it should be easier and faster to
become a developper. Provided that we can fire the developper, everyone
could become a developper if he wants to add something into debian. The
Maintainer guide should of course warn the new developper that he must do a
good job, and that the debian team knows his identity (the subscribtion should
continue to ask for an identirty card) and he musdn't become a developper
for hacking reasons. We shouldn't hire developper that live inside
countries were hacking is legal, of course :))
The release numbering should be, I think, different. (Think different, like
Apple :-))
* For the stable release, it should be changed every time it
upgrades its kernel or its libc. A sub. version can be changed when a great
number of packages are accepted (e.g. if 100 packages have been upgraded,
the sub version should be incremented
* Because the normal version should be upgraded constantly, I think
it's version should be incremented each time RedHat increments its distro,
only for the style ! Or we should maybe have a goal to reach, like now.
* The experimental distro shouldn't have any version. Don't
remember, it's only a cruft, were developpers are playing and were mass of
new code lines are added.
I think I have finished explaining te BIG debian problem. So, please
consider what I wrote instead of saying it's right while nothing changes.
(Ah ! Another Debian problem : changing something is impossible. Even if
it's great, there is a Policy chapter saying that X or X thing is impossible
! Please stop only think through the policy, think before about the proposed
idea, think after about the policy and legal side. If the policy forbits
something which is cool, just change the policy, it's nothing else than some
words added together in a text file....)
Hoping you will think at my idea,
sami
--
DDDD EEEEE BBBB II AAAAA NN N LL II NN N U U X X
DD D E__ B__B II A___A N N N LL II N N N U U XX
DD D E B B II A A N N N LL II N N N U U XX
DDDD EEEEE BBBB II A A N NN LLLLL II N NN UUUUU X X
Reply to: