[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: M68K boot floppies / CDs



> > bloody murder. To be fair, Phil tried to follow my instructions but it
> > didn't work out (maybe because of things like confusing .lha and .lzh and
> > such).
> 
> I think I could have done the whole thing in another 10 minutes as it
> happens, I just misunderstood that I was meant to be doing a merge of
> parts of the old and new directories.  By that time I'd deleted the
> old directory though, and it did occur to me that I really probably
> shouldn't start changing the archive before making CDs unless there's
> no prospect of the fix being applied to the master site.

Yep, I should have been more detailed in that mail perhaps. It sure wasn't
misleading on purpose :-) 
 
> I'm sorry you don't like the BTS Michael, because the lack of a bug
> against ftp.debian.org just made me enter the ``Submit a bug, and
> wait'' cycle once again.  I really don't think you can blame the
> ftpmasters for not fixing things like this, if you don't report a bug.
> Since ftpmaster is now a shared job, I'd imagine the only way of
> keeping track is by checking for open bugs.

Hindsight is always at least 50/50. I did not expect such a messup with
the 'byhand' install because I hadn't had such massive trouble before. I
still don't understand what caused the April update to first be rejected
(and drift out of eyesight), then be installed in bulk into a completely
pointless directory that happened to be named like a sensible
boot-floppies snapshot would. 

I have to concede this kind of stuff happens, and just got #53967
acknowledged (I refered to your bug report from Dec. 29 so Guy is aware
that this is really the same bug). I hope you didn't file another report
after that one? 
 
> > The end of it: everybody's frustrated, and less willing to put in the
> > necessary effort than before. For my part, Debian has gotten way too
> > complicated and slow to react almost to bother. I've spent more time on
> > this discussion today than I could reasonably afford. But we need to find
> > out what to improve next time, so please suggest something...
> 
> Am I right in thinking that the m68k boot-floppies problem was not
> reported as a bug before the release?  If it had been reported as an
> important bug before release, presumably it would have been fixed.

That's right. I made another upload to take care of the missing files
instead, and that got delayed, unfortunately. Next time I won't hesitate
to first file a bug to get the FTP archive fixed, then upload an update
to get the archive changed (and probably broken) once again. 
 
> Does this mean that the m68k crew don't consider this important, don't
> like the BTS or just thing that the BTS is too i386-centric and fails
> to serve other architectures properly?

It's just me. I hate the BTS because it gave me a hard time when I had to
file bugs using Netscrap's messenger, and would choke taking MIME
separators for valid fields. My bugs vanished into thin air (I reported
that behavior, don't know if it was ever fixed). I hate buerocratic
procedures (bloody ironic, as a German, isn't it) and rather work around
something in these cases. It's not a problem with poor support for other
architectures these days, really. 
 
> If this isn't important, then I'd guess that's because the CD images
> are not that important either, and you're all using the ftp sites or
> some such.  That's fine with me, but I'd like to know these things so
> I can avoid wasting my time building images that are not getting used.
> 
> Perhaps it's not important because nobody actually uses stable m68k,
> because there are fewer of you and you all run unstable, say.  If
> that's the case then there really is no point making these CDs, since
> unstable snapshots would be much better for everyone.

We need to distinguish two things here: I don't really rely on CD images
as I can just as well install everything off the net or use unstable. The
same is probably true for the other m68k maintainers. 

The users, on the other hand, often need CD images and mostly use stable.
At this time, though, there just are not enough maintainers to properly
support stable. And getting updates to the boot-floppies rejected because
they are not security related neither helps the users nor improves my
motivation to invest further work into an apparently futile effort that
I'm not over likely to benefit from. 
 
On your implicit conjecture that we don't really care: Speaking for me,
I've been working on Linux-m68k and Debian/68k for a long time. Neither
the longest time nor the most work (Roman probably deserves that
designation), but I've done a big chunk of the m68k Mac kernel support,
the Mac boot-floppies stuff, and the Atari and Mac install guides. I was
glad to finally see m68k CDs (the m68k machines were the only ones running
slink at last March's LWE) after we missed the boat again and again
before. So I don't think it's fair to suggest I just don't care about the
users' needs. But the continuing experience of working for the scrap heap 
sure did contribute to my disillusionment with Debian as a procedural
body. The fact that we still work with more or less the same number of
people for a growing number of users further adds to this. I suppose it's
about time some of the users start taking over. Enough said. 

> If it is important to have stable m68k CDs, then we need to modify our
> use of the BTS to reflect that, or perhaps ensure that someone that
> uses m68k (and each other architecture) attempts to make CDs prior to
> releases, so we can find these sorts of problems.  (B.T.W. CD building
> also highlights unmet dependencies, which is another problem that
> keeps recurring.)

We did just that prior to the original slink release. Chris Lawrence twice
burned CDs from the pre-2.1 stuff that he sent to me and other testers,
and the feedback from his test builds and our test results went into
the debian CD scripts. Our experience with boot-floppies and the CDs went
into the powerpc boot-floppies for example. That was done largely without
the BTS being involved, at least on my part.
It would be nice to run test builds with potato again in the near future
but Chris has no working Amiga anymore, and I have no Debian system on our
CD recorder (and no local mirror). 

Building boot-floppies was another nice way to find unmet dependencies
BTW. The problems I found were integrated into the boot-floppies
(arch-conditional definitions of the package install profiles and
tasks) but didn't make it to the CD maintainers from there it seems. 

	Michael


Reply to: