Re: slave maintainer for day to day work
Marcus Brinkmann writes ("slave maintainer for day to day work"):
...
> when Dwarf maintained glibc, it was soon clear that it was too much work for
> one maintainer to maintain glibc and care about the bug reports etc.
>
> I was helping Dwarf, and digged through all bug reports, classifying them
> and closing fixed ones in his name. It was a big success. I was able to
> close several dozens in a few days, and merge a couple.
>
> I would offer the same for dpkg, but extend this offer to make small point
> releases for very trivial fixes, like one or two character fixes or other
> obvious things.
>
> The idea is that dpkg needs capable maintainers for development and design
> issues, but capable people are often very very busy. So a maintainer with
> more time to answer easy bug reports and do simple things could ease the
> workload on the real maintainers. I am not ignorant of dpkg, I ported it to
> Hurd and spent quite some hours inside the source tree, and I have "lots of
> time" (an exaggeration).
>
> You may or may not like the idea. If you feel you will have more time in the
> future to maintain dpkg, that's just fine. If you think my help could be
> needed, you can approve me.
Thanks for the offer. At the moment, I'm still getting up to speed,
and I'm not sure if there's anything in particular that I could really
do with help with code-wise. I'm reviewing the NMU changes atm.
I'm using the BTS as a worklist, so help organising its contents would
be welcome. In particular, for non-bugs and other dross, it would be
helpful if someone could contact the submitter and see if they agree
to the bug being closed.
I'd rather actually close these bugs myself, but it would save me a
lot of effort if the BTS already had a record of a developer saying
`this is not a bug, can we close it?' and the sumbitter failing to
reply or saying `yes'. Then I can just close the bug without further
ado.
Ian.
Reply to: