Bug#587886: future of maintaining of the bootloader LILO
William Pitcock writes ("Re: Bug#587886: future of maintaining of the bootloader LILO"):
> Hi,
> > If you still think that there is some really hard to fix image size
> > limitation with lilo, could you please provide a more specific
> > reference.
>
> For the most part, it is worked around by using large-memory, but this is
> a bandaid, and is BIOS-dependent.
I see. Well, really, I don't see. Could you please tell me where I
could read more about this problem ?
> > The question is now before the Technical Committee, and our
> > decision-making process will include consulting with Matt and Joachim
> > and anyone else relevant. So Matt _is_ part of the decision-making
> > process at this time.
>
> This is a complete abuse of the tech-ctte process initiated by Joachim who
> wishes to force his LILO 23.0 tree down my throat.
The purpose of the Technical Committee is precisely to deal with these
kind of disputes. To invoke the TC is not an "abuse".
Your emails on this subject in general seem to me to come across as
very hostile, and you have been quite insulting towards Matt and
Joachim. Now perhaps you are right and they don't have the skills and
aptitude for this task, but if that's the argument you are relying on
then (a) you should be able to put it forward more politely and (b)
you'll have to provide some clear evidence for us.
> The following commit shows blind importation of patches without cleanup to
> ensure proper maintainability:
>
> https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=lilo/lilo.git;a=commitdiff;h=f50e3fc18b100fe886270ffdf9c7e0e6d18e2cde
I'm afraid without more context I can't see whether this is a good or
bad change. We're not generally bootloader experts here.
> There are many more commits like this. Contrary to popular opinion, I have
> been paying attention to Joachim's work. I should emphasize that in my mail,
> I told Joachim that he has to produce a lilo release with actual merit. 23.0
> does not have actual merit.
It's quite possible that there are things wrong with Joachim's work.
But your explanations so far aren't very convincing at least to me.
> I have no qualms with Joachim being involved in maintenance provided
> that his work involves something more than applying random patches from
> distributions.
Your emails to him and to Matt seem very hostile, though.
> lilo will have to be removed someday unless it is completely rewritten.
Can you please explain why that's the case ?
> - does not work reliably across all BIOSen when in large-memory mode;
> - does not work reliably across all BIOSen when NOT in large-memory mode.
Are these problems reflected in bug reports in the BTS ? Because if
so I didn't seem to find them.
> lilo 23.0 as compared to 22.8:
>
> - removes a lot of cruft that is no longer applicable
> (this IS a good start towards improving maintainability);
Earlier you said this:
Making a 23.0 release with nothing other
than *broken* patches does not give [lilo a future]
Ie, you implied that that was what Joachim has done. However, now you
agree that he has done some good things. Exaggerating the alleged
misdeeds of the people you are having a disagreement with does not do
you any favours.
> - adds patches from Fedora and OpenSuSE
> (without explaining rationale for adding the patches, most of the
> patches 'work around' bugs rather than correcting the actual design faults);
Would you care to give an example ? I appreciate it might be too much
work for us all to go through every such patch and have you explain in
detail what the real problem is and why the applied patch is not
correct. But I think you should be able to point to an example or
two.
> - fixes bugs that are already fixed in Debian 22.8 sources.
Surely that is exactly one of the things an upstream maintainer should
be doing ?
> - changes elements of the buildsystem that do not need to be changed;
That seems like a bikeshed issue to me.
Ian.
Reply to: