Offer: Intend to sponsor
Err, yes, you read the subject right. This is a risky experiment, and I
hope it comes out fine.
I have been successfully working with a sponsoree, Victor Seva
<linuxmaniac@torreviejawireless.org>, in closing xlibs-dev transition
bugs. He is not a Developer, so I have been sponsoring his NMUs.
I am quite happy with the outcome of our collaboration, and am willing
to sponsor other *loving* NMU's regarding this transition.
Reading from http://wiki.debian.org/DependsXlibsDev, "The rules for
NMU'ing to follow are the ones set by the Release Team in their January
mail to debian-devel-announce: a week after the bug is submitted, upload
directly to unstable as a 0-day NMU after sending the patch to the BTS"
I think this means Monday.
>From the experience I have gathered in working with Victor, the steps I
would like to see in order to work comfortably together, and not to
waste our time with bugs that are already being worked on by the
maintainer, are these:
- Read http://wiki.debian.org/DependsXlibsDev and all of its relevant
links. Make sure you understand what we are trying to do.
- Download the script,
http://people.debian.org/~dnusinow/xlibs-split-2005-11-15.tar-bz2
- Read through the bugs list:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=debian-release@lists.debian.org:transition-xlibs-dev&repeatmerged=no
- Choose a bug you can fix, read the bug log, determine wether you can
help, reply to it, and state your intention to work in it. Hopefully,
active maintainers that are already working on it will have time to
reply before your(our) time and effort are wasted. This is important,
or it will get frustrating.
- Fix the xlibs-dev related bug. Look at the rest of the bugs for the
package. Fix other bugs that you might find non-intrussive, easy and
obvious, like, for example whishlist debconf translations, other RC
(FTBFS) bugs with a reasonable patch... But be really careful.
- Use the xlibs-split script to determine the new Build-Depends.
- Double check with pbuilder.
- Write down really badly maintained packages, and contact me.
There are packages out there in really bad shape (old standards
version, long time not acknowleged previous NMUs... ) and this is
a great chance to spot them and give those packages some love,
including orphaning them propperly and triggering a MIA (Missing In
Action) investigation.
- Keep in mind I do not intend to blindly start a bug closing race.
Well, in a way I do, but not at any price. I will not upload
anything with obvious, easy to fix, lintian/linda warnings, or
suboptimal changelog entries... for example. This is also a QA
effort. I hope you get my point.
- Again, reply to the bug report, attach the patches you have generated,
(specifically, I want the diff.gz and the .dsc files).
Cc: amaya@debian.org, and control@bugs.debian.org and tag the bug
patch. I will then look at your work, and reply to the bug. I will
tag it pending, and I will state that I intend to *lovingly* NMU your
changes.
- I will double check everything carefully, and will get back to you in
case of concerns. What we are about to do is a bit tricky. Non-DD NMUs
can be frowned upon and I intend to be über-conservative in my
sponsoring.
- I will upload, to a delayed queue during this weekend, to 0-day from
Monday on.
- Profit! Party!
I am a bit scared and at the same time very excited by this. Any
comments are very wellcome. I don't want to piss maintainers off. I want
to spread some packaging love, and hopefully, in some cases, remotivate
the semi-MIA maintainers. I have seen this happen in BSP before, it has
happend to myself, even, and would appreciate more input on this whole
craziness I am about to get into.
Happy hacking!
--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com
Reply to: