Re: Bits from the RM
On Mon, 2003-12-01 at 15:45, Anthony Towns wrote:
> Having critical, grave or serious bugs open for an extended period is simply
> not acceptable.
>
> Nor is it excusable. While it's possible that you mightn't have the skill
> required to fix some security bug, or mightn't have the time to respond
> to a bug report, you _do_ have both the time and the skill required
> to file a bug report either orphaning the package, or requesting its
> removal from the archive.
Can "requesting removal from archive" be automated, to occur say after 3
weeks of inactivity of rc/grave/serious bug?
As a DD, I assume there is some pride and/ or utility in having your
package in the archive. This would give you a little "no nonsense"
wakeup call I would guess. And if *even the packager themselves* do not
have enough pride/ utility value in worrying at that point, then it is
likely better to get removed.
> Nor *should* it be excused. You might think the exim bug's not worth
> worrying about -- after all, exim4's what people should be using, and
> multiline Conflicts work with most tools at least, and hey shouldn't we
> think about fixing the things that don't work anyway? So who cares? The
> reporter of the bug for one. The people affected by it for another. The
> people who look at the RC bug list and decide "Oh, there are so many
> bugs already, there's no point filing another, it won't ever be fixed",
> and all the people affected by those bugs. The people who look at the RC
> bug list and decide that there's too much crap their to ever hope to make
I agree the number of RCs should come down definitely.
If automatic "request for removals" are made, they should be very
prominently advertised, so that it is easy for the users of any
particular package (who might also have pride/ utility invested in the
package) can know to do something if they want to avert the pending
situation. That could include simply emailing the DD packager (if I got
four or five emails from different users, it would tell me my work is
valued and I have a userbase worth looking after), or if they're
possibly programmatically inclined to try to patch. And (as DD again)
getting even a bad patch can be an even bigger motivation to "do it
right" for your userbase.
And if none of that happens, the package really, really should be
removed from the archive. Is there a conspiracy against anything that
might remove packages from the archive? :)
> a dent in. The people who would be willing to fix that bug, but don't want
> to have to deal with annoying the maintainer by doing an unauthorised NMU,
> or waste their time waiting for months for a an answer that'll probably be
> "no", and who spend their time doing things other than Debian work.
>
> So, seriously, if you're inclined to think of the current state of much
> of the software we're distributing as anything but a mortifying shame,
> please correct your outlook.
> From how we're going at the moment, the best timeline we can produce
> is something like this. We'll need to reduce the RC bug count to 0 for
> at least major pieces of software like KDE, glibc and X. Each of those,
> or their dependencies, have had various RC bugs open almost continually
> since woody was released, so from that basis we can extrapolate to those
> packages continuing to have RC bugs for the next year and a half, and
> thus that we won't release for at lesat that long. Worse, those packages
> are the ones that most people like to avoid NMUing, so there's not much
> we can do on that score, either.
What happens if say there are simply not enough people interested in
GNOME for example, and the RC counts rise, and rise at an increasing
rate, and we never release again?
I guess my question is, what does it take for a package(s) to get
removed?
> is that we can re-introduce "0-day NMUs", or some similar policy to get
...
> Another possibility is to just drop packages that aren't maintained well
> enough. While this is somewhat attractive, it doesn't really serve our
> users any better than saying "Why don't we just lower our standards?"
I feel it might be the best whip there is - to start dropping packages.
Whip the users - turn them into developers I say!
The reason being, I think we've shown a few times now we can't whip
ourselves. Of course, a little package dropping might change that...
> Which is another possibility of course, and one that a number of
> maintainers seem to like when some of our policies cause problems that
> they don't want to bother fixing. It's certainly possible, and we have a
> procedure for it: argue your case on the -policy list. But concurrently
> with that, you *still* need to fix your packages -- if you're convincing,
> you can then remove the fix later, if you feel the package is better
And this is what? an observation and nothing more. It might be useful
for some, I don't know. (Me personally - "you naughty DD, not fixing
your RC because you disagree with policy - shame, shame!" - just doesn't
do anything for me. I need a whip :)
> off without it. In general, arguments that certain classes of RC bugs
> shouldn't be considered RC but should still be considered bugs aren't
> going to be taken very seriously unless you've demonstrated that you're
> not just trying to be lazy -- generally by fixing all such bugs first.
Allow people to demonstrate that they are lazy, and they will. Start
dropping packages! In fact, we could have 0-day drops!! Aarrghh, what
I'd give for the RMs power!
> The other alternative is to do a better job maintaining our packages on a
> continuous basis. I think that's both worthwhile and possible.
>
> First, let's review what we should be expecting of ourselves. In the
> normal case -- when you're not on holidays, or having family crises,
> or overloaded with work, or, for that matter, fixing compromised Debian
> servers -- do you think it's desirable and possible to:
>
> * do whatever it takes to fix or work around security bugs within
> a few days or at most a week of their discovery -- even if
> that means disabling some important features entirely
I like this one.
> * for confirmed bugs with a known fix, upload a fixed package
> within a day or two of the patch been sent to the bug log
> * respond to bug reports within a day or two indicating whether
> you understand the bug, or need more information, or what
> * acknowledge NMUs within a few weeks, and integrate the changes
> into your own source
Or... ??
These 3 are very similar in nature.
There must be a stick (or a carrot for that matter); as I mentioned
above, I don't think mere observations or recommendations of this kind
are enough to change demonstrated DD behaviour.
> * rather than simply compiling upstream sources and putting the
> result in a .deb, make sure that the resulting package fits
> into a Debian system -- that it has the right directory layout,
> that the programs are documented with manpages, that it's
> internationalised, that it works out of the box, etc
Are we DD's? Are man pages required? etc?
> I have no idea how to argue that those things are desirable because I
> can't imagine why anyone would think otherwise -- if you really think
> some of them aren't (and you're a Debian developer, not a random crackpot
> of course :), talk about it on -devel.
Can't speak to the random crackpot thing :), but I feel we need to start
kicking some serious DD butt.
> Whether they're *possible* or not is another matter. But given that
> they're desirable, we should certainly try to achieve them, rather than
> make excuses so that we don't feel guilty about not achieving them.
<eyes light up> Now there's a possibly brilliant idea! Are there
specific ways we could make developers feel guilty about not fixing
stuff? </>
> First, I don't really have the answer to this -- while you won't find my
I do. Whips. Guilt. Remorse inducing punishment! Everything we can think
of, definitely.
> packages in the RC bug list, I do have plenty of open bugs, and plenty
> of my packages have had NMUs at various times. So with the proviso that
> you should be careful to not make things /worse/ than they already are,
> it's definitely worthwhile thinking about other things that could keep
> our packages well maintained all year.
>
> That said, let's get on with it.
>
> One approach is to deal with your packages more frequently. If you don't
> do an upload for a while you let two bad things happen -- one is you let
> a bunch of bugs accumulate and feel obliged to fix them all at once, which
> is more work, and just encourages you to procrastinate more; the other is
That is a perfect argument for relatively quick "your package is queued
for removal" messages - that should catch the procrastinators. At least
those who for some reason value their [package|users|debian].
> that you become less familiar with the code, especially if you get NMUed a
> few times, and changes become harder to do.
All the more reason to encourage ourselves to get stuff done - whatever
way it takes. (I might relent with a mechanism for a developer to
"postpone" - but not for long (eg. a week) a removal; and two weeks
might require RM approval! :))
> A similar approach is to fix things quickly -- if you get a bug about some
> spelling mistakes, or a simple patch to apply, do them straight away.
How can this be "encouraged"? How do you change entrenched human
habitual behaviour?
> If some changes you make cause some bugs, fix them as soon as they're
> reported, so you can forget about the package for a while with a good
> conscience, rather than having it sit in the back of your mind distracting
> you. It's not that hard, doesn't take that much time, and is a lot more
> fun when you can tell yourself "ha, I bet Microsoft wouldn't have fixed
> that bug within ten minutes of it being reported". And it's even better
> when users tell you.
Now there's a point - perhaps we could have an option <alert - talking
not coding> for users upon installation, to be notified of all installed
packages that are tentative for removal (at any point in the future) -
like an apt setting or something that, when set, auto-subscribes to
buglist for installed package (each, one by one), and unsubscribes on
apt-get remove...
Again, the idea here is to make it as simple as possible to get those
with a vested interest, and willingness to hear, to be in on the loop.
> Another idea on the motivational front is to make sure you remember why
What was that sorry - I forgot again :)
> you're involved in Debian -- presumably for most of us it's because
> it's fun, or because we think it's the best of all possible ways of
> developing a good operating system. If so, you might want to look
> into doing some things that are fun or impressively useful, rather
> than primarily focussing on bugs and policy conformance. You might
> want to look into managing your packages with arch or subversion (see
> {arch,scn}.debian.org), or you might like to look into managing your
> package's configuration files with ucf, or you might like to look into
> setting up SELinux, and including a SELinux policy with your packages,
> or writing some automatic test suites that get run from debian/rules, or
> anything else which is new and interesting (and doesn't actually *detract*
> from the quality of your packages, of course!). If you're here because
> you think Debian's fun, remember to make sure you're actually enjoying
> yourself, and there's a good chance that your bug count, RC and otherwise,
> will drop as a side-effect.
Many good ideas (amongst even more I should say - please don't get me
wrong, the ideas are useful for *those wishing to deal with their
procrastination*).
> The final suggestion for maintainers I'll add here is to get help.
>
> Okay, the fifteen year olds in the audience can stop snickering
> now. Thankyou.
>
> We've often downplayed asking for help in favour of encouraging people
> to *offer* to help, but since we're having problems, it's important to
> try everything we can to overcome them. One of the more effective way
On an I've experienced it note - the gang on debian-mentors@ldo is great
for packaging queries - friendly bunch (mostly :).
> of getting useful help (as opposed to someone who says they'll help,
> then does absolutely nothing), is to find some specific areas (or tasks)
> that could use help, and then be specific in your request. There are
> plenty of ways to do this, but at the moment, I think the best way is to
> file a RFA (which we're redefining as "Request For Assistance" instead
> of just "Request For Adoption") report against wnpp, with some decent
> information as to what assistance do you want (someone to take over the
> package entirely? a co-maintainer? someone to work on some particular
> area? someone to fix some particular bugs? what skills are required?).
>
> And on the other hand, when you're offered help that is actually useful,
> try to encourage it, rather than complaining that the help wasn't perfect
An important point to remember. (Thanks going a long way.)
Another - when you're offered help, respond to it with a status too
(shows you actually using the help).
> in every possible way. Also, make sure that you're using the help in
> a useful way -- if you've got a team working on a package, make sure
> everyone knows what they're meant to be working on, make sure everyone's
> got something interesting and worthwhile to work on, and make sure that
> everything that needs to be worked on is being worked on. Generally,
> this doesn't "just happen", so one of the jobs needed on most teams
> is a leader (or a captain, or a manager, or even a secretary) just to
> make sure everyone knows what they need to do. If you don't have this,
> make sure you get it, even if no one wants the job.
And if you're capt'n - givem 'eaps!! (well, may be let up very
occasionally...)
> Now, if we were able to leave all this stuff up to maintainers, we
> probably wouldn't have this problem in the first place. So, we also
> probably need to make we've got better support from behind the front-lines
> than what we do at the moment.
More automated whips!
> First, the air support:
Yee-haw!
> 0-day NMUs will be open again from next weekend,
> 'til the start of the new year; that is to say from 2003-12-06 00:00:00
> UTC to 2004-01-12 00:00:00 UTC. Same rules as always: make sure your
> upload is correct, change the minimal amount of stuff possible, work
> with the maintainer if at all possible (ie, file the patches in the BTS,
> help the maintainer do the upload rather than doing it yourself, make sure
> your patches would be approved by the maintainer), make sure you support
> your NMU afterwards and fix any new bugs that appear as well. Hey, why
> not sum it up in a poem? "Get it right, be polite, but upload tonight."
>
> Second, artillery. Over the next little while, we'll hopefully have
Ahh, so you've taken the "be nice up front and catch people off guard
when the real firepower comes in". I like it.
> a bunch of "RFA" bugs being filed. Please make sure you help on these
> wherever you can -- and this applies to people in the new-maintainer
> queue as well as people who are already developers. We often focus more on
> ensuring that everything that's been made a .deb can get put in Debian,
> rather than that everything in Debian is maintained at the highest level
> possible. That's akin to fighting a war on many fronts, and it seems
> to have resulted in us spreading ourselves a bit too thin. So let's
> thicken ourselves up -- as well as having people hop around fixing RC
> bugs in different packages every day, it's helpful to have people stick
> around and help particular maintainers on a longer term basis: whether
> as user support, a patch bunny, a backup maintainer, a co-maintainer,
> or whatever else is appropriate.
>
> Third, personnel deployment. As a complement to the "Request For
> Assistance" stuff, we're also creating a new wnpp heading, OTA for "Offer
> To Assist". The usual way to "offer to assist" a maintainer is by sending
> a private email, and if you prefer, you can still do that. The reasons to
> use an OTA bug instead are: (1) to track the maintainer's responses -- if
> the maintainer doesn't respond to either accept the offer, or to indicate
> why it's not needed or what is needed, then it's easy to see that there's
> a problem; (2) to distinguish areas where plenty of assistance has been
> offered, and where not much has been so people can work out where their
> help is more likely to be appreciated; (3) so people see other people
> offering help and it getting accepted and follow suit, rather than it
> happening behind closed doors as some unfathomably mysterious process.
> OTA bugs should be closed when the offer's accepted, or the submitter is
> no longer willing or able to make the offer; but not when the offer is
> rejected. OTAs are *offers*, not demands, if the offer is rejected, you
> should aim to figure out what you can do that will be accepted, not pressure
> the maintainer into changing his/her mind.
>
> Fourth, morale. There's no point making a small contribution to a
> package, then annoying the maintainer so much that he gets fed up with
> Debian and quits, thus removing all possible future contributions he
> might make. Similar things, of a lesser scale can suck too. Sure, have
> disagreements, be passionate, stand up for what you believe is right,
> etc, but do try to make sure the people your trying to help -- users,
> fellow developers, etc -- actually enjoy your company most of the time.
>
>
>
> The key issue here isn't one of ability -- we have more than enough
> skillful, dedicated hackers to stomp the bugs in the BTS -- it's one
> of action versus inaction. The above tries to avoid any really drastic
> changes to how we operate, but I'm hopeful that it will still be enough
> to increase our regular tempo so that we don't need multi-week rounds
> of NMUs to keep our bug count under control.
>
> Fallback plans are important though, and in this case if we're not able
> to get in a position where maintainers are able to keep control of their
> RC bug count (which is to say, keep it at zero), we'll have to consider
> more drastic measures. An obvious one is to transfer packages that aren't
> being maintained at an acceptable level to new maintainers, whether the
> existing maintainer likes it or not. Some simple measures for this are
> things like "has this package had any RC bug open for more than a month or
> two", or "has this package had an RC bug open for more than a week or so
Are there plans to automate such things?
> without any response". Even if you ignore all of the preceeding message,
> you might like to ensure that those two criteria never apply to you.
>
>
>
> So, some ideas to focus on:
>
> * Make sure you're having fun.
> * Make sure your RC bugs are resolved.
> * Make sure your packages are amazingly impressive:
> - current with the latest upstream release
> - easy to configure, setup and use
> - work everywhere out of the box
> - well integrated into Debian
> - any known fixes have been applied
> - feature requests and patches have been forwarded upstream
> - you're managing your package with "best of breed"
> tools, you've got test suites, whatever else
> - all your bug reports are dealt with (reply to them,
> verify them, forward them, fix them, close them as
> appropriate)
> * Do some development instead of just maintenance. Fix some bugs
> instead of doing development. Change things around a bit.
> * File RFAs to ask for help if you need/want it. Respond to OTAs
> if you have any.
> * Make sure any packages you use or rely on don't have any RC bugs.
> * Respond to any RFAs you can help with. Send out OTAs if there's
> something you could usefully work on that the maintainer would
> appreciate.
>
> And, briefly, the two things we need to focus on in order to release are
> (as always):
>
> * a reliably working installer for all our architectures
> - debian-boot@lists.debian.org
>
> * releasable versions for almost all our packages
> - http://bugs.debian.org/release-critical
Thanks for the great summary,
Zenaan
--
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.
Reply to: