Re: freeze policy - open requests for sponsorship
-----BEGIN PGP SIGNED MESSAGE-----
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
Hi,
(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
wheezy.
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
wheezy.
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
wheezy:
- 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJQA9lzAAoJEJOUU0jg3ChAxnwQANSCPgh2qUXc//RDJHOiUQ++
YUhmXfYOyNl/oTWXhZQIfv6mDudQZl41IJyCYYJRyz2wIjjwf5pdAivbPCbMK0vM
WwEW7J+eGzxdKnsuzhb9rhEsav89sWRO/iom/zrhRXyLCZ46OZRINEguxAmhrhc0
n3Djx/MoISqPf3zcCjlVrUj/3FjRzt8UPkSrqkD72ZyG5T+R6QcpEq07cAPL7D0D
vtSn/Oa4X2Ac6TqcI9eUMqZjK+IDqrbsKA1g0OeCfhx480+OkCbNclL6spZGWVfx
jGiDq+q+aWojPzvsteAuIPv2X2qrgY4bgCKOygUm9Soj2DgaGb7K27TGdFI+wbyD
InMikjSxV6PJ2SC2Kd03LmjkkatZtJFW/mz9CgOPEj+VO6uXB/wkHYeQuBRdqEaU
ySoUmwQpzqVAKgRW9nfKnWvrcmFIVVDbPYcc9YpDhM6mnCpksfA3vUi02sVxHO1I
38GZbcf4Is/Pg+nkM2FZJcP6TWcZ03RvvReP/MQQnLZtZTggt0nh34wDCRgj5DL0
U0Qkm6wYLDRmYYs5ePr0kbTMDgT/1dX8eso2QgdTjmSMSj6BDnS7VdezUT6Hiuhl
FJOpjURiZHw5FRVDBAKhwDlwN3V8SnV3TV8DkgAVVWZemfY5kEZUgZt76YAo3EY9
zgWDJAktqm11M5K7RuzV
=RHS2
-----END PGP SIGNATURE-----
Reply to: