[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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,
- Read through the bugs list:
- 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
- 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

- 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: