Re: so what? Re: Debian development modem
On Fri, May 29, 1998 at 02:35:30AM -0600, Bdale Garbee wrote:
> In article <[🔎] 19980529083228.A7451@molec3.dfis.ull.es> you wrote:
> : IMHO, that method would be easier to follow if we divide "main" in "core"
> : and "non-core".
>
> So, how does that differ from the current system? Isn't "core" exactly the
> same as the set of required+important priority packages? One could argue
> that the core also includes standard packages, but I see that as a second
> tier, with all of optional and extra as clearly not part of the core.
It differs in important ways. Debian's current practice of accepting
any DSFG-compliant package into main creates at least two false, but
not unreasonable, expectations among users.
First, having a package in main creates the expectation that the
package will be held to the same standards as every other package in
main. If I understood another message correctly, the test team has
only recently finished checking out the required and important
packages, now hopes to check out all of the standard packages and
probably won't get to the optional and extra packages at all. This
means there could very possibly be some serious problems in packages
that get released.
Second, having a package in main creates the expectation that the
package will either be provided in future releases also or at least
replaced with a comparable alternative. I've seen some people
suggesting that Debian should re-evaluate every package when release
time rolls around and only include those packages that are deemed
stable at that time. The consequence is that the packages which
aren't deemed stable are removed and the users that might need them
are just out of luck.
Both of these situations are a disservice to users. Having a separate
collection of packages clearly marked as contributed and not part of
the main distribution would help prevent users from forming the wrong
expectations.
Now, some may point at RedHat's contrib section and its "varying
degree" of quality as a reason not to do it that way. I strongly
believe that Debian's contrib section wouldn't be that bad. Debian's
policy, open bug system and open development process would ensure
that.
As I've stated before, having a smaller main distribution would also
immensely help to make Debian more manageable. It would make it
easier to focus the developers and testers on what packages are really
important and need the most attention when release time comes.
A true contrib section would also be the ideal place for the one-off
type packages that so many developers, including myself, are guilty of
making. By one-off, I mean the things that look neat, quickly get
packaged and are then abandoned when the neatness wears off.
On Fri, May 29, 1998 at 10:56:35AM +0800, Bill Mitchell wrote:
> All package maintainers would need debian-current release based
> development systems. Developers working on the debian-next release
> would need development systems for both debian-current and debian-next.
> (debian-current and debian-next being major releases having some
> degree of incompatibility. debian-current would have periodic
> release-numbered minor releases).
> ...
> Come to think of it, there would probably be three debian-current release
> trees. I might name them released, proven, and unproven. `released'
> would be the current minor-release stable tree. `proven' would be
> packages which had met minor-release criteria but had not yet been
> picked up in a release. `unproven' would be the latest maintainer
> release.
I don't believe this is workable. First, I doubt that enough
developers would have the required system resources to work on 3 (or
more) different releases at the same time. Second, Debian has a
purely volunteer work force. It's hard enough already getting a
sustained effort working on a single release. If that effort was
diminished by dividing the volunteers across multiple releases,
nothing would ever get done.
On Fri, May 29, 1998 at 07:19:35PM +0100, Tom Lees wrote:
> IMHO, this is what we should do:-
>
> a) Push out more releases, but label them "work in progress", or something
> similar if need be. We _CAN_ do this every 3 or 6 months, and people
> won't complain (hopefully).
They will complain. See above for what expectations users will have
concerning the quality and composition of releases.
> b) Shrink the main distribution somehow. I'm not suggesting a "core
> _developer_" approach - but a "core _distribution_" approach.
>
> This means that I can maintain packages in both distributions, no matter
> who I am, but that the distributions are managed (as a whole) separately.
Yes. This is one thing I've been trying to advocate, but probably
haven't been as clear about the "not a core developer" part as I could
have been.
> c) Do our best to motivate people more. I personally would be motivated
> by better PR on the part of the distribution, or free stuff (CDs,
> T-shirts, etc). Better PR is important though, and making fairly
> regular releases comes into that too.
I would certainly be more motivated if I believed that Debian was
moving forward, gaining wider usage and that the fruits of my labor
were benefitting more people. I'd also be more motivated if I could
recommend the distribution that I worked on to friends and coworkers
because I believed it was the best distribution for them instead of
the distribution "by and for well-net-connected developers" that it
currently is.
> d) Try our best to create more manageable release goals. Releases should
> be specifically planned to take 3 months to update. Most of the work
> that actually should happen in a release should be updating to new
> versions of packages. More long-term goals (eg FHS compliance, libc6
> updating) should be managed very carefully. One possible solution
Right. This is where the strong leadership issue that I've harped on
comes into play.
> Or maybe I just need a better mailing-list-reader (I'm using Mutt at the
> moment, but I might try GNUs) :)
I currently have procmail filter everything related to Debian into a
separate folder, but even that can be too much to read. I think I'm
going to have to filter things into multiple folders and make better
use of Mutt's scoring capabilities.
David
--
David Engel ODS Networks
david@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: