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

Re: [SRU] Proposal of docky 2.0.12-1 for squeeze 6.0.1



On Fri, March 11, 2011 07:33, Rico Tzschichholz wrote:
>> For a stable update, it's a little more than a "quite large" diff.
>
> Neverthelesse it is a stable update which includes fixes of half a year.
> There were 92 commits since 2.0.6 which are solving several problems.

That doesn't mean all of the changes are suitable for stable though.

>> At that size without the translation updates, I'm afraid I'd need
>> considerably more convincing to accept the update.  On the third hand,
>> there's also a single new file that's over 1000 lines, fixes for
>> compilation with mono 2.8 - which isn't even in the archive yet alone in
>> stable - plus at least one new plugin.  Additionally, unstable only has
>> docky 2.0.11-1 currently.
>>
>
> Of course there are some fixes like the mono 2.8 which might not apply
> directly to squeeze, but given the number of fixes besides that it
> should be ok.

That's not how stable updates work in Debian.  If the mono 2.8 fixes were
small and we were happy to accept the rest of the diff as-is, they'd
probably sneak in.  Neither of those are the case, and I'm not happy
ignoring over 1000 lines of new code relative to the current stable
package which don't actually fix any problems in stable.

> All these changes already gone through quite some testing by people
> using our stable ppa
> (https://edge.launchpad.net/~docky-core/+archive/stable)

That doesn't appear to contain any packages for squeeze?  As such, it's
okay for general testing but not really relevant for a stable update in
Debian.

>> I'm afraid that that's the case right now.  It might be possible to get
>> specific fixes included, but I'm not happy accepting the proposed diff
>> as-is.
>
> I understand your concerns, but I as docky developer strongly recommend
> this update.
>
> docky 2.0.12-1 will be uploaded to unstable later this week.

Even after that's occurred, your proposal still appears to be a direct
backport to stable of the package that would be uploaded to unstable. 
That would likely be suitable for squeeze-backports, but wholesale
backports are not generally appropriate for stable updates.

Regards,

Adam


Reply to: