Hello Jonathan, Sorry, I wrote my other reply before reading the e-mail to which I'm now replying.
On Fri, Jun 22 2018, Jonathan Nieder wrote:
> My usual practice has been to backport git versions as soon as they
> hit testing. I'd be happy to settle for waiting a week after that.
> Two weeks feels a bit too long.
>
> If the version in sid right now isn't suitable yet for a wider
> audience, then there are a few (not mutually exclusive) options:
>
> 1. file an RC bug to prevent it from migrating to testing.
>
> 2. revert the feature that is not ready for wide release from
> unstable and upload it to experimental to get the exposure it
> currently needs.
>
> 3. upload a more targeted fix for bug#901900 to
> testing-proposed-updates[*].
>
> To me, 1+2 seems a little simpler than 3, but that's a hunch based on
> limited context.
>
> On the other hand, if the bugs are not serious enough to warrant that,
> then I'm happy to delay a little (e.g. 1 week) but would prefer not to
> wait longer than that after testing migration. Rationale: we can
> trust users of the backport to have a similar risk tolerance to users
> of testing.
With regard to (1): I don't see how (1) on its own helps you, because
the fix you need is only in the 5.x series of dgit -- or is the bug
metadata wrong?
With regard to (2), with or without (1): this would be highly disruptive
to the development of src:dgit, now that bin:git-debrebase has made it
through binNEW into sid. We would have to file an RM bug as part of the
reversion.. This disruption seems entirely out of proportion with the
(otherwise worthy!) goal of updating the backport of git.
With regard to (3): I don't think there is much chance of the release
team letting us use the testing-proposed-updates mechanism for a
backporting issue. But you could write to them.
There are two options that I can see:
(A) Ian artificially delays uploading bug fix releases of the 5.x series
to unstable in order that something in the 5.x series can migrate to
testing, so that I can upload 5.x to backports, and you can update
git in backports
(B) We don't do anything special, wait for something in the 5.x series
to hit testing in the normal way, and then update the dgit and git
backports.
Like (2), (A) is quite disruptive to the development of dgit.
Does the new git backport mainly add features or fix bugs? If the
former, (A) seems to be out of proportion with the goal of updating the
backport of git. If the latter, I am not sure.
In any case, since everyone is happy with (B) for at least a week, we
can do (B) for at least a week.
On Fri, Jun 22 2018, Jonathan Nieder wrote:
> Is there somewhere I can read more about that policy? Not that I'm
> complaining :)
https://backports.debian.org/Contribute/
"... you have to ... update your backport when a new version enters
testing ..."
--
Sean Whitton
signature.asc
Description: PGP signature
