Re: M68K boot floppies / CDs
> > Case in point: the current boot-floppies hassle. Let's rehash this
> once > again in more detail. > I wasted some time attempting to build
> new boot-floppies from the source > (the new slink source got uploaded
> to Incoming only days before the > release deadline IIRC).
>
> I apologize for that, but I would point out that we provide the CVS
> area for a reason. No code is every uploaded without it being in CVS
> -- in this case, as the slink branch. You know this very well. So
> the argument that you didn't have the source available isn't really
> true. I gave warning ont he boot-floppies list prior to building the
> i386 version as well.
I didn't bring the argument that the source wasn't available as much as
that the whole thing evolved into a last minute build again. I found the
correct source but it failed to build on the machine I could use, that's
all.
> > Didn't work on a potato machine (no big surprise, but I bet it
> > wouldn't have worked without changes even on slink).
>
> I don't know that this is a fair assumption. I am pretty sure I
> didn't break anything for m68k in the minor updates I did for 2.1r4
> boot-floppies. So if it was broken, then it must have been broken in
> the boot-floppies source prior to 2.1r4.
It wasn't fair, I agree. And I can't prove it anyway. Take it as my
expectation of things suddenly breaking, based on my experience with the
slink boot floppies from early last year.
> I don't know what I can do about the inconsistent involvement of
> porters in boot-floppies. Many porters make changes but don't bother
> to commit the changes to CVS or even send me patches. I've begged and
> pleaded for porters to help me support other architectures better --
> in a lot of cases, this process is working. In cases where it's not
> working, please tell me what I can do to improve it, if anything.
Adam, you probably know that I did check in quite a number of changes in
the past. The exception being hacks that I used to facilitate thiks like
restarting the build without make clean, doing the packaging step on its
own (without going over make clean), and some things related to the ever
changing 'm68k doesn't have package x use y instead' (think slice here).
While keeping my changes to the real code (few outside the main
Makefile) committed to CVS, there were multiple occasions where things
broke when I ran CVS update (most notably, hacks with the special libc
build procedure). Maybe I was over pessimistic assuming this had happened
again in the 9 months since my last CVS update.
So why did I fail to keep in sync with the CVS tree? Two reasons: I had
more than enough to do in the lab between April and August to wrap up my
postdoc project in Berkeley. After the slink release, I made perfectly
clear that I could not afford to spend more time on boot-floppies, or any
other ongoing project, and kept the slink system on a Mac in the lab
mostly for emergency security update builds. That option went out the
window even before I left Berkeley due to a disk crash (and I've said
that, too).
About the inconsistent involvement of m68k porters in the boot-floppies
team: every one of us five that has time to spend on the project needs to
wear multiple hats in order to just keep up with security stuff and
unstable. On my part, there's no time to continuously take part in the
boot-floppies development (and no hardware on the side). I can't speak for
the others but judged from the enthusiasm on the 2.1r4 occasion it seems
similar. We need new people on the m68k project to improve this.
What can be done to improve it, outside of out small circle of m68k
porters? Well, there is the build server (kullervo.informatik.uni-erlangen.de)
with -currently- 3 GB of free disk space. The stuff can't be tested there,
but that needs to be done on each subarch separately anyway. This would
help ensure that boot-floppies do compile on m68k at least (but it's only
an option for unstable).
Sorry if ths sounds like pushing the problem to someone else, but it's the
only solution I see. Speaking for myself only, others may have a different
opinion.
Michael
Reply to: