Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing
]] Andreas Beckmann > On 2017-03-09 18:00, Ian Jackson wrote: > > To be fair to Pirate, Andreas Beckmann suggested #856606 that if > > Pirate disagreed with Andreas, Pirate should go to the TC. > > The disagreement between Pirate and me is not about the RC-ness of > #856606, but more about the general requirement of working upgrade paths. > > This is my understanding of Pirate's point: > > "Package P hasn't been part of any stable release so far, therefore >upgrades from earlier package versions don't have to be supported. >So not having a working upgrade path from version 1.2-3 in testing >to version 1.2-5 unstable is not a bug." >From reading through the bug log, that is my understanding of his point as well. The upgrade is from a previous version of gitlab that has been in stretch for a little under a month (it went into testing on 2017-02-18). I think it's completely clear that failure to support upgrades (even between short-lived versions that only hit unstable) is a bug. For versions that hit testing, even more so. In the typical cases where we don't support upgrades between major versions (think apache 1 → 2), we typically renamed the packages involved. That seems overly heavy-handed in this case where the upgrade path can just be fixed (see mail from Phil Hands for some suggestions), but it points to what the bar is. The guidelines are more lax for experimental where people have been known to not make it possible to move to testing/unstable versions of the package without reinstalling/reconfiguring it. I think this is, and should be, discouraged but allowed. Experimental exists for a reason: to be able to conduct experiments, and sometimes you need to burn the experiment to the ground afterwards. > I didn't find anything in the policy about upgrade requirements ... > but I think there is a general agreement that direct upgrades must work > (and only skipping over stable releases is not supported). There are a lot of requirements for packages that are not written in policy. There's no requirement in Policy as written that changelogs must be in English, for instance. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing
Andreas Beckmann writes: > On 2017-03-09 18:00, Ian Jackson wrote: >> To be fair to Pirate, Andreas Beckmann suggested #856606 that if >> Pirate disagreed with Andreas, Pirate should go to the TC. > > The disagreement between Pirate and me is not about the RC-ness of > #856606, but more about the general requirement of working upgrade > paths. Looking at the bug, I see that the issue involves this bit of code: export $(cat /etc/gitlab/gitlab-debian.conf) (and other variations thereof) used in the maintainer scripts, and suggested in the README as something for the user to run. It strikes me as rather fragile, and likely to misbehave in surprising ways -- e.g. if one comments out a line in the file with '# ' then the setting will still get set. Is it not possible to patch the code of the package to contain the default paths internally, so that it is not essential to populate the environment before running things? Failing that, how about setting the defaults and exporting them in a wrapper script, which could also source the config file (in the more normal way) before then invoking rake (or whatever), and then using that in place of running rake etc. directly? Either of these should mean that one could have an empty/missing config file under /etc, or include comments in the config file, and still have things work properly. I suspect that much of the tangled code for handling the config files would drop away if you did this, which ought to also ensure that this bug would disappear. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing
On 2017-03-09 18:00, Ian Jackson wrote: > To be fair to Pirate, Andreas Beckmann suggested #856606 that if > Pirate disagreed with Andreas, Pirate should go to the TC. The disagreement between Pirate and me is not about the RC-ness of #856606, but more about the general requirement of working upgrade paths. This is my understanding of Pirate's point: "Package P hasn't been part of any stable release so far, therefore upgrades from earlier package versions don't have to be supported. So not having a working upgrade path from version 1.2-3 in testing to version 1.2-5 unstable is not a bug." I didn't find anything in the policy about upgrade requirements ... but I think there is a general agreement that direct upgrades must work (and only skipping over stable releases is not supported). Andreas
Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing
Adam D. Barratt writes ("Bug#857257: Re: Supporting configuration file changes
between versions in unstable/testing"):
> On 2017-03-09 9:41, Pirate Praveen wrote:
> > I request CTTE to declare this bug as not RC.
>
> That's not something that the Technical Committee has a remit to do.
>
> The determination as to whether a bug is release-critical is delegated
> to the Release Team. So far as I can tell you haven't approached them to
> discuss this, so you can't be asking the TC to override a decision by a
> delegate either, as there hasn't explicitly been one.
To be fair to Pirate, Andreas Beckmann suggested #856606 that if
Pirate disagreed with Andreas, Pirate should go to the TC.
I don't think any of the Release Team have been asked yet.
Sadly, there isn't a "reportbug release.debian.org" category for
"please determine RCness of #". So I am just emailing
debian-release@l.d.o on this mail.
To debian-release:
The question is whether #856606 is RC.
I think you will find the best summary of the arguments in this
message:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856606#37
Ian.
Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing
[this doesn't appear to have reached the tech-ctte list yet, so I'm replying from the BTS archive] On 2017-03-09 9:41, Pirate Praveen wrote: Package: tech-ctte [...] I request CTTE to declare this bug as not RC. That's not something that the Technical Committee has a remit to do. The determination as to whether a bug is release-critical is delegated to the Release Team. So far as I can tell you haven't approached them to discuss this, so you can't be asking the TC to override a decision by a delegate either, as there hasn't explicitly been one. Regards, Adam
Processed: Supporting configuration file changes between versions in unstable/testing
Processing control commands: > block 856606 by -1 Bug #856606 [gitlab] gitlab: fails to upgrade from 'stretch': nginx example configuration file not found 856606 was not blocked by any bugs. 856606 was not blocking any bugs. Added blocking bug(s) of 856606: 857257 -- 856606: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856606 857257: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857257 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
