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

Re: fetch-crl_3.0.16-2~bpo8+1_amd64.changes REJECTED



Hi,

the point is to not have the burden on checking that on the shoulders of the backports team and make you aware of the rule (again) so that you won't make the mistake again once your package doesn't need new processing anymore because it's already in the pool. We often enough have packages in backports which are newer than the version in testing which isn't the way we expect uploaders to backports work.

It might be a picky point to you, but it's actually a burden on the backports team that shouldn't have to be there. Please respect that.

Thanks,
Rhonda

Am 20. Juni 2015 06:16:11 MESZ, schrieb Mattias Ellert <mattias.ellert@fysast.uu.se>:
>ons 2015-06-17 klockan 14:57 +0200 skrev Mattia Rizzolo:
>> On Wed, Jun 17, 2015 at 1:50 PM, Mattias Ellert
>> <mattias.ellert@fysast.uu.se> wrote:
>> > ons 2015-06-17 klockan 07:00 +0000 skrev Alexander Wirt:
>> > > Package version is not in testing
>> > 
>> > It is in unstable.
>> 
>> But it has to be in testing:
>> http://backports.debian.org/Contribute/#index4h3
>
>Yes, but what is the point of rejecting the backport if the new version
>is in unstable. Why not let the backport stay in the new queue for five
>days and then approve it when the new version has migrated to testing?
>
>Do I need to upload it again when the migration has happened?
>
>	Mattias


Reply to: