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

Re: freeze policy - open requests for sponsorship

Hash: SHA256

Le 03/07/12 08:20, Thibaut Paumard a écrit :
> Le 03/07/12 01:41, Adam Borowski a écrit : Hi,
> We could agree on a usertag then, for instance:
> User: sponsorship-requests@packages.debian.org Usertags:
> not-for-wheezy
> Using sponsorship-requests@packages.debian.org as the User, we
> should be able to rearrange the default view of 
> bugs.debian.org/sponsorship-requests to have the "for-wheezy" bugs
> on top (subclassified by severity) followed by the not-for-wheezy
> bugs.
> cf. http://wiki.debian.org/bugs.debian.org/usertags


(For the record, IANADD... yet)

I was about to triage some bugs with these two usertags (for-wheezy
and not-for-wheezy), but I realized it is impossible to do without the
assent from the submitter. Actually, I have read the first 10 RFSes or
so, and if I could, I would not upload any of them because they are
not fit for wheezy and they don't state whether they are aiming for

So, dear prospective sponsees, although I am not yet in a position to
sponsor you, I think I'm not wrong in telling you that: do yourself a
favour and _tell_ in your bugreport whether or not you are targeting

One proposed way to do that is to set the usertag "for-wheezy" or
"not-for-wheezy" with user sponsorship-requests@packages.debian.org.
Since no bug have yet been thus tagged, you need to also spell it out
in your bugreport.

Uploads targeted for Wheezy should fix bug of severity important or
above, and the severity of your RFS should match the highest severity
of the bugs you are fixing (so a RFS targeted at wheezy should be of
severity important or more).

If your RFS does NOT target wheezy:
 - you can do whatever changes to your package, but you should almost
certainly set the distribution to experimental. This will help you get
important fixes to Wheezy should this prove necessary later on. This
does not apply to packages which are not in Wheezy anyway.

If you DO target Wheezy:
 - say so in your bugreport
 - keep your changes minimal
 - fix only important bugs (RC bugs, release goals)
 - set the severity of the RFS accordingly
 - for fixes involving a library transition, get it pre-approved by the
   release team
 - it will always help if you get your upload pre-approved by the
   release team

A few things that you should not do if you want your package to reach
 - update to a new upstream release
 - change from dh to cdbs or other
 - rewrite your rules file from scratch
 - rewrite your copyright file from scratch or convert it to 1.0
   machine readable format
 - ...
All those things are likely to be rejected by the release team, so you
will need to revert them and reupload. New upstream is the worst: it
would force you to reupload to testing-proposed-updates instead of
unstable, and the release team may not allow you to if they don't
think your changes are worth the risk.

Kind regards, Thibaut.
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: