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

Returning to sponsoring - QA or RC preferred



Just a notice, things are a bit more manageable in Emdebian now and I
want to catch up with a few sponsored uploads.

I have one ongoing sponsoring for xf86-input-tslib which I will upload
the latest upstream version today (hopefully). (It won't get a freeze
exception but the fixes are needed for OpenMoko.) I do not expect to
make any other non-QA / non-RC sponsored uploads until Lenny is
released.

*Please make QA and RC uploads easy to identify in the Subject line!*
(especially if you are posting a "ping".) I probably won't read any post
here that does not mention either QA or RC in the Subject.

I am also looking to review a few QA uploads already available at
mentors.debian.net - thanks to the addition of m.d.n to the ToDo section
of the PTS, I have been able to identify some packages as available for
review prior to a possible QA sponsored upload. I'll post about each of
those separately and CC the relevant maintainers as listed on m.d.n
(provided that everything else checks out with regard to other sponsors,
already uploaded etc.). I'll be going through the list [1] and see what
I can do.

I will also be making time for RC bug fixes - these will get priority
*IF* maintainers make it absolutely clear in the *subject* that the
sponsored upload would close RC bugs. Such uploads must be suitable for
a freeze exception. My normal sponsoring rules regarding languages [0]
still apply but there are a few changes for RC issues. 

Sponsoring an RC upload is different to any other sponsoring - the
substance of the upload must be unobtrusive and there are clear
guidelines from the debian-release team about what will be accepted.
There is no point doing an RC upload that will be rejected due to
extraneous changes. Therefore, sponsoring an RC upload is not much
different to fixing the RC bug myself where a patch already exists in
the BTS. The only changes in the package must be entirely within the
patch (with a suitable changelog entry) and if the patch is incomplete,
add a new one in a new post to the bug report. 

The only difference is that you make the changelog entry, not me. All my
normal checks and tests are needed. I specifically do *not* want RC
fixes that also fix lintian issues or other extraneous bug reports
(except translation or documentation updates) or make any change in the
package that would not be accepted by debian-release@l.d.o - If your
upload to m.d.n includes such changes, *I will expect these to be
removed before the upload to Debian* unless you have already cleared
this with debian-release@lists.debian.org and can point to an archived
message from the d-r mailing list that confirms release team approval
for the complete set of changes. (Other sponsors may vary but the
opinion of the debian release team is the final arbiter.) Don't pester
the release team unnecessarily, read the advice. [2]

Note that you do not need a sponsored upload if you feel that Lenny
would be improved by removing a particular package with 1 or more RC
bugs. File the removal bug against ftp.debian.org yourself. :-)

Is there an RC section or list on mentors.debian.net ? (If not, can
there be one?)

[0] http://people.debian.org/~codehelp/#lang
[1] http://qa.debian.org/orphaned.html
[2] http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html

Re [0] - make sure you turn off Adblock Plus to see my sponsoring notes,
apparently anything using the word "sponsor*" is an advert according to
the brain-dead Adblock Plus extension.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: