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 <[EMAIL PROTECTED]>, 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/[EMAIL PROTECTED]: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: [EMAIL PROTECTED], and [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
