* versioning @ 2017-05-17 7:47 Karel Zak 2017-05-17 8:42 ` versioning Ruediger Meier ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Karel Zak @ 2017-05-17 7:47 UTC (permalink / raw) To: util-linux Hi, Sami has good point on IRC... do we really want to continue with the current versioning schema? Now we use: v2.xx[.y] I don't expect v3 or v4, so the prefix v2 does not provide any information... and the 'xx' ('30' now) is already large number. Suggestions: 1) do nothing; nobody cares and v2.31 looks good 2) remove '2' from the version: major release: v31 update release: v31.1 3) <your suggestion>? Note that for v2.30 is to late to do any change in version numbers (we need changes in our libraries and I have to update some my scripts). Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 7:47 versioning Karel Zak @ 2017-05-17 8:42 ` Ruediger Meier 2017-05-17 8:47 ` versioning Ruediger Meier 2017-05-17 15:04 ` versioning Karel Zak 2017-05-17 17:36 ` versioning Bruce Dubbs 2017-05-17 17:46 ` versioning J William Piggott 2 siblings, 2 replies; 27+ messages in thread From: Ruediger Meier @ 2017-05-17 8:42 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux On Wednesday 17 May 2017, Karel Zak wrote: > Hi, > > Sami has good point on IRC... do we really want to continue with the > current versioning schema? Now we use: > > v2.xx[.y] > > I don't expect v3 or v4, so the prefix v2 does not provide any > information... and the 'xx' ('30' now) is already large number. > > Suggestions: > > 1) do nothing; nobody cares and v2.31 looks good > > 2) remove '2' from the version: > > major release: v31 > update release: v31.1 I don't see why v31 would be better than v3? I always appreciate if there are no gaps in version numbers. So v31 should be released after v30 ;) > > 3) <your suggestion>? > I would prefer either v2.31 or v3.1. v3 just to avoid big numbers. But could also be a hint regarding the minimum supported/tested kernel version. I believe that we have already a few incompatibilities for kernel <2.6.32. Maybe we could cleanup our code, only supporting kernel >=3.1. cu, Rudi > Note that for v2.30 is to late to do any change in version numbers > (we need changes in our libraries and I have to update some my > scripts). > > Karel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 8:42 ` versioning Ruediger Meier @ 2017-05-17 8:47 ` Ruediger Meier 2017-05-17 13:23 ` versioning Bernhard Voelker 2017-05-17 15:04 ` versioning Karel Zak 1 sibling, 1 reply; 27+ messages in thread From: Ruediger Meier @ 2017-05-17 8:47 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux On Wednesday 17 May 2017, Ruediger Meier wrote: > On Wednesday 17 May 2017, Karel Zak wrote: > > Hi, > > > > Sami has good point on IRC... do we really want to continue with > > the current versioning schema? Now we use: > > > > v2.xx[.y] > > > > I don't expect v3 or v4, so the prefix v2 does not provide any > > information... and the 'xx' ('30' now) is already large number. > > > > Suggestions: > > > > 1) do nothing; nobody cares and v2.31 looks good > > > > 2) remove '2' from the version: > > > > major release: v31 > > update release: v31.1 > > I don't see why v31 would be better than v3? I always appreciate if > there are no gaps in version numbers. So v31 should be released after > v30 ;) > > > 3) <your suggestion>? > > I would prefer either v2.31 or v3.1. > > v3 just to avoid big numbers. But could also be a hint regarding the > minimum supported/tested kernel version. I believe that we have > already a few incompatibilities for kernel <2.6.32. Maybe we could > cleanup our code, only supporting kernel >=3.1. Note we could still continue with 2 digit version numbers as well without jumping to v31: v2.30 v2.30.1 v2.30.2 v3.0 v3.1 v3.2 v4.0 [...] > cu, > Rudi > > > Note that for v2.30 is to late to do any change in version numbers > > (we need changes in our libraries and I have to update some my > > scripts). > > > > Karel > > -- > To unsubscribe from this list: send the line "unsubscribe util-linux" > in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 8:47 ` versioning Ruediger Meier @ 2017-05-17 13:23 ` Bernhard Voelker 2017-05-17 13:51 ` versioning Karel Zak 0 siblings, 1 reply; 27+ messages in thread From: Bernhard Voelker @ 2017-05-17 13:23 UTC (permalink / raw) To: Ruediger Meier, Karel Zak; +Cc: util-linux On 05/17/2017 10:47 AM, Ruediger Meier wrote: > v2.30 > v2.30.1 > v2.30.2 > v3.0 > v3.1 > v3.2 +1 to all your arguments - v31 and v31.1 look really odd. Have a nice day, Berny ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 13:23 ` versioning Bernhard Voelker @ 2017-05-17 13:51 ` Karel Zak 0 siblings, 0 replies; 27+ messages in thread From: Karel Zak @ 2017-05-17 13:51 UTC (permalink / raw) To: Bernhard Voelker; +Cc: Ruediger Meier, util-linux On Wed, May 17, 2017 at 03:23:11PM +0200, Bernhard Voelker wrote: > On 05/17/2017 10:47 AM, Ruediger Meier wrote: > > v2.30 > > v2.30.1 > > v2.30.2 > > v3.0 > > v3.1 > > v3.2 > > +1 to all your arguments - v31 and v31.1 look really odd. Well, the idea behind v31 is to make difference between the current schema and the new one. The version number v3.1 maybe interpreted as a new major release that is incompatible with v2. Anyway, I have no strong opinion about it. It's just number :-) I can live with v3.1 too. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 8:42 ` versioning Ruediger Meier 2017-05-17 8:47 ` versioning Ruediger Meier @ 2017-05-17 15:04 ` Karel Zak 2017-05-17 16:08 ` versioning Ruediger Meier 1 sibling, 1 reply; 27+ messages in thread From: Karel Zak @ 2017-05-17 15:04 UTC (permalink / raw) To: Ruediger Meier; +Cc: util-linux On Wed, May 17, 2017 at 10:42:53AM +0200, Ruediger Meier wrote: > v3 just to avoid big numbers. But could also be a hint regarding the > minimum supported/tested kernel version. I believe that we have already > a few incompatibilities for kernel <2.6.32. Maybe we could cleanup our > code, only supporting kernel >=3.1. I'm almost sure we have users who use util-linux on old kernels. For example RHEL6 with 2.6.32 is pretty common and I have no problem to compile util-linux there. And sometimes we also backport patches from util-linux upstream to RHEL6 etc ;-) It's fine to kill things for 2.2 (etc.) but for I'd like to be friendly to 2.6 users (if possible). Karel ./lscpu --version lt-lscpu from util-linux 2.30-rc1-25-b7eb $ ./lscpu Architecture: s390x CPU op-mode(s): 32-bit, 64-bit Byte Order: Big Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s) per book: 1 Book(s): 4 Vendor ID: IBM/S390 Machine type: 2827 BogoMIPS: 2913.00 Hypervisor vendor: (null) Virtualization type: full Dispatching mode: horizontal Flags: esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs $ uname -a Linux devel2.s390.bos.redhat.com 2.6.32-550.el6.s390x #1 SMP Fri Apr 3 10:12:50 EDT 2015 s390x s390x s390x GNU/Linux -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 15:04 ` versioning Karel Zak @ 2017-05-17 16:08 ` Ruediger Meier 0 siblings, 0 replies; 27+ messages in thread From: Ruediger Meier @ 2017-05-17 16:08 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux On Wednesday 17 May 2017, Karel Zak wrote: > On Wed, May 17, 2017 at 10:42:53AM +0200, Ruediger Meier wrote: > > v3 just to avoid big numbers. But could also be a hint regarding > > the minimum supported/tested kernel version. I believe that we have > > already a few incompatibilities for kernel <2.6.32. Maybe we could > > cleanup our code, only supporting kernel >=3.1. > > I'm almost sure we have users who use util-linux on old kernels. For > example RHEL6 with 2.6.32 is pretty common and I have no problem to > compile util-linux there. And sometimes we also backport patches from > util-linux upstream to RHEL6 etc ;-) Hehe, I think 2.6.32 LTS is a very good lower boundary and it's almost kernel v3. ;) This version was released in 2009 and widely used (SLE, RHEL, Xen and many devices, routers, etc.). I remember 73f4f3d9 where I fixed a 3 year old bug in ipcs. Probably nobody noticed this. So I don't think that anbody is really using recent ul on even older kernels. > It's fine to kill things for 2.2 (etc.) but for I'd like to be > friendly to 2.6 users (if possible). We could remove <=2.4 hacks from our code, if any. Especially such very old history in the man pages, like tunelp.8: "... the -T option on a 2.0.36 kernel with an tunelp compiled under 2.1.131 or later may have unexpected effects." cu, Rudi > Karel > > > ./lscpu --version > lt-lscpu from util-linux 2.30-rc1-25-b7eb > > $ ./lscpu > Architecture: s390x > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Big Endian > CPU(s): 4 > On-line CPU(s) list: 0-3 > Thread(s) per core: 1 > Core(s) per socket: 1 > Socket(s) per book: 1 > Book(s): 4 > Vendor ID: IBM/S390 > Machine type: 2827 > BogoMIPS: 2913.00 > Hypervisor vendor: (null) > Virtualization type: full > Dispatching mode: horizontal > Flags: esan3 zarch stfle msa ldisp eimm dfp etf3eh > highgprs > > $ uname -a > Linux devel2.s390.bos.redhat.com 2.6.32-550.el6.s390x #1 SMP Fri Apr > 3 10:12:50 EDT 2015 s390x s390x s390x GNU/Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 7:47 versioning Karel Zak 2017-05-17 8:42 ` versioning Ruediger Meier @ 2017-05-17 17:36 ` Bruce Dubbs 2017-05-17 19:07 ` versioning Ruediger Meier 2017-05-17 17:46 ` versioning J William Piggott 2 siblings, 1 reply; 27+ messages in thread From: Bruce Dubbs @ 2017-05-17 17:36 UTC (permalink / raw) To: Karel Zak, util-linux Karel Zak wrote: > > Hi, > > Sami has good point on IRC... do we really want to continue with the > current versioning schema? Now we use: > > v2.xx[.y] > > I don't expect v3 or v4, so the prefix v2 does not provide any > information... and the 'xx' ('30' now) is already large number. > > Suggestions: > > 1) do nothing; nobody cares and v2.31 looks good > > 2) remove '2' from the version: > > major release: v31 > update release: v31.1 > > > 3) <your suggestion>? In managing about 1000 packages, I see a lot of different version numbering. The vast majority of packages use (my terminology) major.minor.point for numbering. The major number really should only be increased when there are incompatibilities introduced in a package update. Sometimes the numbering gets large, For instance the current lvm2 package number is 2.02.171. But that is OK. It tells us that the packages is updated frequently, but there is an effort to maintain backward compatibility. When a package like firefox is at 53.0.2, what does that tell us about the changes? Sometimes the numbering is downright silly. I'll suggest that chromium at 58.0.3029.96 falls into that category. To give you an idea of what other packages use, take a look at http://wiki.linuxfromscratch.org/blfs/browser/trunk/BOOK/packages.ent The bottom line is that from our point of view, x.y.z works fine. There is no need to change the current numbering scheme. -- Bruce Dubbs linuxfromscratch.org ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 17:36 ` versioning Bruce Dubbs @ 2017-05-17 19:07 ` Ruediger Meier 2017-05-17 21:09 ` versioning Karel Zak 0 siblings, 1 reply; 27+ messages in thread From: Ruediger Meier @ 2017-05-17 19:07 UTC (permalink / raw) To: Bruce Dubbs; +Cc: Karel Zak, util-linux On Wednesday 17 May 2017, Bruce Dubbs wrote: > Karel Zak wrote: > > Hi, > > > > Sami has good point on IRC... do we really want to continue with > > the current versioning schema? Now we use: > > > > v2.xx[.y] > > > > I don't expect v3 or v4, so the prefix v2 does not provide any > > information... and the 'xx' ('30' now) is already large number. > > > > Suggestions: > > > > 1) do nothing; nobody cares and v2.31 looks good > > > > 2) remove '2' from the version: > > > > major release: v31 > > update release: v31.1 > > > > > > 3) <your suggestion>? > > In managing about 1000 packages, I see a lot of different version > numbering. The vast majority of packages use (my terminology) > major.minor.point for numbering. > The major number really should only > be increased when there are incompatibilities introduced in a package > update. I agree, so I'd also vote for keeping the current version scheme. But we could talk about some (theoretically) incompatible clean-up changes to justify v3.1. I'm not talking about making things incompatible just to be incompatible but about ugly, outdated ifdefs which probably nobody needs anymore but also nobody would touch unless we actively review this. One thing already mentioned in this thread was to drop any code and documention regarding kernel < 2.6 (maybe even <2.6.32 if it has any benefits). Maybe others have even more ideas, e.g. officially requiring POSIX.1-2008 or newer to cleanup include/c.h, configure.ac, etc.. The benfit would be not only to have a smaller minor version but hopefully to get a few well defined requirements for UL in Documentation/ directory, which will not change until v4. cu, Rudi > Sometimes the numbering gets large, For instance the current lvm2 > package number is 2.02.171. But that is OK. It tells us that the > packages is updated frequently, but there is an effort to maintain > backward compatibility. > > When a package like firefox is at 53.0.2, what does that tell us > about the changes? > > Sometimes the numbering is downright silly. I'll suggest that > chromium at 58.0.3029.96 falls into that category. > > To give you an idea of what other packages use, take a look at > http://wiki.linuxfromscratch.org/blfs/browser/trunk/BOOK/packages.ent > > The bottom line is that from our point of view, x.y.z works fine. > There is no need to change the current numbering scheme. > > -- Bruce Dubbs > linuxfromscratch.org > -- > To unsubscribe from this list: send the line "unsubscribe util-linux" > in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 19:07 ` versioning Ruediger Meier @ 2017-05-17 21:09 ` Karel Zak 2017-05-18 9:29 ` versioning Sami Kerola 0 siblings, 1 reply; 27+ messages in thread From: Karel Zak @ 2017-05-17 21:09 UTC (permalink / raw) To: Ruediger Meier; +Cc: Bruce Dubbs, util-linux On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote: > I'm not talking about making things incompatible just to be incompatible > but about ugly, outdated ifdefs which probably nobody needs anymore but > also nobody would touch unless we actively review this. This would be better to discuss per patch. I don't think the current code is affected by many obscure #ifdef and if we have #ifdef then it's usually to be compatible with some libc, non-linux systems, old gcc, etc. Anyway, it seems the conclusion is to continue with vX.Y.Z :-) Thanks! Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 21:09 ` versioning Karel Zak @ 2017-05-18 9:29 ` Sami Kerola 2017-05-18 10:36 ` versioning Karel Zak 2017-05-18 10:43 ` versioning Ruediger Meier 0 siblings, 2 replies; 27+ messages in thread From: Sami Kerola @ 2017-05-18 9:29 UTC (permalink / raw) To: Karel Zak; +Cc: Ruediger Meier, Bruce Dubbs, util-linux On 17 May 2017 at 22:09, Karel Zak <kzak@redhat.com> wrote: > On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote: >> I'm not talking about making things incompatible just to be incompatible >> but about ugly, outdated ifdefs which probably nobody needs anymore but >> also nobody would touch unless we actively review this. > > This would be better to discuss per patch. I don't think the current > code is affected by many obscure #ifdef and if we have #ifdef then > it's usually to be compatible with some libc, non-linux systems, old > gcc, etc. > > Anyway, it seems the conclusion is to continue with vX.Y.Z :-) So will we get 3.0.0 next and stick with 3.y.z for couple years until numbers grow large? Then v4.y.z and so on. My initial thinking was really as simple as 2.30.0 is a bit large number, and the 2 has not changed for 10 years so maybe it's time to update that. Seeing v31 proposal was interesting, but no. Two number system could also work fine, but there does not seem to be apetite to that. Lets go with concencus and stick with X.Y.Z format. Now when we are talking about versioning - do we get much benefit from rcN series? As far I can tell the project is good shape to release after every single commit. What I don't see is distros using rc series for any users so currently they primarily tell to contributors 'stop sending intrusive crazy stuff for couple weeks, a release is about to happen'. And if that's all these releases do the same could be achieved by sending a maintainer note to maillist informing when is the expected day of next release. In short dropping the -rc's in favour of releasing for real more often is something I would like to see. -- Sami Kerola http://www.iki.fi/kerolasa/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-18 9:29 ` versioning Sami Kerola @ 2017-05-18 10:36 ` Karel Zak 2017-05-18 18:08 ` versioning J William Piggott 2017-05-18 10:43 ` versioning Ruediger Meier 1 sibling, 1 reply; 27+ messages in thread From: Karel Zak @ 2017-05-18 10:36 UTC (permalink / raw) To: kerolasa; +Cc: Ruediger Meier, Bruce Dubbs, util-linux On Thu, May 18, 2017 at 10:29:30AM +0100, Sami Kerola wrote: > On 17 May 2017 at 22:09, Karel Zak <kzak@redhat.com> wrote: > > On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote: > >> I'm not talking about making things incompatible just to be incompatible > >> but about ugly, outdated ifdefs which probably nobody needs anymore but > >> also nobody would touch unless we actively review this. > > > > This would be better to discuss per patch. I don't think the current > > code is affected by many obscure #ifdef and if we have #ifdef then > > it's usually to be compatible with some libc, non-linux systems, old > > gcc, etc. > > > > Anyway, it seems the conclusion is to continue with vX.Y.Z :-) > > So will we get 3.0.0 next and stick with 3.y.z for couple years until Seems like misunderstanding, I've thought that the current v2.nn is good enough and we will continue with it (and maybe one day after some significant changes we will switch to v3.nn, and so on). > numbers grow large? Then v4.y.z and so on. My initial thinking was really > as simple as 2.30.0 is a bit large number, and the 2 has not changed for 10 > years so maybe it's time to update that. ... > Now when we are talking about versioning - do we get much benefit from rcN > series? Well, it would be nice to somehow force people to use -rcN release to test things :-) The important thing on rcN is that we have official tarball, so you can use it independently on git, add to distros etc. I usually push all rc releases to unstable Fedora, sometimes I get feedback. -rc1 is also time when I work on reports from coverity and another static analyzers. So, for me it makes sense, but it's nothing critical. > As far I can tell the project is good shape to release after every > single commit. What I don't see is distros using rc series for any users so > currently they primarily tell to contributors 'stop sending intrusive crazy > stuff for couple weeks, a release is about to happen'. And if that's all > these releases do the same could be achieved by sending a maintainer note to > maillist informing when is the expected day of next release. We need time to freeze the code (at least for one week) for translators (usually -rc2). This is the minimal requirement. > In short dropping the -rc's in favour of releasing for real more often is > something I would like to see. My wish is to release more often (~4 month), but not sure why it's always more months :-)) For v2.30 my schedule is: - Thu May 23 -rc2 - Thu May 30 release For the next releases it would be probably nice to prepare schedule for all year and always publish schedule for the next release immediately after the previous release - Sep 16 -- feature freeze, no invasive changes allowed (aka rc1) - Sep 19 -- strings freeze, translations (aka rc2) - Sep 26 -- v2.31 - Jan 16 -- feature freeze, no invasive changes allowed (aka rc1) - Jan 23 -- strings freeze, translations (aka rc2) - Jan 30 -- v2.32 ... etc. It means release every 4 month, last Tuesday in the month; one week between -rcN (so... 14 days freeze every 4 month, IMHO not so bad). Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-18 10:36 ` versioning Karel Zak @ 2017-05-18 18:08 ` J William Piggott 2017-05-18 19:56 ` versioning Karel Zak 0 siblings, 1 reply; 27+ messages in thread From: J William Piggott @ 2017-05-18 18:08 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux On 05/18/2017 06:36 AM, Karel Zak wrote: 8< --- > > The important thing on rcN is that we have official tarball, so you > can use it independently on git, add to distros etc. 8< --- Karel, I pull from github and haven't seen a new tag since v2.29. Perhaps I should be pulling from kernel.org, but github should work, no? Also, it looks like Documentation/source-code-management.txt needs to be updated. There are no bugfix branches, only tags. Isn't the KNOWN BUGS: referring to the v2.13.1 branch as a typo, not the tag? > Karel > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-18 18:08 ` versioning J William Piggott @ 2017-05-18 19:56 ` Karel Zak 2017-05-18 20:55 ` versioning Rüdiger Meier 0 siblings, 1 reply; 27+ messages in thread From: Karel Zak @ 2017-05-18 19:56 UTC (permalink / raw) To: J William Piggott; +Cc: util-linux On Thu, May 18, 2017 at 02:08:49PM -0400, J William Piggott wrote: > On 05/18/2017 06:36 AM, Karel Zak wrote: > > 8< --- > > > > > The important thing on rcN is that we have official tarball, so you > > can use it independently on git, add to distros etc. > > 8< --- > > Karel, > I pull from github and haven't seen a new tag since v2.29. Perhaps I > should be pulling from kernel.org, but github should work, no? I push to the both repos in the same time $ git push; git push github master; git push --tags; git push github --tags Everything up-to-date Everything up-to-date Everything up-to-date Everything up-to-date And I see the tags at https://github.com/karelzak/util-linux/tags > Also, it looks like Documentation/source-code-management.txt needs to be > updated. There are no bugfix branches, only tags. Good point. Updated. > Isn't the KNOWN BUGS: > referring to the v2.13.1 branch as a typo, not the tag? $ git tag -l | grep v2.13.1 v2.13.1 v2.13.1-REAL v2.13.1-rc1 v2.13.1-rc2 v2.13.1.1 the first line is unwanted tag... it would be possible to delete it, but I don't think that remove already published tags is a good idea. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-18 19:56 ` versioning Karel Zak @ 2017-05-18 20:55 ` Rüdiger Meier 2017-05-19 8:12 ` versioning Karel Zak 2017-05-19 19:00 ` versioning J William Piggott 0 siblings, 2 replies; 27+ messages in thread From: Rüdiger Meier @ 2017-05-18 20:55 UTC (permalink / raw) To: Karel Zak, J William Piggott; +Cc: util-linux On 05/18/2017 09:56 PM, Karel Zak wrote: > On Thu, May 18, 2017 at 02:08:49PM -0400, J William Piggott wrote: >> On 05/18/2017 06:36 AM, Karel Zak wrote: >> >> 8< --- >> >>> >>> The important thing on rcN is that we have official tarball, so you >>> can use it independently on git, add to distros etc. >> >> 8< --- >> >> Karel, >> I pull from github and haven't seen a new tag since v2.29. Perhaps I >> should be pulling from kernel.org, but github should work, no? I think "git pull" does not always give you all the tags. In doubt I do explicitly "git fetch --tag remote-name". Maybe "git pull" only pulls tags if remote-name == origin, I still don't got the full logic. > I push to the both repos in the same time > > $ git push; git push github master; git push --tags; git push github --tags > Everything up-to-date > Everything up-to-date > Everything up-to-date > Everything up-to-date > > And I see the tags at https://github.com/karelzak/util-linux/tags > >> Also, it looks like Documentation/source-code-management.txt needs to be >> updated. There are no bugfix branches, only tags. > > Good point. Updated. > >> Isn't the KNOWN BUGS: >> referring to the v2.13.1 branch as a typo, not the tag? > > $ git tag -l | grep v2.13.1 > v2.13.1 > v2.13.1-REAL > v2.13.1-rc1 > v2.13.1-rc2 > v2.13.1.1 > > the first line is unwanted tag... it would be possible to delete it, but I > don't think that remove already published tags is a good idea. It should not be a problem to delete tags like it's no problem to delete branches. Only rebasing branches or re-creating conflicting tags could be annoying or at least confusing. cu, Rudi > Karel > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-18 20:55 ` versioning Rüdiger Meier @ 2017-05-19 8:12 ` Karel Zak 2017-05-19 19:00 ` versioning J William Piggott 1 sibling, 0 replies; 27+ messages in thread From: Karel Zak @ 2017-05-19 8:12 UTC (permalink / raw) To: Rüdiger Meier; +Cc: J William Piggott, util-linux On Thu, May 18, 2017 at 10:55:41PM +0200, Rüdiger Meier wrote: > It should not be a problem to delete tags like it's no problem to delete > branches. Only rebasing branches or re-creating conflicting tags could be > annoying or at least confusing. It should be re-taged rather than deleted and it's the problem. I don't think it's important after the years. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-18 20:55 ` versioning Rüdiger Meier 2017-05-19 8:12 ` versioning Karel Zak @ 2017-05-19 19:00 ` J William Piggott 2017-05-20 19:34 ` versioning Karel Zak 1 sibling, 1 reply; 27+ messages in thread From: J William Piggott @ 2017-05-19 19:00 UTC (permalink / raw) To: Rüdiger Meier, Karel Zak; +Cc: util-linux On 05/18/2017 04:55 PM, Rüdiger Meier wrote: > > > On 05/18/2017 09:56 PM, Karel Zak wrote: >> On Thu, May 18, 2017 at 02:08:49PM -0400, J William Piggott wrote: >>> On 05/18/2017 06:36 AM, Karel Zak wrote: >>> >>> 8< --- >>> >>>> >>>> The important thing on rcN is that we have official tarball, so you >>>> >>>> can use it independently on git, add to distros etc. >>>> >>> >>> 8< --- >>> >>> Karel, I pull from github and haven't seen a new tag since v2.29. >>> Perhaps I should be pulling from kernel.org, but github should work, >>> no? > > I think "git pull" does not always give you all the tags. In doubt I > do explicitly "git fetch --tag remote-name". Maybe "git pull" only > pulls tags if remote-name == origin, I still don't got the full logic. Using 'git pull' against master fetched the tags up through v2.29. Then it stopped. git-pull(1): By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. If a tag is created from the master branch, then (with the default configuration) pulling the master branch will pull the tag as well. I think perhaps Karel changed his bugfix release workflow and started creating them from a working branch. I say that because the v2.30-ReleaseNotes file never hit my local repo, the master branch, until May 16th. That is why I submitted my patch for it as a simple diff instead of a git format-patch. It seems to me that the working branch should be merged into master first, and then create the tag, tarball, etc. from master. That way pulling master will fetch the release tags. That should be expected behavior. IMO, creating releases from an ephemeral branch, or anything other than master, is asking for headaches. >> I push to the both repos in the same time >> $ git push; git push github master; git push --tags; git push github --tags I think it would be better to: git push --follow-tags; git push --follow-tags github master This would be a good crosscheck to know that the release tags were created against master and not some other branch. Also, one day you may want to have some private tags and --tags will push everything. Whereas, --follow-tags will only push tags associated with what is being pushed, that is, the master branch. 8< --- >> >>> Isn't the KNOWN BUGS: referring to the v2.13.1 branch as a typo, not >>> the tag? >> >> $ git tag -l | grep v2.13.1 v2.13.1 v2.13.1-REAL >> >> v2.13.1-rc1 >> >> v2.13.1-rc2 >> >> v2.13.1.1 >> >> the first line is unwanted tag... it would be possible to delete it, >> but I don't think that remove already published tags is a good idea. I see, but isn't the v2.13.1 branch a 'bug' also, because there are not any bugfix release branches? Well like you said, it's old and doesn't matter much now. > > It should not be a problem to delete tags like it's no problem to > delete branches. Only rebasing branches or re-creating conflicting > tags could be annoying or at least confusing. > > > cu, Rudi > > > >> >> Karel >> > -- To unsubscribe from this list: send the line "unsubscribe > util-linux" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-19 19:00 ` versioning J William Piggott @ 2017-05-20 19:34 ` Karel Zak 2017-05-22 21:37 ` versioning J William Piggott 0 siblings, 1 reply; 27+ messages in thread From: Karel Zak @ 2017-05-20 19:34 UTC (permalink / raw) To: J William Piggott; +Cc: Rüdiger Meier, util-linux On Fri, May 19, 2017 at 03:00:14PM -0400, J William Piggott wrote: > > > > I think "git pull" does not always give you all the tags. In doubt I > > do explicitly "git fetch --tag remote-name". Maybe "git pull" only > > pulls tags if remote-name == origin, I still don't got the full logic. > > Using 'git pull' against master fetched the tags up through v2.29. Then > it stopped. > > git-pull(1): By default, tags that point at objects that are downloaded > from the remote repository are fetched and stored locally. > > If a tag is created from the master branch, then (with the default > configuration) pulling the master branch will pull the tag as well. > > I think perhaps Karel changed his bugfix release workflow and started > creating them from a working branch. I always use master branch. $ git branch --contains v2.30-rc1 * master > I say that because the > v2.30-ReleaseNotes file never hit my local repo, the master branch, > until May 16th. That is why I submitted my patch for it as a simple diff > instead of a git format-patch. https://github.com/karelzak/util-linux/blob/master/Documentation/releases/v2.30-ReleaseNotes ^^^^^^ as well as on kernel.org: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tag/?h=v2.30-rc1 > It seems to me that the working branch should be merged into master > first, and then create the tag, tarball, etc. from master. That way > pulling master will fetch the release tags. That should be expected > behavior. > > IMO, creating releases from an ephemeral branch, or anything other than > master, is asking for headaches. Maybe you need 'git clean -xdf' before 'git pull' or so. > >> I push to the both repos in the same time > >> $ git push; git push github master; git push --tags; git push github --tags > > I think it would be better to: > > git push --follow-tags; git push --follow-tags github master $ git push --follow-tags; git push --follow-tags github master Everything up-to-date Everything up-to-date > This would be a good crosscheck to know that the release tags were > created against master and not some other branch. > > Also, one day you may want to have some private tags and --tags will > push everything. Whereas, --follow-tags will only push tags associated > with what is being pushed, that is, the master branch. OK. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-20 19:34 ` versioning Karel Zak @ 2017-05-22 21:37 ` J William Piggott 2017-05-23 7:57 ` versioning Karel Zak 0 siblings, 1 reply; 27+ messages in thread From: J William Piggott @ 2017-05-22 21:37 UTC (permalink / raw) To: Karel Zak; +Cc: Rüdiger Meier, util-linux On 05/20/2017 03:34 PM, Karel Zak wrote: > On Fri, May 19, 2017 at 03:00:14PM -0400, J William Piggott wrote: >> git-pull(1): By default, tags that point at objects that are downloaded >> from the remote repository are fetched and stored locally. >> >> If a tag is created from the master branch, then (with the default >> configuration) pulling the master branch will pull the tag as well. >> >> I think perhaps Karel changed his bugfix release workflow and started >> creating them from a working branch. > > I always use master branch. > > $ git branch --contains v2.30-rc1 > * master > So, I muddied the waters by talking about two different topics. What I really want to discuss are bugfix releases: v2.xx.x. The following comment should have been a separate topic. I mentioned it only because the odd behavior that I experienced with the recent rc release sparked the thought that the bugfix releases are being created in a working branch and that could explain why 'git pull' is not fetching their tags. >> I say that because the >> v2.30-ReleaseNotes file never hit my local repo, the master branch, >> until May 16th. That is why I submitted my patch for it as a simple diff >> instead of a git format-patch. > > https://github.com/karelzak/util-linux/blob/master/Documentation/releases/v2.30-ReleaseNotes > ^^^^^^ > > as well as on kernel.org: > > https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tag/?h=v2.30-rc1 I wasn't trying to say that this file isn't in 'master', nor that the stable releases cannot be reached from 'master'; they certainly can be as they are in the 'master' commit log. What I was saying is that the release was on May 12. The commit the tag references hit my repo on May 14, but the v2.30-ReleaseNotes file did not pull until May 16; May 15 had nothing: $ find -newermt "-12 day" -printf "%TD %p\n" | sort 8< ... 05/14/17 ./AUTHORS 05/14/17 ./NEWS 05/14/17 ./aclocal.m4 05/14/17 ./config.h.in 05/14/17 ./configure.ac 05/14/17 ./po/ca.po 8< ... 05/16/17 ./Documentation/TODO 05/16/17 ./Documentation/releases/v2.30-ReleaseNotes This seems odd to me, but has all worked out now. The v2.30-rc1 tag contains the unpatched v2.30-ReleaseNotes without the security warnings, but I guess that is what v2.30-rc2 is for ;) Enough of that, the real topic is below. > >> It seems to me that the working branch should be merged into master >> first, and then create the tag, tarball, etc. from master. That way >> pulling master will fetch the release tags. That should be expected >> behavior. >> >> IMO, creating releases from an ephemeral branch, or anything other than >> master, is asking for headaches. > > Maybe you need 'git clean -xdf' before 'git pull' or so. > The bugfix tags 2.xx.x are from another branch and not reachable from 'master', it's not because my local repo is dirty. Here is an example with a fresh repo: S git clone https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git 8< ... $ cd util-linux $ git branch --contains v2.29.1 $ git branch --contains v2.29.2 $ git branch --contains v2.28.1 $ git branch --contains v2.27.1 $ git branch --contains v2.26.1 $ git branch --contains v2.25.1 $ git branch --contains v2.24.1 $ git branch --contains v2.23.1 $ git branch --contains v2.22.1 $ git branch --contains v2.21.1 $ git branch --contains v2.20.1 $ git branch --contains v2.19.1 $ git branch --contains v2.17.1 $ git branch --contains v2.16.1 $ git branch --contains v2.15.1 $ git branch --contains v2.14.1 $ git branch --contains v2.13.1 For example this tag was created from a working branch: $ git show v2.29.1 8< ... commit 9ebc8a7a882ddfd93bc3262514791a0dcaadba09 Author: Karel Zak <kzak@redhat.com> Date: Fri Jan 20 14:13:08 2017 +0100 build-sys: release++ (v2.29.1) Signed-off-by: Karel Zak <kzak@redhat.com> 8< ... ____________________________________________________ The commit, and therefore the tag, is not in 'master' and is not reachable from master. Some issues with this model: * 'git pull upstream master', etcetera, will not fetch the bugfix release tags because they are not reachable from 'master'. This could be unexpected behavior for someone new to the project. * A checked-out bugfix release tag has all of the releases in the NEWS file. Whereas, 'master' omits the bugfix releases. * A checked-out bugfix release tag has all of the v*-ReleaseNotes. Whereas, 'master' omits all of the bugfix v2.xx.x-ReleaseNotes. * The previous two make these orphaned tags more complete then 'master' is. * I don't know this for a fact, but I suspect that due to the tags not being reachable from any branch that they might have to store the entire file tree? If yes, it means more bandwidth and storage use. These aren't issues for me personally, I just thought it was something the project should consider. My thoughts are that bugfix releases should be committed to 'master' the same as the stable/rc releases are. Then the tag created from that commit. >>>> I push to the both repos in the same time >>>> $ git push; git push github master; git push --tags; git push github --tags >> >> I think it would be better to: >> >> git push --follow-tags; git push --follow-tags github master > > $ git push --follow-tags; git push --follow-tags github master > Everything up-to-date > Everything up-to-date > Well, 'git push --tags' already uploaded all of the tags, so at the moment using --follow-tags isn't very meaningful. It could be in the future though. Of course, if the bugfix tags continue to be unreachable from master, then you will have to go back to using 'git push --tags'. >> This would be a good crosscheck to know that the release tags were >> created against master and not some other branch. >> >> Also, one day you may want to have some private tags and --tags will >> push everything. Whereas, --follow-tags will only push tags associated >> with what is being pushed, that is, the master branch. > > OK. > > Karel > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-22 21:37 ` versioning J William Piggott @ 2017-05-23 7:57 ` Karel Zak 2017-05-23 8:05 ` versioning Karel Zak 0 siblings, 1 reply; 27+ messages in thread From: Karel Zak @ 2017-05-23 7:57 UTC (permalink / raw) To: J William Piggott; +Cc: Rüdiger Meier, util-linux On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote: > My thoughts are that bugfix releases should be committed to 'master' the > same as the stable/rc releases are. Then the tag created from that commit. How do you want to commit bugfix release (e.g. v2.29.2) to the 'master' if the master and 'stable/' branches contain a different code? The current workflow: 1) development (branch: <master>) 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>) 3) development (work on v2.30, branch: <master>) 4) fork -- create a new branch <stable/v2.29> based on tag v2.29 4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>) 4b) stable release (tag: v2.29.1, branch: <stable/v2.29>) 4c) another patches, another release (tag: v2.29.2, branch: <stable/v2.29>) 5) master release v2.30 (branch: <master>) ... where 3) and 4) happen in the same time. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-23 7:57 ` versioning Karel Zak @ 2017-05-23 8:05 ` Karel Zak 2017-05-23 20:54 ` versioning J William Piggott 0 siblings, 1 reply; 27+ messages in thread From: Karel Zak @ 2017-05-23 8:05 UTC (permalink / raw) To: J William Piggott; +Cc: Rüdiger Meier, util-linux On Tue, May 23, 2017 at 09:57:33AM +0200, Karel Zak wrote: > On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote: > > My thoughts are that bugfix releases should be committed to 'master' the > > same as the stable/rc releases are. Then the tag created from that commit. > > How do you want to commit bugfix release (e.g. v2.29.2) to the > 'master' if the master and 'stable/' branches contain a different > code? > > The current workflow: > > 1) development (branch: <master>) > > 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>) > > 3) development (work on v2.30, branch: <master>) > > 4) fork -- create a new branch <stable/v2.29> based on tag v2.29 > > 4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>) > > 4b) stable release (tag: v2.29.1, branch: <stable/v2.29>) > > 4c) another patches, another release (tag: v2.29.2, branch: <stable/v2.29>) > > 5) master release v2.30 (branch: <master>) > ... > > > where 3) and 4) happen in the same time. And yes, NEWS file in the master does not contain info about maintenance release (e.g. v2.29.1). Maybe it's mistake. This information is in the ReleaseNotes where are links to the previous maintenance releases. We can add a hint about maintenance releases to the master branch NEWS file, but stable maintenance tags (v2.29.1) has to be in the stable/ branches. It's released code what has to be tagged and signed. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-23 8:05 ` versioning Karel Zak @ 2017-05-23 20:54 ` J William Piggott 2017-05-24 10:02 ` versioning Ruediger Meier 2017-05-27 18:55 ` versioning J William Piggott 0 siblings, 2 replies; 27+ messages in thread From: J William Piggott @ 2017-05-23 20:54 UTC (permalink / raw) To: Karel Zak; +Cc: Rüdiger Meier, util-linux On 05/23/2017 04:05 AM, Karel Zak wrote: > On Tue, May 23, 2017 at 09:57:33AM +0200, Karel Zak wrote: >> On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote: >>> My thoughts are that bugfix releases should be committed to 'master' the >>> same as the stable/rc releases are. Then the tag created from that commit. >> >> How do you want to commit bugfix release (e.g. v2.29.2) to the >> 'master' if the master and 'stable/' branches contain a different >> code? >> >> The current workflow: >> >> 1) development (branch: <master>) >> >> 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>) >> >> 3) development (work on v2.30, branch: <master>) >> >> 4) fork -- create a new branch <stable/v2.29> based on tag v2.29 >> >> 4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>) >> >> 4b) stable release (tag: v2.29.1, branch: <stable/v2.29>) >> >> 4c) another patches, another release (tag: v2.29.2, branch: <stable/v2.29>) >> >> 5) master release v2.30 (branch: <master>) >> ... >> >> >> where 3) and 4) happen in the same time. Argh, my brain was broken. I wrongheadedly believed that this project was using linear development. > > And yes, NEWS file in the master does not contain info about > maintenance release (e.g. v2.29.1). Maybe it's mistake. No, I was the mistake ;) > > This information is in the ReleaseNotes where are links to the > previous maintenance releases. > > We can add a hint about maintenance releases to the master branch NEWS > file, but stable maintenance tags (v2.29.1) has to be in the stable/ > branches. It's released code what has to be tagged and signed. It's all clear now that you've pulled my head out of ... its 'master' branch walled garden. The stable maintenance tags are not reachable from, pulled by, or have anything else to do with the 'master' branch. They belong only to their respective forked stable branches being developed independently. Hinting about them in master would probably be misleading. I think I will submit a patch to add something to Documentation about this so that someone else might not ask the same dumb questions. With your permission, I might include your well written workflow description. Sorry for wasting your time Karel (and anyone else reading this). Thank you for setting me straight. > > Karel > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-23 20:54 ` versioning J William Piggott @ 2017-05-24 10:02 ` Ruediger Meier 2017-05-27 18:55 ` versioning J William Piggott 1 sibling, 0 replies; 27+ messages in thread From: Ruediger Meier @ 2017-05-24 10:02 UTC (permalink / raw) To: J William Piggott; +Cc: Karel Zak, util-linux On Tuesday 23 May 2017, J William Piggott wrote: > On 05/23/2017 04:05 AM, Karel Zak wrote: > > On Tue, May 23, 2017 at 09:57:33AM +0200, Karel Zak wrote: > >> On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote: > >>> My thoughts are that bugfix releases should be committed to > >>> 'master' the same as the stable/rc releases are. Then the tag > >>> created from that commit. > >> > >> How do you want to commit bugfix release (e.g. v2.29.2) to the > >> 'master' if the master and 'stable/' branches contain a different > >> code? > >> > >> The current workflow: > >> > >> 1) development (branch: <master>) > >> > >> 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: > >> <master>) > >> > >> 3) development (work on v2.30, branch: <master>) > >> > >> 4) fork -- create a new branch <stable/v2.29> based on tag v2.29 > >> > >> 4a) new patches or cherry-pick patches from <master> (branch: > >> <stable/v2.29>) > >> > >> 4b) stable release (tag: v2.29.1, branch: <stable/v2.29>) > >> > >> 4c) another patches, another release (tag: v2.29.2, branch: > >> <stable/v2.29>) > >> > >> 5) master release v2.30 (branch: <master>) > >> ... > >> > >> > >> where 3) and 4) happen in the same time. > > Argh, my brain was broken. I wrongheadedly believed that this project > was using linear development. > > > And yes, NEWS file in the master does not contain info about > > maintenance release (e.g. v2.29.1). Maybe it's mistake. > > No, I was the mistake ;) > > > This information is in the ReleaseNotes where are links to the > > previous maintenance releases. > > > > We can add a hint about maintenance releases to the master branch > > NEWS file, but stable maintenance tags (v2.29.1) has to be in the > > stable/ branches. It's released code what has to be tagged and > > signed. > > It's all clear now that you've pulled my head out of ... its 'master' > branch walled garden. The stable maintenance tags are not reachable > from, pulled by, or have anything else to do with the 'master' > branch. They belong only to their respective forked stable branches > being developed independently. Hinting about them in master would > probably be misleading. > > I think I will submit a patch to add something to Documentation about > this so that someone else might not ask the same dumb questions. With > your permission, I might include your well written workflow > description. FYI there is also "man 7 gitworkflows", worth to read IMO. Beside the trivial fact that they use "maint" instead of "stable" they always provide one non-versioned "stable" branch which contains *all* tags, more easy to be followed by users. To be able to do that they *commit* bugfixes only to "stable" and *merge* them into master (instead of cherry-picking from master). cu, Rudi > Sorry for wasting your time Karel (and anyone else reading this). > Thank you for setting me straight. > > > Karel > > -- > To unsubscribe from this list: send the line "unsubscribe util-linux" > in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-23 20:54 ` versioning J William Piggott 2017-05-24 10:02 ` versioning Ruediger Meier @ 2017-05-27 18:55 ` J William Piggott 2017-05-29 10:22 ` versioning Karel Zak 1 sibling, 1 reply; 27+ messages in thread From: J William Piggott @ 2017-05-27 18:55 UTC (permalink / raw) To: Karel Zak; +Cc: Rüdiger Meier, util-linux On 05/23/2017 04:54 PM, J William Piggott wrote: > > I think I will submit a patch to add something to Documentation about > this so that someone else might not ask the same dumb questions. I started on this and noticed that the source-code-management.txt and README files are very similar. README actually has a more complete version schema breakdown. Is there any reason that they should not be combined into a single file? I think maintaining a single file for links, contacts, repo locations, etc. makes things easier. There are only three files referencing source-code-management.txt, one of them is README. Seems okay to have the other two files point at the README file instead? README includes the mailing list. Is there any reason that the IRC channel shouldn't be there instead of in howto-contribute.txt? The howto-contribute.txt file says patches can be sent to the mailing list or directly to Karel, and points to README for the addresses. Is there any reason not to have Karel's email contact in the README? > > Sorry for wasting your time Karel (and anyone else reading this). Thank > you for setting me straight. > > >> >> Karel >> > -- > To unsubscribe from this list: send the line "unsubscribe util-linux" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-27 18:55 ` versioning J William Piggott @ 2017-05-29 10:22 ` Karel Zak 0 siblings, 0 replies; 27+ messages in thread From: Karel Zak @ 2017-05-29 10:22 UTC (permalink / raw) To: J William Piggott; +Cc: Rüdiger Meier, util-linux On Sat, May 27, 2017 at 02:55:41PM -0400, J William Piggott wrote: > > > On 05/23/2017 04:54 PM, J William Piggott wrote: > > > > I think I will submit a patch to add something to Documentation about > > this so that someone else might not ask the same dumb questions. > > I started on this and noticed that the source-code-management.txt and > README files are very similar. README actually has a more complete > version schema breakdown. Is there any reason that they should not be > combined into a single file? No problem, but I'd like to keep all most important information (=links, addresses, etc.) in the README file. Send patch :-) > README includes the mailing list. Is there any reason that the IRC > channel shouldn't be there instead of in howto-contribute.txt? Send patch :-) > The howto-contribute.txt file says patches can be sent to the mailing > list or directly to Karel, and points to README for the addresses. Is > there any reason not to have Karel's email contact in the README? I don't think it's so important, but no problem to change it. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-18 9:29 ` versioning Sami Kerola 2017-05-18 10:36 ` versioning Karel Zak @ 2017-05-18 10:43 ` Ruediger Meier 1 sibling, 0 replies; 27+ messages in thread From: Ruediger Meier @ 2017-05-18 10:43 UTC (permalink / raw) To: kerolasa; +Cc: Karel Zak, Bruce Dubbs, util-linux On Thursday 18 May 2017, Sami Kerola wrote: > On 17 May 2017 at 22:09, Karel Zak <kzak@redhat.com> wrote: > > On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote: > >> I'm not talking about making things incompatible just to be > >> incompatible but about ugly, outdated ifdefs which probably nobody > >> needs anymore but also nobody would touch unless we actively > >> review this. > > > > This would be better to discuss per patch. I don't think the > > current code is affected by many obscure #ifdef and if we have > > #ifdef then it's usually to be compatible with some libc, non-linux > > systems, old gcc, etc. > > > > Anyway, it seems the conclusion is to continue with vX.Y.Z :-) > > So will we get 3.0.0 next and stick with 3.y.z for couple years until > numbers grow large? Then v4.y.z and so on. My initial thinking was > really as simple as 2.30.0 is a bit large number, and the 2 has not > changed for 10 years so maybe it's time to update that. > > Seeing v31 proposal was interesting, but no. Two number system could > also work fine, but there does not seem to be apetite to that. Lets > go with concencus and stick with X.Y.Z format. > > Now when we are talking about versioning - do we get much benefit > from rcN series? I think some distro maintainers use and test it to report bugs before final release. Maybe even translaters use it. The benfit for them is that they need less dependencies for the build. Also the rcN tag makes them able to get informed automatically a few times per year rather then continuously following our master branch or mailing list. Only for cosmetics I would remove the old rcN tarballs from the server. Nobody needs them nor should still use them after release. > As far I can tell the project is good shape to > release after every single commit. What I don't see is distros using > rc series for any users so currently they primarily tell to > contributors 'stop sending intrusive crazy stuff for couple weeks, a > release is about to happen'. And if that's all these releases do the > same could be achieved by sending a maintainer note to maillist > informing when is the expected day of next release. > > In short dropping the -rc's in favour of releasing for real more > often is something I would like to see. IMO we are releasing often enough. Personally I find the stable bug fix releases most interesting. If I want a more recent UL I would build from git anyways. cu, Rudi ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: versioning 2017-05-17 7:47 versioning Karel Zak 2017-05-17 8:42 ` versioning Ruediger Meier 2017-05-17 17:36 ` versioning Bruce Dubbs @ 2017-05-17 17:46 ` J William Piggott 2 siblings, 0 replies; 27+ messages in thread From: J William Piggott @ 2017-05-17 17:46 UTC (permalink / raw) To: Karel Zak, util-linux On 05/17/2017 03:47 AM, Karel Zak wrote: > > Hi, > > Sami has good point on IRC... do we really want to continue with the > current versioning schema? Now we use: > > v2.xx[.y] > > I don't expect v3 or v4, so the prefix v2 does not provide any > information... and the 'xx' ('30' now) is already large number. > > Suggestions: > > 1) do nothing; nobody cares and v2.31 looks good I'd vote for number one. > > 2) remove '2' from the version: > > major release: v31 > update release: v31.1 > > > 3) <your suggestion>? > > > Note that for v2.30 is to late to do any change in version numbers > (we need changes in our libraries and I have to update some my scripts). > > Karel > ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2017-05-29 10:22 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-17 7:47 versioning Karel Zak 2017-05-17 8:42 ` versioning Ruediger Meier 2017-05-17 8:47 ` versioning Ruediger Meier 2017-05-17 13:23 ` versioning Bernhard Voelker 2017-05-17 13:51 ` versioning Karel Zak 2017-05-17 15:04 ` versioning Karel Zak 2017-05-17 16:08 ` versioning Ruediger Meier 2017-05-17 17:36 ` versioning Bruce Dubbs 2017-05-17 19:07 ` versioning Ruediger Meier 2017-05-17 21:09 ` versioning Karel Zak 2017-05-18 9:29 ` versioning Sami Kerola 2017-05-18 10:36 ` versioning Karel Zak 2017-05-18 18:08 ` versioning J William Piggott 2017-05-18 19:56 ` versioning Karel Zak 2017-05-18 20:55 ` versioning Rüdiger Meier 2017-05-19 8:12 ` versioning Karel Zak 2017-05-19 19:00 ` versioning J William Piggott 2017-05-20 19:34 ` versioning Karel Zak 2017-05-22 21:37 ` versioning J William Piggott 2017-05-23 7:57 ` versioning Karel Zak 2017-05-23 8:05 ` versioning Karel Zak 2017-05-23 20:54 ` versioning J William Piggott 2017-05-24 10:02 ` versioning Ruediger Meier 2017-05-27 18:55 ` versioning J William Piggott 2017-05-29 10:22 ` versioning Karel Zak 2017-05-18 10:43 ` versioning Ruediger Meier 2017-05-17 17:46 ` versioning J William Piggott
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.