Ian Jackson wrote:
> Jonathan Nieder writes ("Bug#901900: dgit in stretch-backports"):>> Once git 2.18.0 is in testing, I want to update the git package in >> stable-backports. This would require updating dgit as well to a >> version that supports the working-tree-encoding attribute >> (https://bugs.debian.org/901900). [...] > Sean has mostly been managing the backports of dgit. I think > backports of both git and dgit would be good things. Thanks. I figured Sean was the one to ask. > However, we have just released a major new feature and there are > inevitble bugs in it. My current wip branch[1] has fixes for that but > also fixes for other bugs, some of which may themselves cause further > bugs. > > What kind of timescale are you thinking about here ? If you are > willing to wait a couple of weeks, I think sid/testing's dgit will > have settled down. 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. Separately from that, my offer of preparing an upload of 4.4 for backports still stands. Thoughts? Jonathan [*] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u
