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

Bug#587886: future of maintaining of the bootloader LILO



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.


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


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

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

 B. lilo should be retained in unstable.  Matt and Joachim are to be
    joint maintainers of lilo.  

If lilo is retained in unstable that does not mean, of course, that it
will be included in squeeze (or indeed any other relase).  If anyone
(William included) feels that the package has bugs which are so
serious that they should not be included in Debian releases, then they
may file bugs at a release-critical severity.  

If the bugs are determined to be release-critical (by the maintainer
in the first instance of course, but subject to review by the Release
Team and Technical Committee) then the package will not be released.

Does anyone disagree with this assessment ?

Ian.



Reply to: