Bug#901900: dgit in stretch-backports
Sean Whitton writes ("Re: dgit in stretch-backports"):
> I prepared the backport earlier today but in a stretch chroot the test
> suite has two failures:
>
> gdr-newupstream FAIL non-zero exit status 16
> gdr-viagit FAIL non-zero exit status 16
>
> Ian, could you take a look at the log, please?
>
> I think these are just another gnupg failure that need not delay the
> backport, but it would be good to get your opinion on it.
I think this is something else. I always run the tests on stretch
during development so I don't think there is anything fundamentally
wrong, but the behaviour is certainly odd and does not look like the
usual gnupg2 race bugs. Looking at the error message, line 21
gpg-locked is (roughly)
$DGIT_TEST_REAL_GPG --agent-program=$DGIT_STUNT_AGENT
and this suggests that DGIT_TEST_REAL_GPG is not set. So I think the
most likely explanation is a bug in the test suite. Of course that
means that these tests were not run.
I will see if I can repro it in adt with a stretch chroot.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#901900: dgit in stretch-backports
Hello, On Tue, Jun 26 2018, Jonathan Nieder wrote: > Thanks again for this pointer. dgit 5.2 has now hit testing. If > there is anything I can do to help with getting it into > stretch-backports, please don't hesitate to let me know. I prepared the backport earlier today but in a stretch chroot the test suite has two failures: gdr-newupstream FAIL non-zero exit status 16 gdr-viagit FAIL non-zero exit status 16 Ian, could you take a look at the log, please? I think these are just another gnupg failure that need not delay the backport, but it would be good to get your opinion on it. -- Sean Whitton dgit_5.2~bpo9+1_i386.build Description: Binary data signature.asc Description: PGP signature
Bug#901900: dgit in stretch-backports
Hi Sean, Sean Whitton wrote: > 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 ..." Thanks again for this pointer. dgit 5.2 has now hit testing. If there is anything I can do to help with getting it into stretch-backports, please don't hesitate to let me know. Sincerely, Jonathan
Bug#901900: dgit in stretch-backports
Sean Whitton wrote: > (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. [...] > In any case, since everyone is happy with (B) for at least a week, we > can do (B) for at least a week. Sorry for the lack of clarity. I think (B) is the right choice, and without any special delays. My previous reply was just about how we would get testing in a good state without blocking Git updates if the dgit 5.x issues Ian mentioned were release-critical, but I don't think that's the situation we're in. > 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 ..." Ah, lovely. Thank you. Jonathan
Bug#901900: dgit in stretch-backports
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
Bug#901900: dgit in stretch-backports
Hi Sean, Sean Whitton wrote: > On Fri, Jun 22 2018, Jonathan Nieder wrote: >> Do you plan to update dgit in backports once it hits testing? > > Yes. Excellent, thank you. [...] >> Is there anything I can do to help? For example, should I prepare an >> upload for 4.4 while we wait for 5.1 to migrate to testing? > > So far as I can tell from this bug's metadata 4.4 will not help you? > (I'll push 4.4 to stretch-backports soon in order to comply with > backports policy, anyway.) Is there somewhere I can read more about that policy? Not that I'm complaining :). [...] > On Fri, Jun 22 2018, Ian Jackson wrote: >> 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. [...] > The only way to delay > updating the backport is to keep making releases to unstable ;) Or in other words, users of the backport are not promised any better stabilization than testing. If you're concerned about the stability of the package, I recommend sorting it out in testing too, as mentioned in my previous reply. Thanks much, Jonathan
Bug#901900: dgit in stretch-backports
Hello Jonathan, On Fri, Jun 22 2018, Jonathan Nieder wrote: > Do you plan to update dgit in backports once it hits testing? Yes. > Is there anything I can do to help? For example, should I prepare an > upload for 4.4 while we wait for 5.1 to migrate to testing? So far as I can tell from this bug's metadata 4.4 will not help you? (I'll push 4.4 to stretch-backports soon in order to comply with backports policy, anyway.) For 5.x, I already have a working backport of 5.0 in my personal apt repo, so it should be easy to bump that to whichever 5.x release migrates to testing first and push that to stretch-backports. If you want the debs for testing, I can send you the URL for that repo. On Fri, Jun 22 2018, Ian Jackson wrote: > 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. Just ftr, we have to update stretch-backports once something new migrates to testing, per backports policy. The only way to delay updating the backport is to keep making releases to unstable ;) -- Sean Whitton signature.asc Description: PGP signature
Bug#901900: dgit in stretch-backports
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
Bug#901900: dgit in stretch-backports
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 supports the working-tree-encoding attribute
> (https://bugs.debian.org/901900).
>
> Do you plan to update dgit in backports once it hits testing? Is
> there anything I can do to help? For example, should I prepare an
> upload for 4.4 while we wait for 5.1 to migrate to testing?
Sean has mostly been managing the backports of dgit. I think
backports of both git and dgit would be good things.
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.
Ian.
[1] git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git#wip (rebasing)
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#901900: dgit in stretch-backports
Hi Sean et al, 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 supports the working-tree-encoding attribute (https://bugs.debian.org/901900). Do you plan to update dgit in backports once it hits testing? Is there anything I can do to help? For example, should I prepare an upload for 4.4 while we wait for 5.1 to migrate to testing? Thanks, Jonathan
