|
Home > Archive > Debian Developers > April 2004 > testing and no release schedule
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
testing and no release schedule
|
|
| Adrian Bunk 2004-03-25, 8:38 pm |
| On Thu, Mar 25, 2004 at 12:39:20PM -0600, Steve Langasek wrote:
>...
> (And
> given that reducing freeze time is a stated goal of testing, I don't
> think the lack of an announced freeze is all that useful in gauging our
> time to release.)
>...
You say it "is a stated goal of testing".
Before testing was invented, it was also a goal that testing should be
always in a releasable state. Practice has shown that this goal was
never reached.
Looking at the woody freeze, the question arises whether testing really
reaches the goal to reduce the freeze time.
There are always reasons to say "hey, we managed to get A, B and C into
testing, and the next goals are getting D, E and F into testing". But is
this real progress towards the next stable release, or will after F is
achieved only G, H and I arrive?
I have yet to see any objective evaluation whether testing really is an
improvement.
Let me say that I'm frustrated, and sorry if the following is a bit
offensive.
I reassigned from Debian over two years ago since I was not happy with
the speed of Debian releases. Since then, I have the impression things
got even worse.
I like Debian for both technical and political reasons, but it's simply
impossible today to recommend to anyone to use Debian stable on
production systems. Or if a friend wants to know which Linux
distribution to install on his new computer since most likely his
graphics adapter will only be supported in non-acceptable VESA modes.
Backports are a workaround for this problem, but they cause additional
problems, e.g. I assume it will be a nightmare to upgrade many of the
Debian 3.0 plus half a dozen backports systems to Debian 3.1.
It's quite frustrating that there's no clear schedule towards Debian 3.1
that includes a date for the beginning of the freeze.
When talking about a clear schedule, I'm not talking about something
unrealistic like the schedule that told Debian 3.1 would be released on
Dec 1st 2003 that included dates that were not based on any realistic
estimates (esp. the installer dates).
Debian stable might not be known for short release cycles, but it's
still known for high quality packages and easy upgrades. To achieve this
quality Debian is known for it's not enough to say at some point "we
will release in one month". After the beginning of a freeze, there need
to be several months to fix all bugs that get reported over time and to
ensure that both new installations of Debian 3.1 and upgrades from
Debian 3.0 to Debian 3.1 work for everyone without problems.
I'm no longer at the age where I think "my idea is the only possible
solution", and although I'm not a fan of testing freezing testing is
definitely a possible way towards a new stable release.
The latest "Release update" [1] said "On or shortly after 15th March,
we'll see if these targets have been met and update the schedule
accordingly.". I sent on March 15th a suggestion of a "weak freeze" and
how I'd help within it for unstable [2] plus two additional mails to the
release managers and his assistants. I got one mail from you (Steve)
stating that "At a glance, I don't see anything in the plan that
conflicts with the Release Team's agenda." and that you wanted to answer
during the next days a week ago, but no other feedback until now.
I'm not claiming that my suggestion of a weak freeze of unstable is the
only way to get closer towards Debian 3.1, but I'm a bit astonished that
although it was announced that "shortly after 15th March" there will be
an update of the release schedule, none of the release managers and his
assistants had the time to either send an updated release schedule or to
give an "yes" or a "no, we have a better plan" answer to my suggestion.
In the pre-testing times there was one release manager who announced a
freeze date, and at that date unstable was frozen and at about half a
year later there was a new stable release. Today, there are 4 people
that do release management, but it seems neither possible to do any
estimate when Debian 3.1 will release, nor does it seem that the
release speed improved.
These are the points where I'm quite unhappy with the current release
management.
Note that I'm not claiming that there's only one way to get to a
high-quality stable release, or that the release manager and his
assistants were complete idiots.
Most frustrating is that I see no way to help making the situation
better at the moment. Fixing bugs is not very effective as long as
there'a no freeze and new upstream versions with new bugs flood into
testing every day. That was the point when I sent my suggestion of a
weak freeze of unstable that would make both unstable and testing
better (as explained in my mail). The only people that are able to
announce a freeze are the release manager and his assistants.
What is the alternative?
If there's no progress inside Debian the only alternative would be to do
some kind of an Open Source variant of Lindows:
Trying to find some other people and infrastructure to create a new
distribution with stable releases based on Debian.
But besides requiring much work, such a split would be a loss-loss
situation for everyone.
That was much text.
Thanks to everyone who took the time reading it.
Sorry if it was too offensive.
> Steve Langasek
cu
Adrian
[1] http://lists.debian.org/debian-deve...2/msg00009.html
[2] http://lists.debian.org/debian-deve...3/msg01033.html
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-25, 8:38 pm |
| On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
> I like Debian for both technical and political reasons, but it's simply
> impossible today to recommend to anyone to use Debian stable on
> production systems.
I don't think this is 100% true. At the company I work for, we still use
woody on most of our servers (and we still even have potato installed on
some).
Stable is *definitely* not usable on desktop systems. The problem is that
pretty much every Debian developer runs unstable on his/her desktop. So not
having a current stable release doesn't really affect them.
Perhaps Debian needs to change its product offering. We could have a server
distribution (with a long release cycle) and a desktop distribution (with a
short release cycle). Yes, just like every other major Linux vendor. No,
this is not rocket science and I'm 100% sure I'm not the first one with this
idea. So why aren't we doing it?
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-25, 9:34 pm |
| On Thu, Mar 25, 2004 at 04:47:12PM -0800, Adam McKenna wrote:
> On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
>
> I don't think this is 100% true. At the company I work for, we still use
> woody on most of our servers (and we still even have potato installed on
> some).
>...
Even servers sometimes require recent software.
E.g. SpamAssassin from stable isn't that helpful on a mail server today.
> Perhaps Debian needs to change its product offering. We could have a server
> distribution (with a long release cycle) and a desktop distribution (with a
> short release cycle). Yes, just like every other major Linux vendor. No,
> this is not rocket science and I'm 100% sure I'm not the first one with this
> idea. So why aren't we doing it?
The server distributions of some other major Linux vendors (not all
offer server products) are roughly spoken the personal editions plus
additional fixes and features and equipped with five years of support.
Splitting Debian into two parts would create extra work and produce new
problems like testing all ways to switch between the server- and the
desktop-distribution.
Debian stable's quality is comparable with the quality of other major
Linux vendors' server products.
If Debian would manage to release once a year (e.g. half a year new
features and then half a year freeze) Debian stable would be suitable
for both server and desktop needs. It wouldn't be as current as e.g. the
latest SuSE but stability and easy upgrades would compensate for this
even for desktop users.
> --Adam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2004-03-25, 9:34 pm |
| Adam McKenna <adam@flounder.net> writes:
> Perhaps Debian needs to change its product offering. We could have a
> server distribution (with a long release cycle) and a desktop
> distribution (with a short release cycle). Yes, just like every other
> major Linux vendor. No, this is not rocket science and I'm 100% sure
> I'm not the first one with this idea. So why aren't we doing it?
Because Debian and short release cycle are currently incompatible. Debian
isn't just like every other major Linux vendor; Debian supports an order
of magnitude more packages. I believe you have to fundamentally change
the concept of what goes into a release to increase the speed of the
release cycle notably, and even then I think it's going to be hard to do a
release much faster than Debian currently is while still maintaining the
same level of quality. It's exactly the desktop software that often has
very long dependency chains that are difficult to get into a releasable
state at the same time.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matt Zimmerman 2004-03-25, 10:34 pm |
| On Thu, Mar 25, 2004 at 05:53:34PM -0800, Russ Allbery wrote:
> Because Debian and short release cycle are currently incompatible.
I completely disagree; it just takes a different kind of mojo to get Debian
releasing.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 11:20 am |
| On Thu, Mar 25, 2004 at 05:53:34PM -0800, Russ Allbery wrote:
> It's exactly the desktop software that often has
> very long dependency chains that are difficult to get into a releasable
> state at the same time.
....yet all of the other Linux distributors seem to be able to do it.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miles Bader 2004-03-26, 11:20 am |
| Adam McKenna <adam@flounder.net> writes:
>
> ...yet all of the other Linux distributors seem to be able to do it.
.... by having goals nowhere near as lofty.
Debian releases on what is it, 11 archs? Most of them are never tested
by upstream authors, so if there's a problem, guess where it's going to
show up?
-Miles
--
Run away! Run away!
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 11:20 am |
| On Fri, Mar 26, 2004 at 04:10:29PM +0900, Miles Bader wrote:
> Adam McKenna <adam@flounder.net> writes:
>
> ... by having goals nowhere near as lofty.
>
> Debian releases on what is it, 11 archs? Most of them are never tested
> by upstream authors, so if there's a problem, guess where it's going to
> show up?
How about we just stop making excuses? If dead architectures are holding up
the release process, then drop them, or make them secondary platforms. m68k
wouldn't be any worse off today if we had released an i386 sarge six months
ago.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Patrice Fortier 2004-03-26, 11:21 am |
| Le ven 26/03/2004 à 08:46, Adam McKenna a écrit :
> On Fri, Mar 26, 2004 at 04:10:29PM +0900, Miles Bader wrote:
>
> How about we just stop making excuses? If dead architectures are holding up
> the release process, then drop them, or make them secondary platforms. m68k
> wouldn't be any worse off today if we had released an i386 sarge six months
> ago.
In fact, it should even be in better shape, as it's much easier to
correct problems on a stable release than on a constantly evolving
software base.
Patrice.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Pitt 2004-03-26, 11:21 am |
| Hi Adrian, hi everybody!
On 2004-03-26 1:42 +0100, Adrian Bunk wrote:
> I'm not claiming that my suggestion of a weak freeze of unstable is the
> only way to get closer towards Debian 3.1, but I'm a bit astonished that
> although it was announced that "shortly after 15th March" there will be
> an update of the release schedule, none of the release managers and his
> assistants had the time to either send an updated release schedule or to
> give an "yes" or a "no, we have a better plan" answer to my suggestion.
I was a bit disappointed by that too. Announcing and enforcing freezes
over different stages (no new packages to testing, no new major
upstream versions, manual propagation to testing etc.) is overdue and
I don't see a reason why this cannot be done at this (or any other)
moment, if there is one, I would appreciate enlightenment.
A few days ago I was waiting for the testing RC bug counter dropping
below 200, and now its is already back to 245. We won't get anywhere
when we keep the current state of changing.
> What is the alternative?
> [...]
> Trying to find some other people and infrastructure to create a new
> distribution with stable releases based on Debian.
I also thought about this once: if we are not able to make releases in
a reasonable time (i.e. <= 1 year) then we should not aim for it in
the first place and have other groups screw together Debian-based
stable distros. But this would make at least me unhappy; why we have
Release Managers when we don't hear anything from them? I do not say
that they are inactive, but they should be a bit more verbose and
actually enforce things more rigidly. Anthony, can you please tell us
about your current plans? Thanks in advance!
Currently I cannot really recommend people to use Debian because very
few of them want to limit theirself to the alternatives "stick with
outdated software" or "constantly change your system without security
updates". This is really a pity.
I know that the installer is not yet finished anyway, but looking at
its current progress it certainly might be ready in three to six
months and AFAICS we need (at least) this time to get testing into
releasable shape.
Thanks for comments and have a nice day!
Martin
--
Martin Pitt Debian GNU/Linux Developer
martin@piware.de mpitt@debian.org
http://www.piware.de http://www.debian.org
| |
| Chad Walstrom 2004-03-26, 1:42 pm |
| On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
> It's quite frustrating that there's no clear schedule towards Debian
> 3.1 that includes a date for the beginning of the freeze.
Agreed. It's frustrating, indeed. Historically, Debian takes the Linux
kernel strategy: "It's ready when it's ready." Without schedules to
commit to, Debian avoids the reputation of not releasing "on time".
Debian can never be behind or late, but it never promises to be
punctual, timely.
Obviously there are Pro's and Con's to this approach. The primary Pro's
are: Debian can ignore complaints of obsolescense. Debian will always
release stable, secure, and consistant state.
The Con's are: Debian is behind the curve compared to most distribution
releases. Although Debian can ignore complaints of obsolescense, the
truth is quite opposite with repect to upstream stable releases of
software. There is a motivational factor that is lost by our developers
when you don't have deadlines. The public impression of progress is
lost when there are no deadlines.
So on and so forth... Can you guess which I would favor?
I still like the componentization idea of Ian's, but I'll not drag that
argument into this thread just yet.
--
Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
| |
| Colin Watson 2004-03-26, 1:43 pm |
| On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
> There are always reasons to say "hey, we managed to get A, B and C into
> testing, and the next goals are getting D, E and F into testing". But is
> this real progress towards the next stable release, or will after F is
> achieved only G, H and I arrive?
It is clearly frustrating for us when we manage to heave a huge pile of
improvements into testing only to find that people say "oh, but you
can't release stable yet because <major-project> <major-new-version> has
just been released".
At the same time, we *have* to have a working installer; anything else
is just not an option. To some extent, the exact details of what version
of everything else we release with is a distraction, and is certainly
much more easily solved. (Not meaning to demean anyone's efforts, of
course, but I think it's clear that "our installer doesn't work yet"
usually overrides "we don't have a new enough version of <foo>".)
> It's quite frustrating that there's no clear schedule towards Debian 3.1
> that includes a date for the beginning of the freeze.
I'm sorry that there hasn't been a schedule posted since the 15th. This
is mostly because the release team have been working flat-out on other
things (I've been trying to make d-i work releasably on powerpc, and I
believe the same goes for Steve and d-i on alpha).
A new announcement is being prepared now, and should be available by
this weekend.
> When talking about a clear schedule, I'm not talking about something
> unrealistic like the schedule that told Debian 3.1 would be released on
> Dec 1st 2003 that included dates that were not based on any realistic
> estimates (esp. the installer dates).
The estimates did seem realistic at the time, actually, but it turned
out that the installer was further behind than was expected. We're now
much closer to a fully-working installer (there've already been lots of
very favourable installation reports along with the bugs, some saying
that it's already much better than woody's), and it's possible to make
better predictions.
> After the beginning of a freeze, there need to be several months to
> fix all bugs that get reported over time and to ensure that both new
> installations of Debian 3.1 and upgrades from Debian 3.0 to Debian 3.1
> work for everyone without problems.
However, long freezes are also problematic. They impede development and
cause much frustration: the potato freeze was a good example of this.
> The latest "Release update" [1] said "On or shortly after 15th March,
> we'll see if these targets have been met and update the schedule
> accordingly.". I sent on March 15th a suggestion of a "weak freeze" and
> how I'd help within it for unstable [2] plus two additional mails to the
> release managers and his assistants. I got one mail from you (Steve)
> stating that "At a glance, I don't see anything in the plan that
> conflicts with the Release Team's agenda." and that you wanted to answer
> during the next days a week ago, but no other feedback until now.
>
> I'm not claiming that my suggestion of a weak freeze of unstable is the
> only way to get closer towards Debian 3.1, but I'm a bit astonished that
> although it was announced that "shortly after 15th March" there will be
> an update of the release schedule, none of the release managers and his
> assistants had the time to either send an updated release schedule or to
> give an "yes" or a "no, we have a better plan" answer to my suggestion.
See above. I'm sorry that "shortly" has slipped more than we intended.
On the other hand, I'm not keen on the "I'll fix bugs when we freeze"
attitude; this is a chicken-and-egg situation. Bugs need to be fixed
*now* so that we can freeze with the confidence that we know
approximately how long the freeze will need to last.
If you don't want to fix bugs until we freeze, then please contribute
that effort to the new installer. That is the single most effective way
to speed up the next release right now.
> In the pre-testing times there was one release manager who announced a
> freeze date, and at that date unstable was frozen and at about half a
> year later there was a new stable release. Today, there are 4 people
> that do release management, but it seems neither possible to do any
> estimate when Debian 3.1 will release, nor does it seem that the
> release speed improved.
Remember that the difficulty of release management has increased very
substantially since the old days, due to the many-times-over increased
size of the distribution and the more and more labyrinthine nature of
our dependency structure. This consumes a great deal of release
management time, although the large-scale automation of testing makes
the job possible.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 1:44 pm |
| On Fri, Mar 26, 2004 at 02:31:20PM +0100, Adrian Bunk wrote:
>
> Which of the architectures Debian 3.0 released with do you consider to
> be dead?
A lot of them. However, that's not the point. The point was to stop making
excuses. If niche (politically correct term for dead) architectures are
holding up the release, then let's release without them.
> A real problem are RC issues in essential packages like e.g. glibc.
>
> Let's check for which architectures there are architecture-specific RC
> bugs open against glibc today [1]:
> - i386
> - alpha
> - sparc
> And there are also benefits of supporting many architectures, an
> example:
>
> hppa in Debian 3.0 uses gcc 3.0. Therefore, the hppa maintainers had to
> report all compile errors with with g++ 3 as non-RC bugs.
>
> Some bugs were not fixed before Debian 3.0 was released, and this was
> only a hppa problem. But the big amount of reported and mostly fixed
> issued with g++ 3 made the g++ 3.2 transition for all architectures much
> easier.
I think we are in agreement that this is a management problem, and not
necessarily a manpower problem. I also don't know if it's a solvable
problem, since solving it will require a change in Debian's culture at the
highest levels.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-26, 3:35 pm |
| On Fri, Mar 26, 2004 at 04:58:37PM +0000, Colin Watson wrote:
> On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
>
> It is clearly frustrating for us when we manage to heave a huge pile of
> improvements into testing only to find that people say "oh, but you
> can't release stable yet because <major-project> <major-new-version> has
> just been released".
That's similar to my opinion that it's of limited value to fix bugs etc.
before the beginning of a freeze.
If there's a freeze announced early enough all maintainers know that
after this date no major changes are allowed. All "<major-project>
<major-new-version>" have to simply be ignored after this date.
> At the same time, we *have* to have a working installer; anything else
> is just not an option. To some extent, the exact details of what version
> of everything else we release with is a distraction, and is certainly
> much more easily solved. (Not meaning to demean anyone's efforts, of
> course, but I think it's clear that "our installer doesn't work yet"
> usually overrides "we don't have a new enough version of <foo>".)
That's clear.
Looking at the past, it might perhaps have been worth to check at the
time of the release of Debian 3.0 whether the new installer would be
ready in time for Debian 3.1, or whether this would have better been a
Debian 3.2 project with parallel work to get the woody installer working
in Debian 3.1. But that's a past experience that might be a worthwhile
experience for the future.
>
> I'm sorry that there hasn't been a schedule posted since the 15th. This
> is mostly because the release team have been working flat-out on other
> things (I've been trying to make d-i work releasably on powerpc, and I
> believe the same goes for Steve and d-i on alpha).
>
> A new announcement is being prepared now, and should be available by
> this weekend.
>...
Is it possible to either publically or privately discuss the
announcement with you before it's released?
The final decision is at the release manager, but I'd prefer to give
comments and critics before it's officially released instead of later.
>
> However, long freezes are also problematic. They impede development and
> cause much frustration: the potato freeze was a good example of this.
The woody freeze wasn't shorter.
The main question is perhaps what Debian's main focus is:
An always up-to-date unstable or a rock-solid stable?
You can't have both.
A rock-solid stable requires much testing (including many newly reported
bugs) after the beginning of the freeze.
Several months after the freeze are required with all Debian developers
focussing mostly on frozen to create a stable the is as good as Debian
users are used to.
>
> See above. I'm sorry that "shortly" has slipped more than we intended.
> On the other hand, I'm not keen on the "I'll fix bugs when we freeze"
> attitude; this is a chicken-and-egg situation. Bugs need to be fixed
> *now* so that we can freeze with the confidence that we know
> approximately how long the freeze will need to last.
>...
Many bugs currently present aren't yet reported.
I wouldn't agree that the focus on the number of RC bugs in testing is
really the right metric to estimate the release date on.
Besides this, noone has counted the number of RC bugs that are present
only in testing since they were already fixed in unstable.
>
> Remember that the difficulty of release management has increased very
> substantially since the old days, due to the many-times-over increased
> size of the distribution and the more and more labyrinthine nature of
> our dependency structure. This consumes a great deal of release
> management time, although the large-scale automation of testing makes
> the job possible.
First of all, I want to say that although I'm not a fan of freezing
testing, it's definitely possible to use testing to get to a new stable.
The "large-scale automation of testing" tracks some issues and solves
some problems, but it also creates new problems that weren't in
unstable. As an example, check the state of xfig/transfig in testing two
days ago that made both packages useless for most purposes.
And when looking at how much manual work is always required to keep
testing in a usable shape, I have yet to see a comparison that shows
that testing is really an improvement regarding the work required
and/or the time needed to get a new stable release.
> Cheers,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-26, 3:35 pm |
| On Fri, Mar 26, 2004 at 09:54:44AM -0600, Chad Walstrom wrote:
> On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
>
> Agreed. It's frustrating, indeed. Historically, Debian takes the Linux
> kernel strategy: "It's ready when it's ready." Without schedules to
> commit to, Debian avoids the reputation of not releasing "on time".
>...
Halloween 2002 was announced as the date for the feature freeze for
kernel 2.6 months before, and after this date most effort was spent in
stabilizing the kernel.
Looking at kernel 2.6 my impresion is that this was a good way.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-26, 3:35 pm |
| On Fri, Mar 26, 2004 at 09:31:35AM -0800, Adam McKenna wrote:
> On Fri, Mar 26, 2004 at 02:31:20PM +0100, Adrian Bunk wrote:
>
> A lot of them. However, that's not the point. The point was to stop making
> excuses. If niche (politically correct term for dead) architectures are
> holding up the release, then let's release without them.
If I understand you correctly, every architecture except i386 is a
"dead" architecture since most likely > 95% of all Debian users use
Debian in i386.
>
>
> I think we are in agreement that this is a management problem, and not
> necessarily a manpower problem. I also don't know if it's a solvable
> problem, since solving it will require a change in Debian's culture at the
> highest levels.
I see that it causes additional work to support many architectures, but
I can't see that there would be specific architectures to blame.
> --Adam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bruno Barrera C. 2004-03-26, 3:35 pm |
| On Thu, 2004-03-25 at 20:47, Adam McKenna wrote:
> On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
>
> I don't think this is 100% true. At the company I work for, we still use
> woody on most of our servers (and we still even have potato installed on
> some).
Same here. Actually we have a woody server without problems, and people
are happy with it. Most of them, recognizes that woody is really stable
and can be handled easily without lost efficiency, security and
stability.
>
> Stable is *definitely* not usable on desktop systems. The problem is that
> pretty much every Debian developer runs unstable on his/her desktop. So not
> having a current stable release doesn't really affect them.
I Agree.
>
> Perhaps Debian needs to change its product offering. We could have a server
> distribution (with a long release cycle) and a desktop distribution (witha
> short release cycle). Yes, just like every other major Linux vendor. No,
> this is not rocket science and I'm 100% sure I'm not the first one with this
> idea. So why aren't we doing it?
Many users think that 'stable' is too old, and they willn't use it, and
when you tell they about 'unstable' they got scared (No! That will break
my system, no way!). So, many users use other linux distributions.
--
Midway upon the journey of our life,
I found myself within a forest dark,
For the straightforward pathway had been lost.
| |
| Ingo Juergensmann 2004-03-26, 4:36 pm |
| Xref: number1.nntp.ash.giganews.com linux.debian.devel:143917
On Thu, Mar 25, 2004 at 11:46:46PM -0800, Adam McKenna wrote:
> How about we just stop making excuses? If dead architectures are holding up
> the release process, then drop them, or make them secondary platforms. m68k
> wouldn't be any worse off today if we had released an i386 sarge six months
> ago.
Ah, you're offering yourself as a person that would like to explain users
why their arch is no longer supported?
Regarding to popcon.debian.org we should then first drop hppa, mipsel and
s390. There are apparently much less users than on m68k.
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2004-03-26, 4:36 pm |
| On 26-Mar-04, 14:07 (CST), Adrian Bunk <bunk@fs.tum.de> wrote:
>
> Halloween 2002 was announced as the date for the feature freeze for
> kernel 2.6 months before, and after this date most effort was spent in
> stabilizing the kernel.
>
> Looking at kernel 2.6 my impresion is that this was a good way.
The kernel has someone with the power to say "Yes, this change goes
in", and "No, this change must wait". No one in Debian has that power.
Anytime someone tries to take such a position, there's a lot of whining
about cabals and dictators and abuse of power.
And you'll note it took a >year between the announced freeze and the
actual release of 2.6.
Big projects with lots of interacting parts are simply difficult to
stabilize and release. Debian is a combination of several such projects,
is it any wonder we have problems?
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-26, 4:36 pm |
| Colin Watson wrote:
> At the same time, we *have* to have a working installer; anything else
> is just not an option. To some extent, the exact details of what version
> of everything else we release with is a distraction, and is certainly
> much more easily solved. (Not meaning to demean anyone's efforts, of
> course, but I think it's clear that "our installer doesn't work yet"
> usually overrides "we don't have a new enough version of <foo>".)
It works quite well now on i386, ia64, and alpha, and to some extent on some
of the other architectures (powerpc, sparc, m68k).
Is it time to drop some architectures and/or subarchitectures? :-P For
instance, powerpc-oldworld appears to be a PITA to support, and
powerpc-apus likewise. Some ARM subarchitectures don't even have a kernel
yet, nobody's built a daily build for mipsel ever as far as I can tell,
etc.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2004-03-26, 4:36 pm |
| On 26-Mar-04, 14:07 (CST), "Andrew M.A. Cater" <amacater@galactic.demon.co.uk> wrote:
> No, and I could care less about them. If our releases are being delayed
> because we're spending too much time supporting dead platforms, we should
> drop support for them in our releases, or at least support them as secondary
> platforms which are released after the primary platforms.
The world has plenty of x86 only Linux distributions. One of the values
of Debian is that it supports a wide variety of systems. That means
someone can run the same distribution on all the machines under their
purview.
> The fact that Debian is a volunteer organization has nothing to do
> with the fact that we release slowly. I wish people would stop using
> this red herring argument. We probably have more manpower than the
> development teams of the 3 largest Linux distributors put together.
> The problem, as in most large, ineffective organizations, is in
> management.
What management? That's exactly the point: Because Debian is a volunteer
organization (or rather, because it's an unstructured volunteer
organization), you can't tell people what to do. If more people were
interested in making releases, then they'd happen faster. Most people in
Debian are interested in maintaining a few packages.
When you "sign up" to hack the Linux Kernel, or GNOME, or Python, or X,
there's a very clear authority structure. Our authority structure is
"everybody is equivalent." That's what the constitution says. There are
some de-factor chokepoint positions, such the FTP masters and Release
master, but anytime they try to actually do something, there's a lot of
bitching and moaning about how they're not doing their job right and how
we need to overthrow the cabal. I'm amazed that they continue to put up
with it; I sure as hell would have given up a long time ago.
And every six months or so, someone comes in to say how we could make
faster releases is only we did X, Y, and Z. Well, here's the thing:
there's nothing to keep you from taking the packages, picking the ones
you want, and making your own release. Since the problems not manpower,
but only organization, this shouldn't be such a big deal, eh?
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-03-26, 4:36 pm |
| On Fri, Mar 26, 2004 at 04:22:51PM -0500, Nathanael Nerode wrote:
> Colin Watson wrote:
>
> It works quite well now on i386, ia64, and alpha, and to some extent on some
> of the other architectures (powerpc, sparc, m68k).
>
> Is it time to drop some architectures and/or subarchitectures? :-P For
> instance, powerpc-oldworld appears to be a PITA to support, and
> powerpc-apus likewise.
We just got a new developer who's working on oldworld. Not sure about
apus, although I think Sven's handling that.
> Some ARM subarchitectures don't even have a kernel yet,
That's OK - I believe there are something like 70 ARM subarchitectures.
Lots of them are pretty minority interests, and we don't have to support
all of them.
In general dropping subarchitectures is fairly easy, and can be decided
quickly enough based on what works when everything else is ready. We
need to be in a position where popular architectures like powerpc don't
turn out to be broken like it did for beta3, though.
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2004-03-26, 5:34 pm |
| Adrian Bunk wrote:
> Looking at the past, it might perhaps have been worth to check at the
> time of the release of Debian 3.0 whether the new installer would be
> ready in time for Debian 3.1, or whether this would have better been a
> Debian 3.2 project with parallel work to get the woody installer working
> in Debian 3.1. But that's a past experience that might be a worthwhile
> experience for the future.
We tried that during the woody release, and it failed miserably; nearly
a year of development time on d-i was lost while a few people got the
boot floppies working again for one last hurrah. It was impossible to
make projections of how much time it would take to get d-i ready when
noone was working on it, noone was testing it, and the issues were
unknown.
The only way to get the installer ready is to make it a priority, and to
work on it.
--
see shy jo
| |
| Adam McKenna 2004-03-26, 5:34 pm |
| On Fri, Mar 26, 2004 at 09:12:42PM +0100, Adrian Bunk wrote:
>
> If I understand you correctly, every architecture except i386 is a
> "dead" architecture since most likely > 95% of all Debian users use
> Debian in i386.
I would say there are 4 or 5 architectures that would be worth putting into
the 'core', which should cover more than 99% of our installed base. I'm not
going to get into specifics because it would be a waste of time at this
point.
>
> I see that it causes additional work to support many architectures, but
> I can't see that there would be specific architectures to blame.
Then my point is valid. Supporting many architectures is not a valid
excuse for our long release cycle.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-26, 5:34 pm |
| On Fri, Mar 26, 2004 at 02:40:43PM -0600, Steve Greenland wrote:
> On 26-Mar-04, 14:07 (CST), Adrian Bunk <bunk@fs.tum.de> wrote:
>
> The kernel has someone with the power to say "Yes, this change goes
> in", and "No, this change must wait". No one in Debian has that power.
> Anytime someone tries to take such a position, there's a lot of whining
> about cabals and dictators and abuse of power.
"The freeze begins at ..." is a power the Debian RM has.
The Debian RM even has the power to remove any package he wants from
testing without notifying anyone. With freezeing testing, this is the
power to remove any package he wants from the next stable release.
I wouldn't say that these powers the Debian RM has today aren't enough.
> And you'll note it took a >year between the announced freeze and the
> actual release of 2.6.
>...
Sure.
I was talking about quality, not about speed.
Looking at the last freezes, half a year might be a realistic estimate
for the time between the beginning of the freeze and a stable release of
the quality Debian is known for.
> Steve
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 5:34 pm |
| On Fri, Mar 26, 2004 at 10:02:29PM +0100, Ingo Juergensmann wrote:
> On Thu, Mar 25, 2004 at 11:46:46PM -0800, Adam McKenna wrote:
>
>
> Ah, you're offering yourself as a person that would like to explain users
> why their arch is no longer supported?
I'm not suggesting dropping support. Please learn to read. I'm saying that
architectures with RC bugs that are not popular should not hold up the
release. They can be released later. It will be up to the individual arch
teams when the release happens.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2004-03-26, 5:34 pm |
| Ingo Juergensmann wrote:
> Ah, you're offering yourself as a person that would like to explain users
> why their arch is no longer supported?
"Because nobody cared enough to do any work on it, despite numerous
pleas for help."
> Regarding to popcon.debian.org we should then first drop hppa, mipsel and
> s390. There are apparently much less users than on m68k.
We're well on our way to dropping mipsel and s390: d-i has never booted
on mipsel let alone installed, and we have no working means of
partitioning a s390 in the debian-installer.
http://www.debian.org/devel/debian-...er/ports-status
--
see shy jo
| |
| Karsten Merker 2004-03-26, 5:36 pm |
| On Fri, Mar 26, 2004 at 04:22:51PM -0500, Nathanael Nerode wrote:
> Is it time to drop some architectures and/or subarchitectures? :-P For
> instance, powerpc-oldworld appears to be a PITA to support, and
> powerpc-apus likewise. Some ARM subarchitectures don't even have a kernel
> yet, nobody's built a daily build for mipsel ever as far as I can tell,
> etc.
The missing daily build on mipsel is due to breakage in two areas:
keyboard support and proper serial console support (the latter is a
problem for other architectures as well and problems in this area
occur also on i386, if somebody actually uses serial console there).
These issues are being worked on, but it needs some time. D-i works
ok on mipsel besides these two things (just did a full install two
days ago), but as long as these two are unfixed, having daily builds
do not make sense.
Regards,
Karsten
--
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ingo Juergensmann 2004-03-26, 5:36 pm |
| On Fri, Mar 26, 2004 at 01:01:56PM -0800, Adam McKenna wrote:
> I'm not suggesting dropping support. Please learn to read. I'm saying that
> architectures with RC bugs that are not popular should not hold up the
> release. They can be released later. It will be up to the individual arch
> teams when the release happens.
One of the things that can make maintainers fix their bugs, is the release.
When you exclude (or delay) some archs, some bugs will never get fixed by
the maintainers. Ergo, it is very unlikely that non-core archs would release
anyway.
The porters are there to get the arch working and compiling packages and to
port some things to their arch - not to fix maintainers (RC) bugs.
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Karsten Merker 2004-03-26, 5:36 pm |
| On Fri, Mar 26, 2004 at 04:38:05PM -0500, Joey Hess wrote:
> We're well on our way to dropping mipsel and s390: d-i has never booted
> on mipsel let alone installed, and we have no working means of
> partitioning a s390 in the debian-installer.
Sorry Joey, but that is is not true with regard to mipsel. It boots,
and installation works mostly with the two showstoppers being keyboard
support (mipsel specific problem) and serial console support (general
problem over several architectures).
Kbd-chooser had even worked on mipsel in the meantime but other changes
seem to have broken it again.
I have done an install with current CVS (as of two days ago) which
worked ok with the exception of kbd-chooser dying and some problem in
prebaseconfig causing a missing getty on the serial console after
base-config ran.
Regards,
Karsten
--
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ingo Juergensmann 2004-03-26, 5:36 pm |
| On Fri, Mar 26, 2004 at 04:38:05PM -0500, Joey Hess wrote:
> Ingo Juergensmann wrote:
> "Because nobody cared enough to do any work on it, despite numerous
> pleas for help."
Any work on what? I doubt that you can seriously mean m68k with that.
Citing Camm Maguire on debian-68k list (20 Feb 2004 23:12:45 -0500)
"Greetings! Just wanted to say a quick word of thanks and
encouragement to the m68k crowd -- I routinely get faster and more
helpful replies on these lists than I do from many lists pertaining to
much faster hardware."
(Message-ID: <54ekspjcjm.fsf@wisdom.m.enhanced.com> )
Maybe you ask on some other lists than the m68k lists, like someone else did
when complaining about m68k, but forgot to CC the 68k people before...
> We're well on our way to dropping mipsel and s390: d-i has never booted
> on mipsel let alone installed, and we have no working means of
> partitioning a s390 in the debian-installer.
Well, "dropping" a previously unreleased arch is something different than
really dropping a multiple released arch. I think "not releasing yet" would
be the appropriate term for s390 at least.
> http://www.debian.org/devel/debian-...er/ports-status
When you only refer to d-i as being release relevant, then I don't know why
all those people complain about packages not entering testing?
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-26, 5:36 pm |
| Joey Hess wrote:
> Ingo Juergensmann wrote:
>
> "Because nobody cared enough to do any work on it, despite numerous
> pleas for help."
>
>
> We're well on our way to dropping mipsel and s390: d-i has never booted
> on mipsel let alone installed, and we have no working means of
> partitioning a s390 in the debian-installer.
Incidentally, that's the *only* s390 problem -- if support for IBM
disklabels was present in libparted, the suspicion is that s390 would
suddenly Just Work.
> http://www.debian.org/devel/debian-...er/ports-status
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-03-26, 5:36 pm |
| Steve Greenland <steveg@moregruel.net> wrote:
> On 26-Mar-04, 14:07 (CST), Adrian Bunk <bunk@fs.tum.de> wrote:
[color=darkred]
[color=darkred]
> The kernel has someone with the power to say "Yes, this change goes
> in", and "No, this change must wait". No one in Debian has that power.
> Anytime someone tries to take such a position, there's a lot of whining
> about cabals and dictators and abuse of power.
[...]
Have you got references for this with respect to release managment in
Debian? Usually the cabal-thingy comes up in Debian when somebody is
doing stuff without communicating.
cu andreas
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 5:36 pm |
| On Fri, Mar 26, 2004 at 03:02:45PM -0600, Steve Greenland wrote:
> What management? That's exactly the point: Because Debian is a volunteer
> organization (or rather, because it's an unstructured volunteer
> organization), you can't tell people what to do.
That's BS and you know it.
> And every six months or so, someone comes in to say how we could make
> faster releases is only we did X, Y, and Z. Well, here's the thing:
> there's nothing to keep you from taking the packages, picking the ones
> you want, and making your own release. Since the problems not manpower,
> but only organization, this shouldn't be such a big deal, eh?
Ooh, you certainly zinged me there. Love it or leave it, right? Are we
still chanting that mantra?
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-03-26, 6:35 pm |
| Adam McKenna <adam@flounder.net> wrote:
[...]
> I'm not suggesting dropping support. Please learn to read. I'm saying that
> architectures with RC bugs that are not popular should not hold up the
> release. They can be released later. It will be up to the individual arch
> teams when the release happens.
You are aware that we do not have any infrastructure for a delayed
release of some archs or know how to do it?
What happens if foo is buggy on arm at time X when i386 releases? You
change the source and put it into the next point-release of i386?
You'd have to freeze the autobuilders to upgrading to sid. You'd have
to make the testing scripts smarter.
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 6:36 pm |
| On Fri, Mar 26, 2004 at 02:40:43PM -0600, Steve Greenland wrote:
> The kernel has someone with the power to say "Yes, this change goes
> in", and "No, this change must wait". No one in Debian has that power.
> Anytime someone tries to take such a position, there's a lot of whining
> about cabals and dictators and abuse of power.
It seems like Debian worked better back when there actually *was* a cabal and
people were actually able to get things done without long, protracted
300-post threads on debian-devel and/or debian-private. I have to imagine
that these threads, especially the NM threads, contributed significantly to
cabal member burnout.
--Adam
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chad Walstrom 2004-03-26, 6:36 pm |
| Please stop Cc'ing me on these...
On Fri, Mar 26, 2004 at 10:35:47PM +0100, Adrian Bunk wrote:
> I was talking about quality, not about speed.
>
> Looking at the last freezes, half a year might be a realistic estimate
> for the time between the beginning of the freeze and a stable release
> of the quality Debian is known for.
Say it ain't so! *groan* Wait, you said half a year, not a year and a
half. *whew*
--
Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 6:37 pm |
| On Fri, Mar 26, 2004 at 11:15:30PM +0100, Andreas Metzler wrote:
> Adam McKenna <adam@flounder.net> wrote:
> [...]
>
> You are aware that we do not have any infrastructure for a delayed
> release of some archs or know how to do it?
Yes, we do. We simply say:
"Debian 3.1 is released on these platforms:
Platform 1
Platform 2
Platform 3
etc."
The rest of the platforms will be there, just not officially.
> What happens if foo is buggy on arm at time X when i386 releases? You
> change the source and put it into the next point-release of i386?
Backport when possible and do point releases. If not, they'll have to wait
for the next release. This won't be much of a problem if we're on a shorter
release cycle.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-26, 6:37 pm |
| On Fri, Mar 26, 2004 at 02:44:14PM -0800, Adam McKenna wrote:
> On Fri, Mar 26, 2004 at 11:15:30PM +0100, Andreas Metzler wrote:
>
> Yes, we do. We simply say:
> "Debian 3.1 is released on these platforms:
> Platform 1
> Platform 2
> Platform 3
> etc."
>
> The rest of the platforms will be there, just not officially.
>
>
> Backport when possible and do point releases. If not, they'll have to wait
> for the next release. This won't be much of a problem if we're on a shorter
> release cycle.
Debian doesn't support upgrading with skipping a major release.
> --Adam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2004-03-26, 6:37 pm |
| On 26-Mar-04, 15:50 (CST), Adam McKenna <adam@flounder.net> wrote:
> On Fri, Mar 26, 2004 at 03:02:45PM -0600, Steve Greenland wrote:
>
> That's BS and you know it.
No, it's not. No matter how much any orders or begs me to work on any
particular item to help the release, I'm not going to do it, unless it's
specifically related to my packages. I simply don't have the time.
Several maintainers are on the record as not caring about releases at
all - unstable meets their needs.
Furthermore, unlike some developement groups, there's no history of
authority structures in Debian, and the constitution was written
particularly to prevent such from developing.
> Ooh, you certainly zinged me there. Love it or leave it, right? Are we
> still chanting that mantra?
I didn't say you needed to leave, I said you, or rather, those with all
the bright ideas about how it could be better, should just get together
a group and *do* it, rather than telling others what to do. Now's the
time to start. It's too late to change sarge, but if you came with a
proposal and an actual plan to achieve it for sarge+1, I bet there's a
lot of people here who would at least consider it.
> Love,
> --Adam
Kisses,
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2004-03-26, 7:35 pm |
| Karsten Merker wrote:
> The missing daily build on mipsel is due to breakage in two areas:
> keyboard support and proper serial console support (the latter is a
> problem for other architectures as well and problems in this area
> occur also on i386, if somebody actually uses serial console there).
> These issues are being worked on, but it needs some time. D-i works
> ok on mipsel besides these two things (just did a full install two
> days ago), but as long as these two are unfixed, having daily builds
> do not make sense.
Hmm, I had no idea mipsel was even being worked on.
I disagree that it's a good idea to not do build just because it doesn't
work. At least with a build the barrier to trying it, finding problems,
and trying to correct them is lower. Plus, we will know that it builds.
--
see shy jo
| |
| Steve Greenland 2004-03-26, 7:36 pm |
| On 26-Mar-04, 16:44 (CST), Adam McKenna <adam@flounder.net> wrote:
> On Fri, Mar 26, 2004 at 11:15:30PM +0100, Andreas Metzler wrote:
>
> Yes, we do. We simply say:
> "Debian 3.1 is released on these platforms:
> Platform 1
> Platform 2
> Platform 3
> etc."
>
> The rest of the platforms will be there, just not officially.
So all the un-released platforms with their apt.sources pointing
at stable are now screwed? No security updates, no way to install
additional packages that are consistent with what they already have,
etc. etc.
Better to be honest and drop them.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 7:36 pm |
| On Fri, Mar 26, 2004 at 05:21:59PM -0600, Steve Greenland wrote:
>
> No, it's not. No matter how much any orders or begs me to work on any
> particular item to help the release, I'm not going to do it, unless it's
> specifically related to my packages. I simply don't have the time.
There are penalties in Debian for not fulfilling one's responsibilities, just
like at any real job. Yes, we can play semantic games and say 'nobody can
force you to do anything', but if you don't do your work at Debian you will
be marginalized in favor of those who do.
> Several maintainers are on the record as not caring about releases at
> all - unstable meets their needs.
But our priority is not the developers' needs. Our priorities are our users
and free software. Our users need frequent stable releases. Developers
who state openly that they do not care about releases are in violation of
the Social Contract.
> I didn't say you needed to leave, I said you, or rather, those with all
> the bright ideas about how it could be better, should just get together
> a group and *do* it, rather than telling others what to do.
I can't do anything -- I don't have the power to freeze unstable or testing.
My only option is to appeal to those who do or start my own distribution.
You, apparently, would rather have me shut up or leave.
> time to start. It's too late to change sarge, but if you came with a
> proposal and an actual plan to achieve it for sarge+1, I bet there's a
> lot of people here who would at least consider it.
I'm not telling anyone what to do. I'm participating in a discussion.
Someone complained that we can't release often due to supporting so many
architectures. I offered a solution. If you don't like my solution, come up
with a better one.
--Adam
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2004-03-26, 7:36 pm |
| Ingo Juergensmann wrote:
> Well, "dropping" a previously unreleased arch is something different than
> really dropping a multiple released arch. I think "not releasing yet" would
> be the appropriate term for s390 at least.
s390 was released with woody.
> When you only refer to d-i as being release relevant, then I don't know why
> all those people complain about packages not entering testing?
d-i is the area with the most likelyhood to need to drop unworking
arches.
--
see shy jo
| |
| Ingo Juergensmann 2004-03-26, 7:36 pm |
| On Fri, Mar 26, 2004 at 07:20:08PM -0500, Joey Hess wrote:
> Ingo Juergensmann wrote:
> s390 was released with woody.
Uh? *bummer* I should install Debian more often...
Ok, then *drop* s390 before m68k... ;)
> d-i is the area with the most likelyhood to need to drop unworking
> arches.
OTOH, it is quite argueable why a non-working installer has been made a
prerequisite to get released, instead of release with what is working. And
what's the base of decision whether to release m68k with sarge because of a
working d-i? 1 working subarch? All working subarchs? 2? three?
That's quite strange over all, imho...
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-03-26, 8:33 pm |
| On Sat, Mar 27, 2004 at 01:34:18AM +0100, Ingo Juergensmann wrote:
> OTOH, it is quite argueable why a non-working installer has been made a
> prerequisite to get released, instead of release with what is working.
It doesn't work that way: b-f took substantial work to fix up for woody,
and I expect would take substantial work again to fix up for sarge.
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-26, 8:33 pm |
| On Fri, Mar 26, 2004 at 05:48:09PM -0600, Steve Greenland wrote:
> On 26-Mar-04, 16:44 (CST), Adam McKenna <adam@flounder.net> wrote:
>
> So all the un-released platforms with their apt.sources pointing
> at stable are now screwed? No security updates, no way to install
> additional packages that are consistent with what they already have,
> etc. etc.
>
> Better to be honest and drop them.
I don't think it's good practice to have one's sources.list pointing to
'stable'. I always change mine to the release name I want to use.
But anyway, this is very far offtopic and is not really productive, since
nobody is seriously talking about dropping architectures (yet). When that
time comes I will be happy to participate in a conversation involving
logistics. For now I will just say that I don't think the logistics are
very complicated.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-03-27, 1:33 am |
| On Fri, Mar 26, 2004 at 08:07:10PM +0000, Andrew M.A. Cater wrote:
> On Fri, Mar 26, 2004 at 07:00:23AM +0000, Andrew M.A. Cater wrote:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> No, and I could care less about them. If our releases are being delayed
> because we're spending too much time supporting dead platforms,
Which platforms are you singling out as the dead ones? Using what
criteria? Other than a lack of a viable installer for a few of the
ports at present, there are no ports I see which stand out as being
particularly less useful or releasable than the others, and certainly
not any that are consistently so over time.
The issue is not the quality of the ports, it's the *number* of them.
Coordinating 6 or 11 ports takes more effort than coordinating 2 of
them, regardless of which architectures they are. People are happy
to argue for dropping "doorstop architectures" or "dead platforms" to
get us to a release, but there's no real evidence that any of the
existing ports meet objective criteria that would justify excluding
them from the release. Well, in medical science one of the standards
for being "dead" is brain death; so maybe we should evaluate dropping
the i386 port, too, on the grounds that it's a brain-dead processor
design?
> we should drop support for them in our releases, or at least support
> them as secondary platforms which are released after the primary
> platforms.
But if coordinating 11 architectures takes more work than coordinating
2, maintaining 11 architectures *without* coordinating them takes even
more. I don't think it's at all realistic to support these other
architectures in Debian stable if they're not going to release together.
Now, maybe 11 architectures is simply too many to coordinate and still
be able to release at intervals that are acceptable to Debian as a
whole. If this is true (and I'm not personally persuaded of this yet,
though I do recognize that all other things being equal, increasing the
number of archs will slow down a release), it's something we'll have to
address. I'm not sure how it could be addressed without dropping
architectures altogether.
[color=darkred]
[color=darkred]
> The fact that Debian is a volunteer organization has nothing to do with the
> fact that we release slowly. I wish people would stop using this red herring
> argument. We probably have more manpower than the development teams of the 3
> largest Linux distributors put together. The problem, as in most large,
> ineffective organizations, is in management.
Given that d-i has been the holdup for some time, and is only now
finding its way into a truly usable and releasable state as of the
latest beta, I wonder what sort of managing you would like to see beyond
the repeated requests for volunteers to help with the installer? I
don't see that you've committed any code to the debian-installer SVN
repo, and I don't see that you've filed any current installation reports
regarding the installer (though I do see you're subscribed to the
debian-boot list, and must have done at least one test install -- so
thank you for that!). What "management techniques" would entice you to
do more to ensure our installer is releasable?
--
Steve Langasek
postmodern programmer
| |
| Steve Langasek 2004-03-27, 2:33 am |
| On Sat, Mar 27, 2004 at 12:16:22AM -0600, Steve Langasek wrote:
[color=darkred]
[color=darkred]
> Given that d-i has been the holdup for some time, and is only now
> finding its way into a truly usable and releasable state as of the
> latest beta, I wonder what sort of managing you would like to see beyond
> the repeated requests for volunteers to help with the installer? I
> don't see that you've committed any code to the debian-installer SVN
> repo, and I don't see that you've filed any current installation reports
> regarding the installer (though I do see you're subscribed to the
> debian-boot list, and must have done at least one test install -- so
> thank you for that!). What "management techniques" would entice you to
> do more to ensure our installer is releasable?
Er... of course, I managed to bungle the attribution here, and therefore
posed this question to Andrew instead of to Adam, the latter of whom
does *not* appear to have participated in the debian-boot list of late.
But the question still remains: if past calls for attention to the
installer haven't attracted enough developer time to have gotten it
close to releasable until now, what, exactly, would? And if you can't
answer this question, how would it ever have been possible to release
sarge faster than we already are?
--
Steve Langasek
postmodern programmer
| |
| Steve Langasek 2004-03-27, 2:33 am |
| On Fri, Mar 26, 2004 at 01:50:38PM -0800, Adam McKenna wrote:
> On Fri, Mar 26, 2004 at 03:02:45PM -0600, Steve Greenland wrote:
[color=darkred]
> That's BS and you know it.
Ok, then.
"Go work on debian-installer."
There, how'd that do?
[color=darkred]
> Ooh, you certainly zinged me there. Love it or leave it, right? Are we
> still chanting that mantra?
I think the exact wording is "put up or shut up."
--
Steve Langasek
postmodern programmer
| |
| Adam McKenna 2004-03-27, 2:33 am |
| And again, for the functionally illiterate:
PRIVATE MESSAGE.
POSTED PUBLICLY.
PLEASE IGNORE.
thanks.
--Adam
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-27, 2:33 am |
| On Sat, Mar 27, 2004 at 12:16:22AM -0600, Steve Langasek wrote:
> Which platforms are you singling out as the dead ones? Using what
> criteria? Other than a lack of a viable installer for a few of the
> ports at present, there are no ports I see which stand out as being
> particularly less useful or releasable than the others, and certainly
> not any that are consistently so over time.
>
> The issue is not the quality of the ports, it's the *number* of them.
> Coordinating 6 or 11 ports takes more effort than coordinating 2 of
> them, regardless of which architectures they are. People are happy
> to argue for dropping "doorstop architectures" or "dead platforms" to
> get us to a release, but there's no real evidence that any of the
> existing ports meet objective criteria that would justify excluding
> them from the release.
That's great. As I've been saying, this all supports my original point
that "too many architectures" is not a valid excuse for release delay.
> for being "dead" is brain death; so maybe we should evaluate dropping
> the i386 port, too, on the grounds that it's a brain-dead processor
> design?
Zing!
> Given that d-i has been the holdup for some time
Adrian's original post doesn't seem to indicate that. Is he lying?
> finding its way into a truly usable and releasable state as of the
> latest beta, I wonder what sort of managing you would like to see beyond
> the repeated requests for volunteers to help with the installer? I
> don't see that you've committed any code to the debian-installer SVN
> repo, and I don't see that you've filed any current installation reports
> regarding the installer (though I do see you're subscribed to the
> debian-boot list, and must have done at least one test install -- so
> thank you for that!). What "management techniques" would entice you to
> do more to ensure our installer is releasable?
The 'management techniques' I'm talking about have nothing to do with the
installer. They have to do with people exercising what little authority
they've been given and making decisions without needing a 300-post flamewar
around each one.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam McKenna 2004-03-27, 2:33 am |
| On Sat, Mar 27, 2004 at 12:34:58AM -0600, Steve Langasek wrote:
> Er... of course, I managed to bungle the attribution here, and therefore
> posed this question to Andrew instead of to Adam, the latter of whom
> does *not* appear to have participated in the debian-boot list of late.
>
> But the question still remains: if past calls for attention to the
> installer haven't attracted enough developer time to have gotten it
> close to releasable until now, what, exactly, would? And if you can't
> answer this question, how would it ever have been possible to release
> sarge faster than we already are?
Well, this is just a shot in the dark here, but maybe if sarge was frozen,
RC bugs in base were low, and d-i was the last thing that everyone was
waiting for, it'd help motivate people to get involved with d-i.
But hell, we've got to wait for Gnome 2.6 now. And mozilla 1.7 is coming out
soon too. And XFree 4.3.4, of course, and don't forget glibc 2.3.3, and foo
and bar and baz and all of the other software that keeps trickling into
testing while there's no freeze, allowing RC bugs to pile up with no end in
sight.. But if d-i was only finished, we could release! Damn it, why can't
we get more people to work on d-i??
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Branden Robinson 2004-03-27, 3:33 am |
| There's just one point in your mail I want to comment on at this time.
On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
> I reassigned from Debian over two years ago since I was not happy with
> the speed of Debian releases. Since then, I have the impression things
> got even worse.
I'd like to suggest that this demonstrates the efficacy of resignation
as a strategy for reform.
--
G. Branden Robinson | The only way to get rid of a
Debian GNU/Linux | temptation is to yield to it.
branden@debian.org | -- Oscar Wilde
http://people.debian.org/~branden/ |
| |
| Ingo Juergensmann 2004-03-27, 8:33 am |
| On Sat, Mar 27, 2004 at 12:16:22AM -0600, Steve Langasek wrote:
> Given that d-i has been the holdup for some time, and is only now
> finding its way into a truly usable and releasable state as of the
> latest beta, I wonder what sort of managing you would like to see beyond
> the repeated requests for volunteers to help with the installer?
Often it is said and stressed, that you can't demand something from
volunteers and that Debian is an effort by volunteers.
So, demanding something from users to get d-i work, is somehow "strange" for
me.
For the m68k part of this:
There are many, many DDs that are still owning a m68k box. So, when d-i
folks want that d-i is ported to m68k, they could either request accounts on
several m68k (buildd) boxes or some m68k boxes as well in whole. There
are from time to time donations of m68k boxes that wouldn't be a great
benefit as buildds, but for DDs to get things work, like d-i.
I tried to explain some time ago this year, what problems occur when we
would shutdown buildds and use them for d-i porting. The excessive adding of
new 060 buildds should take some load off the buildds for being able to shut
down some 040 buildds to be able to work on d-i.
If "someone up there" decide to use d-i as a prerequisite for release, that
one should have had an idea how to do that without depending on other
people. I'm quite sure that a m68k box could be sent to a d-i developer.
Granted, this might be more problematic with s390 boxes to be sent across
the country... ;))
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen R Marenka 2004-03-27, 10:33 am |
| On Sat, Mar 27, 2004 at 12:44:59PM +0100, Ingo Juergensmann wrote:
> If "someone up there" decide to use d-i as a prerequisite for release, that
> one should have had an idea how to do that without depending on other
> people. I'm quite sure that a m68k box could be sent to a d-i developer.
> Granted, this might be more problematic with s390 boxes to be sent across
> the country... ;))
Great, send me an amiga, because I sure can't motivate anybody to test
d-i on it (except Christian once).
--
Stephen R. Marenka If life's not fun, you're not doing it right!
<stephen@marenka.net>
| |
| Ingo Juergensmann 2004-03-27, 11:34 am |
| On Sat, Mar 27, 2004 at 08:00:10AM -0600, Stephen R Marenka wrote:
> Great, send me an amiga, because I sure can't motivate anybody to test
> d-i on it (except Christian once).
Oh, I offered my two A2000s for about two years on m68k-build for some sort
of this. Now I currently need both of it. One for setting up shaihulud and
the other for testing purposes like d-i. Once shaihulud boots and runs, I
could at least send you some leftover hardware such as accelerator boards.
Note that I spoke above about m68k boxes in general, not about particular
boxes. There were some mac offers last year on debian-68k.
Note as well, that I made a proposal to hardware-donations to list
wanted/needed hardware last year to work around those problems. I'm quite
sure when someone would read there that you need an Amiga, it would be much
easier to get such hardware near to you. Nothing happened so far to the
donations webpage, also there should have been some progress mid of last
year.
It's not so good to request hardware when you urgently need it. There needs
to be some overview in the long run what would/could be needed the next
months. You can consider this problem as an administrative problem which can
be solved by a mixture of communications, such as involving people that have
contact to users, donation managers, DDs and others.
When d-i needs some hardware to test or make progress in early porting
stages, d-i people need to communicate with others in advance. Then a
request for hardware could be listed on the donations page, people can look
around if someone has hardware to spend and such.
Realizing on Monday that you'll hardware xyz on Tuesday will just not work.
Depending on users to do more testing on development versions that exceeds
"please run this and reports if it works or not" won't work either. Ask
Christian for his experiences in that region with his kernel images. ;)
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Michlmayr - Debian Project Leader 2004-03-27, 11:34 am |
| * Ingo Juergensmann <ij@2004.bluespice.org> [2004-03-27 16:07]:
> Note as well, that I made a proposal to hardware-donations to list
> wanted/needed hardware last year to work around those problems. I'm
> quite sure when someone would read there that you need an Amiga, it
> would be much easier to get such hardware near to you. Nothing
> happened so far to the donations webpage, also there should have
> been some progress mid of last year.
The page has actually been created recently and will be announced
soon. See http://www.debian.org/misc/hardware_wanted and submit
entries.
--
Martin Michlmayr
leader@debian.org
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ingo Juergensmann 2004-03-27, 11:34 am |
| On Sat, Mar 27, 2004 at 04:58:12PM +0100, Martin Michlmayr - Debian Project Leader wrote:
> * Ingo Juergensmann <ij@2004.bluespice.org> [2004-03-27 16:07]:
> The page has actually been created recently and will be announced
> soon. See http://www.debian.org/misc/hardware_wanted and submit
> entries.
Ah, thx... *finally* :-))
But I'm quite confused by the content now:
Wanted: SGI Hardware
Who: MIPS porters
Architecture: mips
Specifications: Not specified
Where: Not specified
I guess you know why I'm confused? (and many others will be too, i think)
BTW: how about the announcement of $arch@b.d.o? ;)
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Michlmayr - Debian Project Leader 2004-03-27, 12:35 pm |
| * Ingo Juergensmann <ij@2004.bluespice.org> [2004-03-27 17:12]:
> Wanted: SGI Hardware
> Who: MIPS porters
> Where: Not specified
>
> I guess you know why I'm confused? (and many others will be too, i think)
No. This is about SGI hardware for individual porters, not buildd
(i.e. kernel work, d-i work).
> BTW: how about the announcement of $arch@b.d.o? ;)
Done a while ago, will be announced soon.
--
Martin Michlmayr
leader@debian.org
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen R Marenka 2004-03-27, 9:34 pm |
| On Sat, Mar 27, 2004 at 04:07:11PM +0100, Ingo Juergensmann wrote:
> On Sat, Mar 27, 2004 at 08:00:10AM -0600, Stephen R Marenka wrote:
>
[color=darkred]
> of this. Now I currently need both of it. One for setting up shaihulud and
> the other for testing purposes like d-i. Once shaihulud boots and runs, I
Actually, while I wouldn't mind having the hardware, I was really just
hoping to get you to test d-i on an amiga. :-)
--
Stephen R. Marenka If life's not fun, you're not doing it right!
<stephen@marenka.net>
| |
| Ingo Juergensmann 2004-03-28, 6:34 am |
| On Sat, Mar 27, 2004 at 08:06:43PM -0600, Stephen R Marenka wrote:
> Actually, while I wouldn't mind having the hardware, I was really just
> hoping to get you to test d-i on an amiga. :-)
Actually that's why I have two A2000s here - but both distributed in parts
in my flat... 
--
Ciao... //
Ingo \X/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-28, 1:34 pm |
| Ingo Juergensmann <ij@2004.bluespice.org> writes:
> On Sat, Mar 27, 2004 at 08:06:43PM -0600, Stephen R Marenka wrote:
>
>
> Actually that's why I have two A2000s here - but both distributed in parts
> in my flat...
I missed the start of the thread so excuse me for asking again if it
was mentioned:
Are there daily build m68k images and if where?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thiemo Seufer 2004-03-28, 2:34 pm |
| Goswin von Brederlow wrote:
> Ingo Juergensmann <ij@2004.bluespice.org> writes:
>
>
> I missed the start of the thread so excuse me for asking again if it
> was mentioned:
>
> Are there daily build m68k images and if where?
The debian-installer daily builds are linked from
http://www.debian.org/devel/debian-...er/ports-status
Thiemo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chris Cheney 2004-03-28, 8:35 pm |
| On Fri, Mar 26, 2004 at 03:44:08PM -0800, Adam McKenna wrote:
> On Fri, Mar 26, 2004 at 05:21:59PM -0600, Steve Greenland wrote:
>
> But our priority is not the developers' needs. Our priorities are our users
> and free software. Our users need frequent stable releases. Developers
> who state openly that they do not care about releases are in violation of
> the Social Contract.
I don't know if I have publically stated that I don't care about
releases, but with Debian releasing as slowly as it is stable is of very
little value to anyone unless they have systems roughly 6mo-1yr older
than the release itself. This is primarily due to the fact that the
installer is never updated with newer kernels. Personally I have been
unable to install Debian stable, using b-f, on my last ~ 6 systems. The
way I managed to install Debian was to use knoppix with debootstrap
which is definitely not friendly enough for a newbie or even the average
user. So Debian definitely needs to update its installer images as new
kernels are released, regardless of if it releases the whole
distribution faster.
Chris
| |
| Goswin von Brederlow 2004-03-28, 8:35 pm |
| Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> The debian-installer daily builds are linked from
> http://www.debian.org/devel/debian-...er/ports-status
A few comments before I burn the image and reboot:
1. /tools contains i386 tools, rather unneeded
2. No *.icon for the cdrom (disk.info was it?), the install or the doc
folder
3. install/amiga/StartInstall* scripts:
- No "ramdisk_size=16384" (ramdisk is 15361024 byte big)
- '-k linux.bin' should read '-k vmlinuz'
- '-r root.bin' should read '-r ../root.bin' (unix style path) or
'-r /root.bin' (AmigaOS style path)
- missing 'devfs=mount' or is that mounted on boot by default on amiga?
- nolangchooser in StartInstall but not the others
amiboot-5.6 -d -k vmlinuz -r ../root.bin root=/dev/ram ramdisk_size=16384 devfs=mount nolangchooser
4. minimum ram requirement to just boot seems to be >32MB, thats just
the ramdisk and the copy of it in tmpfs. Not counting the installer
itself.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2004-03-28, 8:35 pm |
| On 26-Mar-04, 17:44 (CST), Adam McKenna <adam@flounder.net> wrote:
> There are penalties in Debian for not fulfilling one's responsibilities, just
> like at any real job. Yes, we can play semantic games and say 'nobody can
> force you to do anything', but if you don't do your work at Debian you will
> be marginalized in favor of those who do.
Sure. But the thing is, I only signed up to maintain a few packages.
>
> But our priority is not the developers' needs. Our priorities are our users
> and free software. Our users need frequent stable releases.
Depends on the user. People with a room full of servers don't, in fact,
w | | |