Hi,
----- "Ian Jackson" <ijack...@chiark.greenend.org.uk> wrote:
> William, thanks for replying with your position and stating it very
> clearly. It's very helpful for us to know exactly what you think.
>
> William Pitcock writes ("Re: Bug#587886: future of maintaining of the
> > bootloader LILO"):
> > [Ian Jackson:]
> > > I've caught up on all of this now. I'm not sure I quite
> understand
> > > the position of the current lilo maintainers. In
> > > http://lists.debian.org/debian-devel/2010/05/msg00769.html
> > > William writes:
> > >
> > > it has pretty much been determined that kernel sizes have
> crossed
> > > the line past where lilo can reliably determine the payload size.
> > >
> > > William, to what are you referring ? Can you provide a bug number
> ?
>
> > Please read all of the bug reports on lilo. At least half of them
> > are related to this issue. Fortunately, payload sizes have dropped
> > below the watermark.
>
> I've done as you asked and looked at the bug reports on lilo. I
> reviewed the title lines, and where necessary the bug log, of every
> bug report to decide whether the bug could possibly be due to an
> image
> size limitation as you suggest. Of the bugs only #357567 could
> possibly match the description you have given so far and that only at
> a huge stretch.
>
> 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.
>
> > > William and Matt: Can you confirm that you still intend to remove
> > > lilo from squeeze ?
> >
> > Matt really is not part of this decision-making process at this
> time, as he
> > has never provided any insight into any critical decisions with this
> package.
>
> 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.
>
> > On a side note: the bug reporter needs to find something better to
> do with
> > their time. lilo has no future. Making a 23.0 release with nothing
> other
> > than *broken* patches does not give it one.
>
> "Release with nothing other than broken patches" is a very strong
> statement. Can you justify that ? For example, you could list the
> patches in Joachim's 23.0 release and explain why each of them is
> broken ?
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
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.
>
> Joachim, do you have a convenient list of the patches you have folded
> into 23.0 ? What level of technical review were you able to give to
> them ? What is your opinion of the general quality of those patches
> ?
>
>
> > Let the damned thing die already.
>
> I think it's clear from William's response that joint maintainership
> involving both William on one hand, and one or both of Matt and
> Joachim on the other hand, is not tenable.
>
I have no qualms with Joachim being involved in maintenance provided
that his work involves something more than applying random patches from
distributions.
Until such effort is demonstrated, any lilo uploads made by myself will
not be based on the 23.x release series.
1:22.8-9 will be uploaded at some point in the next few weeks to fix some
issues involving the new kernel bootloader policy.
> I think this leaves the Technical Committee with two options:
>
> A. lilo should be removed. In the meantime, William is to be sole
> maintainer of lilo. His promised request to the ftp team to
> remove lilo should be honoured, after which the ftp masters
> should
> not permit Matt and/or Joachim to reupload a new lilo package.
lilo will have to be removed someday unless it is completely rewritten.
Joachim's work has not shown that he is capable of taking on the task of
rewriting lilo. A new upstream maintainer of lilo should be able to show
that he has enough knowledge to get the job done. This has not been done
either.
Whether that time is during Squeeze's release cycle or not is irrelevant
in the regard that it will eventually have to be removed. An orderly
removal process with coordination from the release team is the proper way
of ensuring that lilo is removed cleanly from the distribution.
That said, I have not at this time committed to removing lilo from Debian.
Although there has been discussion, there has not been any action on this
at the time of this writing.
>
> B. lilo should be retained in unstable. Matt and Joachim are to be
> joint maintainers of lilo.
If the technical committee feels that putting lilo maintainership under
Matt and Joachim, that is fine, but it comes with severe risk to the QA
viability of the lilo package. I feel that orphaning (forceful or otherwise)
a critical part of the Debian system would be even more irresponsible.
Again, I must stress that I have made no attempt at this time to remove
the package, other than soliciting opinions on doing so. The following,
in full detail is my opinion on the matter:
Until I discovered extlinux, I started rewriting almost all of lilo's assembly
parts in C, using protected-mode like grub1. This corrected, and effectively
removed the need for the large-memory option. However, this has it's own
problems,
in that it depends on BIOS services still being available in protected mode...
this is true on many BIOSen, but...
At any rate none of the people who are participating in this are actually
putting Debian's QA interests at heart. extlinux is capable of replacing
lilo *right now* for new users. extlinux *should* be replacing lilo for
new users.
I have made the following points on extlinux, lilo overall, and lilo 23.0 as
compared to 22.8:
extlinux:
- is well documented;
- is actively maintained by the main person maintaining the x86 boot process
code
in Linux (H. Peter Anvin);
- does not have the design problem that lilo does;
- is relatively compatible with lilo configurations.
lilo:
- is poorly documented in regard to design rationale
(or in other words, consists mostly of documentation explaining what the code
is
doing, not why it is doing it, which is critical for maintainability);
- 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.
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);
- 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);
- changes elements of the buildsystem that do not need to be changed;
- fixes bugs that are already fixed in Debian 22.8 sources.
William
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
