Re: 1. RFD: Reorganization of the Debian Project

[Fabrizio Polacco <fpolacco@megabaud.fi>]

Bdale Garbee wrote:
> 
> In article <32A0D333.40B4AEBF@megabaud.fi> you wrote:
> :
> : Well, even if this can appear foolish, I suggest that Debian should
> : give up releasing distributions.
> :
> 
> Fascinating.  I'd like to see this idea get some serious discussion,
> and not just be dismissed out of hand.

Yes, please.
I'm quite scared by the silence of the lists. It seems that everyone is
waiting to see what will happen without realising that we all should
decide what will happen and what will not.


> The idea of a developer like me creating a pseudo-package that
> depends on all the packages I care about at revisions that I believe
> all work well together, and making that available as a
> "distribution/release" for others to install is a really intriguing
> idea, and might be really useful locally. 

I think this is the way we should follow anyway.

> Without a change in the way we handle package versions, in particular
> how we allow the older version of packages that are upgraded to
> vaporize instantly, I don't see how this can be really practical,
> though. 

This is why I want to formalize the "correctness" of a package. Now we
have the bug-tracking system that tells if a package has bugs, but the
absence of bug-reports doesn't mean everything.

I was thinking of something like a checklist to be compiled by a tester,
and a policy that tells that if a package has no bugs and N positive
reports, and the same applyes to the packages from which it depends,
then it is moved into stable automatically, but without removing the
precedent version (that should happens later).

Bugs discovered in stable packages must be fixed quickly or the package
be downgraded back into unstable. We need to force developers to
acknoledge their bugs as they are raised.


> : [3] As someone else pointed out, unstable in the last months
> : seemed to be more stable (and less buggy) than stable-fixed.
> 
> :-)  True, but you have to be careful about generalizing this.
> 

Developers has very little room to handle bugs in stable. We've seen
recently packages depending on libc 5.4 uploaded to stable and other
amenities.
The numbering scheme does'n allow room for diverging in case you need to
release an old version with a bugfix (the dot-number extension seems
reserved to non-maintainer releases).


> There are, and have always been, some issues with packages in the
> unstable tree at any given moment, most often regarding dependencies
> that are broken for short periods when something is changing. 
> The current/recent issues with X are a good example, as were the
> dependency issues surrounding the switch to ELF/libc5. 

The policy about virtual packages should be enforced, because such a
dependence can solve these kind of problems.


> Maybe there's some sort of middle ground...  A faster, and more
> predictable, release schedule would be good since it would keep
> the "value" discrepancies between stable and unstable down to a
> more manageable level...

I think the problem arises when we want to move everything from 
unstable to stable.
A formal policy on when to move one package could solve it.

more comments, please.

Fabrizio
-- 
+-------------------------------------------------------------+
| e-mail: fpolacco@megabaud.fi    fpolacco@debian.org         |
| http://megabaud.fi/~fpolacco/   Join the UKI Linux Project! |
| fingerprint 70 1A 72 2D 2B C8 A5 63 7A C2 CC E0 2A 54 AE DA |
| finger: fpolacco@megabaud.fi    fpolacco@master.debian.org  |
+-------------------------------------------------------------+


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com