On Tue, Dec 16, 2003 at 09:59:39AM +0100, Sven Luther wrote:
> On Mon, Dec 15, 2003 at 02:23:46PM -0600, Steve Langasek wrote:
> > On Mon, Dec 15, 2003 at 06:40:56PM +0100, Sven Luther wrote:
> >
> > > > > > > advi: Maintainer won't fix the RC bug until he fixes "other"
> > > > > > > problems, which he hasn't gotten around to. Packages which
> > > > > > > FTBFS should not be in sarge. Accordingly, remove it until
> > > > > > > the maintainer gets around to fixing his bugs. (or, yell at
> > > > > > > the maintainer with authority ;-)
> >
> > > > > > It's such a simple fix that it's only one-line and I don't know
> > > > > > if it's really worth it, but if it's going to be removed I've
> > > > > > got packages that require advi.
> >
> > > > > Why should it be removed ? There is really no reason for it, we
> > > > > are not near the release in any stretch of the imagination, we
> > > > > are at least month from being ready.
> >
> > > > Is it currently releasable? If not, then there's no reason to keep
> > > > it in testing, is there?
> >
> > > Yes it is, there is nothing wrong with the package, it is statically
> > > linked to ocaml, so didn't need to get rebuild for ocaml 3.07, which
> > > is why i didn't upload it.
> >
> > "Not buildable" -> "not releasable." This is not a new concept. There's
> > more at issue here than whether you as the maintainer believe it
> > would be trivial to fix this bug when you got around to it; we have
> > to support things like security updates, which demand packages which
> > conform to the interfaces published in Policy.
>
> It is only a question of priority. I believe not only that it is a
> trivial fix, but also that there are more important bugs for me to work
> on before this one, and also that there are more important bugs for you
> and others to work on than pestering me about this.
>
> If you are really serious about being ready for sarge release, whic in
> my eyes, is a joke today, then it is not enough to close seemingly RC
> bugs which in turn are trivial to fix, the overall shape of sarge need
> enhancements, and i personnally know that on my packages it is more
> important to fix some other things, maybe not marked as RC, but which are
> more important to to fix for the overall usability of the future sarge
> release.
The release will remain a joke so long as people don't consider RC bugs to
be serious. How one handles serious bugs can vary widely depending on just
what's wrong, how damaging it is to someone with the package installed,
and how difficult it is to fix (for example, a flawed Build-Depend that
can be worked around with -d might not warrant a new upload just for that
bug alone, if other stuff was going to be done within a week that would
make a worthwhile batch upload, for me), but it remains a bug that is worth
removing the package from the release for.
Being able to build a package is not merely a 'nicety', it is a primary
requirement of packaging. If it isn't possible, the packaging is
fundamentally *broken*. Maybe it's a break that's easy to fix, and maybe
it's a break that has a workaround, which makes it less crucial to upload
'today' (as opposed to 'at the end of the week') because it won't do
something horrible like lose user data or open a security hole (of course,
those bugs are of higher severity levels for a reason).
Usability is good, but it doesn't matter HOW useable a package is once
built, if it can't be built in the first place. The failure to build limits
the usability to '0' in practice.
> And since i am not having infinite time to dedicate to debian, i am
> forced to take priorities, and, sorry, but this trivial RC bug rank lower
> than some other stuff, which since it is not RC, will not attract the
> eyes of the bug fixers. In fact i believe that the example bug against
> advi is more important than the FTBFS, and i was going to upload the
> package with many of those fixes together, but since you are rushing me,
> i changed this.
If it is as trivial as you claim, I could have fixed it in much less than
the time it took to write the emails involved (and, for that matter,
written a short note to the bug saying "This is fixed in packaging CVS, and
will appear in the next upload, tentatively planned for late this week").
> Also, for sarge to be released ontime, there is the problem of the MIA
> status of the ftp-masters (well, they don't respond to email, they let
> packages sitting in the NEW queue for weeks if not month without any
> explanation at all and so on), which is putting an unneeded delay in the
> work of their fellow developers, if not treating them with contempt and
> rudeness, and stopping them from making everything possible to have sarge
> released on time.
A separate topic - and one that may need to be addressed - but unless
you've uploaded a version that requires queue/NEW handling to get the fix
in place, irrelevant (and, in fact, following up to the bug saying that it
was uploaded but will be a bit due to queue/NEW would be good, even if you
did have that situation).
> > Now, it could have been that this FTBFS bug really only applied to sid,
> > and not to sarge (because the build-dependencies were still available
> > in sarge); but if that were the case, I would have expected you to tag
> > this bug "sid" instead of developing a persecution complex because
> > people expect buggy packages to be fixed or removed. (And I've just
> > confirmed that the build-dependency is also unsatisfiable in testing.)
>
> No, this is not the case. It is just a question of priorities. I believe
> not many people use advi (yet), and i have had first to fix the example
> problem before advi becomes more usable. I have also been working on
> parted, and the powerpc kernel packages lately, which are needed for
> debian-installer, and removed a non-free part of the ocaml package which
> had crept unnoticed into main.
Priorities happen; I don't think anyone has claimed that it's a bad idea to
prioritize your time spent on Debian as you see fit. But if that doesn't
permit you enough time to take basic care of your packages, you need to
either find a co-maintainer, or orphan the packages in question, and let
someone who does have the time work on them.
> You just don't need to see a package in its singularity, but look at all
> the packages of a maintainer globally, if not all the packages of a group
> of developers, like the whole ocaml stuff, or the debian-installer stuff,
> or ...
No; actually, we do need to look at a package in it's singularity. to know
whether it is up to snuff. If it isn't, then we look at the rest of the
maintainer's information to decide whether it's a case of truly being MIA,
or just not having enough time to get to everything. Being MIA means all of
their stuff is up for orphaning, being out of time means folks should offer
to NMU, co-maintain, or adopt as appropriate.
> > > > Would you really prefer that packages only be removed from testing
> > > > at the very last minute, leaving maintainers no time to get a fixed
> > > > version back in?
> >
> > > Heck, if the ftp-masters had time to loose, then why not, but this
> > > not being the case, there are tons of more important things to fix
> > > than this, and i am sure that if i ask for the removal of the 2.4.20
> > > and 2.4.21 powerpc kernel today, this will not happen before weeks,
> > > while those are plaged with a local root exploit. Indeed i will do
> > > that this evening.
> >
> > Removing packages from testing is the domain of the release manager;
>
> Which is also an ftp-master, told me he was not busy with the intrusion
> when i meet him on irc two weeks ago and attracted his attention on
> the powerpc kernel and its implication for debian-installer. He denied
> knowing about it, while i have sent an email to him personnally about
> this and an email to the ftp-masters in general, which i find is unworthy
> of a debian maintainer, and makes me fear for the future quality of the
> sarge release and debian. I don't think we will be going anywhere, if we
> threat our fellow debian developers like shit.
Again, the ftp-master topic is a separate one (if a valid concern). Their
failure, if they're failing, doesn't change the fact that *your* package is
one with problems - and in this case, problems that do not appear to be in
any way caused by them (unlike, for example, a complaint about a failure to
update the powerpc kernel packages).
> > removing packages from unstable (and NEW queue processing) is the
> > domain of the ftp-master team at large. Unless you mean for the release
> > manager to prioritize the general queue management work above the
> > specific release management work, I don't see how the two are much
>
> Yep, or at least provide some feedback about the issue. Right now, they
> are like a black hole where nothing ever comes out, and the only way to
> get attention is to make a week long rant on the public mailing lists,
> which worked for aj some month back, but is lost on elmo, which has me
> black-listed anyway.
See above.
> > related. All the moreso when you consider that this request only showed
> > up on a public mailing list because the person proposing the removal is
> > not an ftp-master.
>
> No, i have been ranting on debian-boot for weeks, i have wrotten an email
> to them personnaly, have waited for over a month, but nothing seem to
> happen ever.
>
> And anyway, if the ftp-masters are too busy to handle even responses,
> then something is seriously wrong in the way we handle the archive.
See above.
> > > > > Time would be much better spent fixing one of the billion other
> > > > > RC bugs around, instead of this minor bug.
> >
> > > > It may be trivial to /fix/, but a FTBFS is not "minor".
> >
> > > dpkg-buildpackage -d fixes it. It is not really a FTBFS, just a
> > > broken build dependency. Anyway, i uploaded a fixed package now,
> > > including dpatchification, so you will all stop bothering me about
> > > this, and let me time to do real bug fixing. It is also in the ocaml
> > > SVN repository on alioth now, so anyone feeling like helping out with
> > > the other stuff can give a hand there.
> >
> > Your misrepresentation of "FTBFS" here is truly mind-boggling. RC
> > bugs do not become less important because they're easy (for the
> > maintainer) to fix; if anything, they become MORE important, because
> > this demonstrates all the more that a package isn't receiving the
> > minimal level of attention required from its maintainer.
>
> That is bullshit. I know perfectly well what an FTBFS bug is, but as the
> maintainers of my packages, i am more able to determine the relative
> priorities of the work which needs to be done on my packages, more so
> than some out-sider who sees nothing but the RC flag, and altough good
> intentioned, lacks the insight of the situation that the maintainer has.
It's still a FTBFS, which is, by definition, a release critical bug.
There's no two ways around it. That you choose to put it at a lower
priority of fixing is your call, but that choice may have consequences, if
that means it's sufficiently low that it doesn't get fixed in a suitable
timeframe.
> And BTW, do you think it is more important of me to fix this FTBFS
> bug, or, like i did, fix the parted FTBFS bug, which i did, and whose
> maintainer seems to be mostly MIA ? parted is used for debian-installer,
> without which we cannot release, while advi is probably used by less than
> 1% of our users, and nobody will really miss it if it is removed in the
> last minute. It is a question of priorities and time scheduling, and i
> always intented to fix this problem before the release (or the freeze
> if we still had such a time), that is if the RM will not again pull a
> rabit out of his hat, and suddenly declare that we are going to release
> tomorrow, like he did for woody, with the consequences that we know of.
It may well be true that the parted FTBFS is more important than an advi
FTBFS; in fact, it almost certainly is. That doesn't mean the advi FTBFS
should be ignored; as above, if you lack the time to get to all of your
priorities, consider having someone else help you reach the ones you
don't consider as important, if they have the time. It's been offered,
repeatedly.
> And seriously, i am a bit demotivated. I past hours and days compiling
> powerpc kernels, each build needing 6 hours of compile time, working
> around bugs and bad design in kernel-package, and loosing time i could
> otherwise have spent on other stuff, just to have the package die in the
> NEW queue limbo. What good is my participation into debian if my work
> is threated like shit ? Not to speak about the time last year when i
> suddenly, on the 30 of december, receive a mail from elmo telling me that
> the way we handle api changes in the ocaml package was not acceptable to
> the buildd, without further explanation, and i, instead of passing a nice
> sylvester, ask him for details, i get killfiled by him, and let to wonder
> in the dark ? And all this, just to see other packages do exactly the
> same thing a few months later ?
So maybe it's time to take a break; anyone can get burned out, particularly
if one is having difficulties in dealing with things. Nothing wrong with
that, and nothing wrong with saying, for example, "Going to take a two week
breather and avoid Debian work, please NMU critical bugs only, I'll be back
to fixing stuff soon".
> > If you're really this upset about being asked to not let an RC bug
> > languish in the BTS for over a month, perhaps you should consider
> > putting this package up for adoption -- or at least asking for help
> > with
>
> What a bullshit ! Sorry, but i am really pissed at the moment, but this
> is unimagineable. You clearly think the RC bug is not fixed because i am
> lazy and doesn't care, and asking for help is no solution either. Notice
> how a patch for the RC bug was provided, indeed an one liner, but not the
> more important issues of the package ? What good would it do to fix thie
> RC bug, apart from artifically diminishing the RC count so we make peolpe
> believe that sarge is of good quality ?
It means the package has one less serious bug. That may not make it
perfect; if you don't think the version in sid is acceptable for release,
file a bug tagged 'sid' against it, saying as much, and it'll be kept from
automatic promotion (granted, the better answer in the future - which
presumably wasn't the case when you first uploaded this - is to upload to
experimental if it isn't of release quality).
If the patch doesn't fix the problem in question, say so in the bug. If it
does, and you intend to do an omnibus upload of a week's worth of fixes all
at once (entirely reasonable if you have a bunch of minor things), just
email the bug and say so, once it's fixed in the local copy. But having
*any* RC bug in a package for a month without either a tag asking for help,
or a fix, much less one with a patch filed, says that you are *seriously*
lacking in time, to the point that your packages are suffering. That means
it's time to step back, and figure out what to do about fixing that.
> And at least i provide a response in a matter of a few days, if not
> hours, while other DD do not provide any _ANY_ response after more than
> month, i don't believe that.
Leaving a wishlist bug open for a month, with a response is days, is just
fine, for the most part. The same is not true for an RC bug.
> > it? You clearly have other Debian tasks you're working on which you
> > assign a higher priority to. This is no fault, but it's still important
> > that RC bugs be taken care of, even if the way to do that is to cede
> > responsibility for the package.
>
> Again, the RC ranking is arbitral. I personaly believe that other bugs of
> the advi package are more important, than this FTBFS, and was working in
> my spare time on fixing many of the bug reports against the advi package,
> not only a minor stuff for which a workaround is known and documented.
>
> Find me someone which is willing to take over the package, or even do
> co-maintainership, will you, and you will see that few persons are
> available, few persons have the knowledge of the ocaml language which i
> have, and the contact to upstream. In fact if such a person does exist,
> we would be happy to have him in the ocaml-debian team, and there are
> many tasks we cannot do for lack of maintainers interested in ocaml
> stuff. Orphaning or RFAing the package would only result in someone with
> less interest and less time than me to handle this package, so ...
So use the WNPP, or post to debian-devel and say "Looking for a
co-maintainer". I strongly suspect that saying "I've asked for help, or a
co-maintainer, because there's just too much to do, and nobody has stepped
up - but I'm keeping up as best I can" will generally get you a much better
response.
Orphaning it may well not be the right answer; I don't think you can say
anything about RFAing it except that so far, nobody with more time and/or
interest has stepped up. Saying that there is not, nor will ever be, anyone
in Debian with more time or interest than you in the package seems fairly
conceited, to me...
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU/NetBSD(i386) porter : :' :
`. `'
`-
Attachment:
pgpjXqP1ofc_Y.pgp
Description: PGP signature