Re: Versioning of new releases in (old)stable (Was: nss security update package ready for review)
Hi Emilio, Jonas, Antoine, Thanks for all feedback. On Thu, Dec 01, 2016 at 04:44:22PM +0100, Emilio Pozuelo Monfort wrote: > On 01/12/16 16:25, Jonas Meurer wrote: > > Hi Security and LTS folks, > > > > Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso: > >> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote: > >>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high > >>> + > >>> + * Non-maintainer upload by the LTS Security Team. > >>> + * New upstream release to fix CVE-2016-9074 > >> > >> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or > >> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1. > >> > >> The former if you import new orig source on top of the previous > >> packaging to indicate the new import and have a version which is > >> before any possible such ones uploaded to unstable (which is even true > >> in this case because 2:3.26.2-1 is currently in unstable). The later > >> is often prefered if the package is mostly are build of :3.26.2-1 for > >> Wheezy. (The later proposed version works obviously as well in the > >> case of just a new upstream import, but Release team has often as well > >> done that distinction for the ~debXuY suffix). > > > > With this topic being discussed again and again recently, I suggest that > > we should agree on a defined standard regarding the versioning of new > > upstream releases uploaded to (old)?stable(-security)? and document it > > somewhere. What do you think? > > > > I don't have particular strong feelings on the exact versioning but I > > think that the following should be considered: > > > > *) New upstream releases in (old)?stable should use lover version > >numbers than their equivalent uploaded to unstable. This because > >packages uploaded to unstable are built using more recent versions > >of the build toolchain and libraries. > > Moreover, New upstream releases should use lower versions than the next suite. > That means oldstable < stable < testing < sid. Not just oldstable < sid and > stable < sid, as you worded it. > > That's why 2:3.26.2-1+debu7u1 would be bad even if unstable had 2:3.26.3-1 by > now, if stable had 2:3.26.2-1~debu8u1. > > When doing an update in oldstable, we need to see if it has happened or is > happening in stable to avoid having a higher version in oldstable. > > > *) The versioning should make it obvious whether the new release is > >based on a similar upload to unstable or whether it's packaged > >solely for (old)?stable. > > > > Consequently, the following (as already done for most uploads of new > > releases to (old)?stable) is my suggestion: > > > > *) Uploads of new upstream releases to (old)?stable that were packaged > >for unstable before should use the '~debXu1' suffix to the version > >number from unstable as they're basically backports of the package > >from unstable. > > *) Uploads of new upstream releases that were not packaged for unstable > >yet or will never be, should use the '1.2.3-0+debXu1' format (given > >that '1.2.3' is the upstream version. > > That's the current practice, yes. As Salvatore pointed out, that's also what > the > SRMs require for (old)stable uploads. > > > If we can agree on this, what would be the proper place to document it > > for the future? Ideally, this should be mandatory for any uploads of new > > upstream releases to the (old)?stable suites, be it to > > (old)?stable-security, to stable-proposed-updates or to stable-updates. > > Probably the developers-reference, which already mentions the +debXuY syntax > in > various places (including the security updates section, 5.8.5.4 [1]), but > doesn't mention ~debXuY for the case of backports. Right it is spread around on various sections both for stable updates and as well for security updates. Would it make sense to maybe add a new section for handling versioning for (old)?stable(-securit)? udpates, and then reference from both the security bug handling and the stable-updates handling to it? I do not have a wording right now for dev-ref, but I can look if I can come up with something during the weekend (keep in mind though that it will in any case need review, I'm not a native english speaker). Regards, Salvatore
Re: Versioning of new releases in (old)stable (Was: nss security update package ready for review)
On 2016-12-01 10:25:58, Jonas Meurer wrote: > Hi Security and LTS folks, > > Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso: >> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote: >>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high >>> + >>> + * Non-maintainer upload by the LTS Security Team. >>> + * New upstream release to fix CVE-2016-9074 >> >> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or >> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1. >> >> The former if you import new orig source on top of the previous >> packaging to indicate the new import and have a version which is >> before any possible such ones uploaded to unstable (which is even true >> in this case because 2:3.26.2-1 is currently in unstable). The later >> is often prefered if the package is mostly are build of :3.26.2-1 for >> Wheezy. (The later proposed version works obviously as well in the >> case of just a new upstream import, but Release team has often as well >> done that distinction for the ~debXuY suffix). > > With this topic being discussed again and again recently, I suggest that > we should agree on a defined standard regarding the versioning of new > upstream releases uploaded to (old)?stable(-security)? and document it > somewhere. What do you think? It has been repeatedly discussed, indeed. I think Salvatore's description is basically the ad-hoc standard. Maybe this should be documented better in LTS/Development in the wiki? or devref? > I don't have particular strong feelings on the exact versioning but I > think that the following should be considered: > > *) New upstream releases in (old)?stable should use lover version >numbers than their equivalent uploaded to unstable. This because >packages uploaded to unstable are built using more recent versions >of the build toolchain and libraries. > > *) The versioning should make it obvious whether the new release is >based on a similar upload to unstable or whether it's packaged >solely for (old)?stable. > > Consequently, the following (as already done for most uploads of new > releases to (old)?stable) is my suggestion: > > *) Uploads of new upstream releases to (old)?stable that were packaged >for unstable before should use the '~debXu1' suffix to the version >number from unstable as they're basically backports of the package >from unstable. > *) Uploads of new upstream releases that were not packaged for unstable >yet or will never be, should use the '1.2.3-0+debXu1' format (given >that '1.2.3' is the upstream version. The distinction is a little more subtle than this - 3.26.2 *was* packaged for unstable - it's just that the package is built with the debian/ (or debian.tar.gz, if you prefer) from oldstable, not from unstable. Upstream releases that were "not packaged for unstable *yet*" should probably *never* be shipped in unstable. In the example of nss, it would make no sense to package 3.26.x releases in oldstable unless they had been running for a while... Therefore, I think we may want to target "testing" there, to make it explicit that it's not just a package that was just uploaded to unstable that can be shipped in oldstable... In other words, the second paragraph above would read: *) Uploads of new upstream releases that do not ship associated debian/ packaging from testing/unstable should use a lower version than testing/unstable, for example `1.2.3-0+debXu1` given a `1.2.3-1` version in unstable > If we can agree on this, what would be the proper place to document it > for the future? Ideally, this should be mandatory for any uploads of new > upstream releases to the (old)?stable suites, be it to > (old)?stable-security, to stable-proposed-updates or to stable-updates. SPU/SU is the release team's jurisdiction, i am not sure i would want to mess with those guys. ;) As to where document this, it's always tricky. Our documentation is unfortunately a bit spread out. I don't know about the secteam, but i often refer to this: https://wiki.debian.org/LTS/Development#Build_the_update Uploads to stable are documented here: https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable Security uploads are documented here: https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#bug-security-building We should probably cross-reference all this stuff. Note that everyone with collab-maint access can edit the developer's reference, and I encourage people here to get familiar with that process... > Anything I forgot to consider? For me, the critical issue is not versionning - those mistakes are pretty easy to catch and even in case of mistake, can be more or less harmless. For example, in the case of nss 3.26.2-1+deb7u1, while it was newer than the version in testing/unstable, 3.27.1 is coming down the pipe there and it wouldn't stay newer for long. Those problems often have a tendency of fixing
Re: Versioning of new releases in (old)stable (Was: nss security update package ready for review)
On 01/12/16 16:25, Jonas Meurer wrote: > Hi Security and LTS folks, > > Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso: >> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote: >>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high >>> + >>> + * Non-maintainer upload by the LTS Security Team. >>> + * New upstream release to fix CVE-2016-9074 >> >> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or >> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1. >> >> The former if you import new orig source on top of the previous >> packaging to indicate the new import and have a version which is >> before any possible such ones uploaded to unstable (which is even true >> in this case because 2:3.26.2-1 is currently in unstable). The later >> is often prefered if the package is mostly are build of :3.26.2-1 for >> Wheezy. (The later proposed version works obviously as well in the >> case of just a new upstream import, but Release team has often as well >> done that distinction for the ~debXuY suffix). > > With this topic being discussed again and again recently, I suggest that > we should agree on a defined standard regarding the versioning of new > upstream releases uploaded to (old)?stable(-security)? and document it > somewhere. What do you think? > > I don't have particular strong feelings on the exact versioning but I > think that the following should be considered: > > *) New upstream releases in (old)?stable should use lover version >numbers than their equivalent uploaded to unstable. This because >packages uploaded to unstable are built using more recent versions >of the build toolchain and libraries. Moreover, New upstream releases should use lower versions than the next suite. That means oldstable < stable < testing < sid. Not just oldstable < sid and stable < sid, as you worded it. That's why 2:3.26.2-1+debu7u1 would be bad even if unstable had 2:3.26.3-1 by now, if stable had 2:3.26.2-1~debu8u1. When doing an update in oldstable, we need to see if it has happened or is happening in stable to avoid having a higher version in oldstable. > *) The versioning should make it obvious whether the new release is >based on a similar upload to unstable or whether it's packaged >solely for (old)?stable. > > Consequently, the following (as already done for most uploads of new > releases to (old)?stable) is my suggestion: > > *) Uploads of new upstream releases to (old)?stable that were packaged >for unstable before should use the '~debXu1' suffix to the version >number from unstable as they're basically backports of the package >from unstable. > *) Uploads of new upstream releases that were not packaged for unstable >yet or will never be, should use the '1.2.3-0+debXu1' format (given >that '1.2.3' is the upstream version. That's the current practice, yes. As Salvatore pointed out, that's also what the SRMs require for (old)stable uploads. > If we can agree on this, what would be the proper place to document it > for the future? Ideally, this should be mandatory for any uploads of new > upstream releases to the (old)?stable suites, be it to > (old)?stable-security, to stable-proposed-updates or to stable-updates. Probably the developers-reference, which already mentions the +debXuY syntax in various places (including the security updates section, 5.8.5.4 [1]), but doesn't mention ~debXuY for the case of backports. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security Cheers, Emilio
