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

Re: M68K boot floppies / CDs



Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> writes:

> When complaints about the inconsistent directories in disks-m68k surfaced
> (Dec. 20, I had never seen that my April updates were installed in June
> otherwise I'd have complained before) I checked the contents of these
> directories and described to Phil how this situation could be remedied
> (basically, merge 0606 and 0301 trees according to the map file). That was
> on Dec. 21, the problem being that I didn't CC ftpmaster and didn't file a
> bug report (those who know me a bit probably know that I abhor the BTS,
> especially in cases where not a simple package is involved). Next thing I
> hear is somebody I can't remember seeing any mails from before yelling
> 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.

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.

> 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.

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?

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.

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.)

Cheers, Phil.


Reply to: