Re: so what? Re: Debian development modem
Here are my responses to several messages (in no particular order). I
had intended to respond to even more messages, but I was adding too
many "me too" and "agreed" type comments and this message was already
long enough so I cut them out.
On Thu, May 28, 1998 at 01:01:57PM -0400, Brandon Mitchell wrote:
> We are only volunteers, and even the critical elements (like the boot
> disks) only move as fast as the people who work on them move. If you
All the more reason to set realistic goals for releases to begin with.
And even more reason to have strong leadership reduce those goals when
not everything goes as well as planned.
> for you. I'd prefer if debian not put the stable sticker on something
> just because we hit a 3 month mark (I know there was more to the request
> than just that, I just fear this result in the long run).
Nobody is suggesting that Debian lower its standards to ship something
just because the calendar changes. However, to many users the need to
have current, timely releases is just as important as having bug-free
releases. At some point, a current release with only a few moderate,
but fixable, problems is better than an out of date release with no
significant problems but lots of minor and annoying ones that you know
have been fixed.
On Thu, May 28, 1998 at 12:01:04AM -0400, Buddha Buck wrote:
> Before work started on Hamm, there was plans to do exactly that --
> periodic releases every 3-4 months. This was because we had such a
> problem with missing deadlines.
Change that to "... have always had and still have a problem with
missing deadlines."
> Both of those transitions required all the packages to be recompiled to
> new standards. To be fair, the libc6 conversion is complete, and we
The libc6 conversion has been virtually complete for 6 months. It was
70-80% done 9 months ago. The biggest stumbling block in the
conversion was X (to be expected). I just checked and Mark had
released the first X packages for libc6 last August already!
> also used the time to do other major overhauls (such as how we handle
> Emacs, TeX, etc, and getting the window managers to work with the
> menuing system). These overhauls also take time.
What good are those overhauls if you don't get them into users' hands
in a reasonable amount of time?
> We also took the time to improve the behind-the-scenes issues, like
> revamping the source packaging system, and overhauling the packaging
> system. We have greatly improved the ease of maintaining the
> distribution as well, with more mirrors, new hardware for master, and
> better helper scripts for building, checking, uploading, and processing
> packages.
All of which are great improvements for the developers, but none of
which were important enough from a users standpoint to force them to
go without a significant update for a year.
> Also, 1.3 was a very successful release, and caused a -tremendous-
> amount of growth in Debian as well. My available list shows nearly
I agree that 1.3 was a watershed for Debian. It's a shame that all
of the momentum gained from that release has been lost.
> 2000 packages (double that of 1.3), and we are forced to go to three
Don't be fooled. More packages does not necessarily equate to a
better distribution.
> 2.0 is a -big- improvement over 1.3. But it also did most of the big
> changes. I expect 2.1 to be a -much- simpler, faster, undertaking than
> 2.0.
I'm not as optimistic as you. There will always be a big, new
undertaking. They may not always be as big as a libc switch, but they
will be there. For example, the source packaging still needs some
improvements. What's going to happen when someone mandates that those
~2000 packages all need to be converted to the next new format before
the next release can be made?
On Thu, May 28, 1998 at 11:52:31AM -0700, The Gecko wrote:
> I thought, in general, Debian came out every few months with a new release.
> The delay with 2.0 was glibc6 and Red Hat is faster with that because they pay
> their programmers. After 2.0 is released, we should probably be able to count
> on Debian going back to it's frequent release cycle...
Debian has never, ever had a frequent release cycle.
On Thu, May 28, 1998 at 02:07:23PM +0200, Michael Meskes wrote:
> And now we're back into the marketing debate we had a short time ago.
To a degree, yes. I'm certainly not saying that having a larger
market share than RedHat should be a goal. However, if you're going
to go to the trouble of putting together a major distribution and
packaging it, don't you want to reach the widest audience you can?
On a related note, is anyone else bothered by the fact that nearly
every well known Linux developer (at least in the kernel and
development areas) uses RedHat?
On Thu, May 28, 1998 at 01:48:44PM +0100, Ian Jackson wrote:
> I see one big reason why hamm is taking so long to release: it's not
> compatible with bo.
I'm glad to see you make an appearance in this thread, Ian. I hope
you will continue to participate.
> This has made developers (many of whom were attracted by Debian's
> incremental and partial upgrade capability) very reluctant to
> upgrade. It has also made it impossible to fix bugs in bo.
>
> Let us never make this mistake again.
The mistake was not biting the bullet getting the libc conversion done
fast enough. It was allowed to drag on and other changes allowed to
creep in to the point where there were too many changes left to
complete to move forward quickly and too many changes already made to
go back.
> We should, instead, simply freeze unstable every six months, and
> release it three months or so later. A package should be allowed into
> frozen (or stable) if it would improve the quality of the
> distribution.
If you mean a full release would pop out every six months or so,
that's a bit longer than I would like but is still acceptable. I also
think 3 months from first freeze to release is too long. Finding
people to test is already hard enough. Do you really expect to be
able to find enough people willing to give up current development for
3 months just to do testing and actually get it done in 3 months?
Ian, I know Bruce left you in a tough position because of the way he
left, but I feel I must put you on thr spot here. There has been talk
before of more frequent releases, however, and each time it was just
that -- talk. What do you intend to do as current Debian leader to
ensure that the project doesn't fall back into its aimless wandering
ways like before?
> We have often good backwards compatibility, so that it doesn't matter
> if our stable distribution is a mixture of a.out and ELF or libc5 and
> libc6.
A mixed environment is fine for normal packages. It is not fine for
development packages (i.e. libraries). If not everything you need is
available for the right environment, it's worthless.
On Thu, May 28, 1998 at 09:30:07AM -0400, Raul Miller wrote:
> I suspect that if we'd have focussed on a libc6 development environment
> that run under libc5, and built up from there, that we'd have gotten
> a fully libc6 release sooner.
I don't think that would have helped much. Supporting parallel
development environments is going to be a major pain no matter how you
try to do it.
In hindsight, I think a better approach for fixing bugs in bo would
have been to allow selected libc6 packages into bo so that more easily
buildable hamm packages could have been used as updates. Before
anyone cries about moving unstable packages into stable, they would
have been tested, of course.
On Thu, May 28, 1998 at 11:54:55AM -0400, Dale Scheetz wrote:
> Well, as I see it there are two major issues, one of which is my
> responsibility.
>
> First, we are waiting on an upstream release of 2.0.7 glibc (any day now)
> which will, hopefully fix several package problems.
I don't think Debian should wait on Ulrich. There's no telling when
he will have an official 2.0.7 ready. Dale, you should go with
whatever -pre version and fixes you deem appropriate. FWIW, that's
what RedHat appears to have done.
> Second, the major need for a release is to have a functioning set of
> installation disks. As several of the crucial packages were converted to
> slang "at the last minute" they have taken some time to stabalize out. It
> appears that the most recent disk set is well on the way to being release
> ready.
Lesson learned: someone should be looking at boot disk issues even
_before_ a freeze and not allow these types of last minute changes.
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: