It has been my practice for some time to always upload all of the
packages when one of them changes. This includes patch releases such as
4.5.5.3.
You may recall that I originally uploaded only changed packages but that
seemed to cause angst among the user population.
Recent questions from the Debian release team about the current practice
have prompted me to revisit the issue. As I see it, there are three
possible approaches:
1) Continue to release all packages.
2) Continue to release all packages and indicate which of them
actually changed. That would allow individual packagers to release
some or all of them.
3) Only release the changed packages.
We could, of course, have one policy for regular releases and another
one for patch releases.
I welcome all comments and suggestions.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today''s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> It has been my practice for some time to always upload all of the > packages when one of them changes. This includes patch releases such as > 4.5.5.3. > > You may recall that I originally uploaded only changed packages but that > seemed to cause angst among the user population. > > Recent questions from the Debian release team about the current practice > have prompted me to revisit the issue. As I see it, there are three > possible approaches: > > 1) Continue to release all packages.May I suggest to NOT change the system again, not the release system, not the install system nor the packaging options built into the Shorewall distribution! There are many more packagers than the Debian or Fedora folks. Maybe they don''t speak out, but still have to reflect all the changes which have been done in the past in their kind of packages. And there were many changes in the last couple of months... I prefer if the Shorewall devs - of course mainly you Tom :) - do work on Shorewall itself. Thanks Tom, you are doing an excellent job! Regards, Simon ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 07/19/2012 08:11 AM, Simon Matter wrote:>> It has been my practice for some time to always upload all of the >> packages when one of them changes. This includes patch releases such as >> 4.5.5.3. >> >> You may recall that I originally uploaded only changed packages but that >> seemed to cause angst among the user population. >> >> Recent questions from the Debian release team about the current practice >> have prompted me to revisit the issue. As I see it, there are three >> possible approaches: >> >> 1) Continue to release all packages. > > May I suggest to NOT change the system again, not the release system, not > the install system nor the packaging options built into the Shorewall > distribution! > There are many more packagers than the Debian or Fedora folks. Maybe they > don''t speak out, but still have to reflect all the changes which have been > done in the past in their kind of packages. And there were many changes in > the last couple of months... > > I prefer if the Shorewall devs - of course mainly you Tom :) - do work on > Shorewall itself. > Thanks Tom, you are doing an excellent job!Hi Simon, My build and release system was designed to be able to build and release individual products. So it won''t require any development work on my part. Regards, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 19 July 2012 10:31, Tom Eastep <teastep@shorewall.net> wrote:> Recent questions from the Debian release team about the current practice > have prompted me to revisit the issue. As I see it, there are three > possible approaches: > > 1) Continue to release all packages. > > 2) Continue to release all packages and indicate which of them > actually changed. That would allow individual packagers to release > some or all of them. >With my Fedora packager hat on, I''d prefer one of the above.> 3) Only release the changed packages. >This just gets more fiddly and error prone in my opinion. Keeping all tarball versions in lock step is easy for boneheads like me to follow. J.> We could, of course, have one policy for regular releases and another > one for patch releases. > > I welcome all comments and suggestions. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel >------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 20/07/12 02:05, Jonathan Underwood wrote:> On 19 July 2012 10:31, Tom Eastep <teastep@shorewall.net> wrote: >> Recent questions from the Debian release team about the current practice >> have prompted me to revisit the issue. As I see it, there are three >> possible approaches: >> >> 1) Continue to release all packages. >> >> 2) Continue to release all packages and indicate which of them >> actually changed. That would allow individual packagers to release >> some or all of them. >> > With my Fedora packager hat on, I''d prefer one of the above.I agree with Jonathan. With my non-packager, mostly-non-developer hat on, i think that keeping the versions lock-stepped follows the principle of least surprise for Shorewall''s users. It might save hours of effort for developers & packagers by not having them lock-stepped, but it will save hundreds of hours of confusion and dozens of questions on the mailing list if we keep it the way it is. Paul ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Fri, Jul 20, 2012 at 08:57:45AM +1000, Paul Gear wrote:> > I agree with Jonathan. With my non-packager, mostly-non-developer hat > on, i think that keeping the versions lock-stepped follows the principle > of least surprise for Shorewall''s users. It might save hours of effort > for developers & packagers by not having them lock-stepped, but it will > save hundreds of hours of confusion and dozens of questions on the > mailing list if we keep it the way it is. >On the flip side, Debian has just entered the freeze period for the next stable release. So, any new releases introduced into Debian must reeceive a freeze exception in order to be allowed to propogate. Since it is the practice of the release managers to not allow gratiutous changes, I have to choose one of these options: 1) (assuming all packages are released each time) I upload only the packages which actually changed (potentially confuses users since the Debian packages get out of sync with respect to version numbers i.e., they are not all in lock step) 2) (assuming all packages are released each time) I patch in the specific changes and upload them as a new Debian revision, which risks confusing users even more 3) (assuming only changed packages are released each time) I keep the Debian packages in sync and there is no confusion since upstream and Debian match up Personally, I like the last option, since that would be the "least surprise" to me (and I would think to users). Of course, there are people out there using just upstream packages or just Debian packages, and they are not likely to be affected inconsistencies between available versions of Debian packages and upstream packages. Incidentally. when Debian is not frozen, this is not a major issu since I can make "gratiutous" uploads and no special action is required in order to get the packages propogated to testing. Also, keep in mind that there are other software systems out there that are modular in nature that do not keep all components in lock step. For example, the Horde framework has lots of different components. Sometimes releases are synchronized, but oftentimes they are not. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 19/07/2012 15:31, Tom Eastep wrote:> It has been my practice for some time to always upload all of the > packages when one of them changes. This includes patch releases such as > 4.5.5.3. >This is really an argument about whether to version individual components or the distribution as a whole... I just saw an almost identical question on the Perl blogs rss feed - can''t remember which project it was for, but the question again was whether to mark the whole release of all packages with a version, or to version the individual components. Ahh, yes, just remembered, the sub issue was then how to put the version numbers into the individual modules so that lib-1.2.3 is known to be part of distribution-1.2.5 The majority opinion was that there are some thorny problems with having two part version numbers. I think the same also in your case here, it''s not obvious to a package dependency system that shorewall-core-1.2.3 is acceptable for shorewall6-1.2.5. Gentoo would typically define the dependencies as simple variables that are constructed from the base package name you are installing, and so letting these versions get out of lockstep would be annoying and extra work (and likely lead to bugs) My thought would be that generally people on Debian are quite happy running shorewall 3.x despite shorewall-4.5 being out. Don''t panic too much about their freeze, if users of Debian want to get bang up to date they can come upstream and get their packages... This is a distro management problem, not your problem Cheers Ed W ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 07/19/2012 07:43 PM, Roberto C. Sánchez wrote:> On Fri, Jul 20, 2012 at 08:57:45AM +1000, Paul Gear wrote: >> >> I agree with Jonathan. With my non-packager, mostly-non-developer hat >> on, i think that keeping the versions lock-stepped follows the principle >> of least surprise for Shorewall''s users. It might save hours of effort >> for developers & packagers by not having them lock-stepped, but it will >> save hundreds of hours of confusion and dozens of questions on the >> mailing list if we keep it the way it is. >> > On the flip side, Debian has just entered the freeze period for the next > stable release. So, any new releases introduced into Debian must > reeceive a freeze exception in order to be allowed to propogate. Since > it is the practice of the release managers to not allow gratiutous > changes, I have to choose one of these options: > > 1) (assuming all packages are released each time) I upload only the > packages which actually changed (potentially confuses users since the > Debian packages get out of sync with respect to version numbers > i.e., they are not all in lock step) > > 2) (assuming all packages are released each time) I patch in the > specific changes and upload them as a new Debian revision, which > risks confusing users even more > > 3) (assuming only changed packages are released each time) I keep the > Debian packages in sync and there is no confusion since upstream and > Debian match up > > Personally, I like the last option, since that would be the "least > surprise" to me (and I would think to users). Of course, there are > people out there using just upstream packages or just Debian packages, > and they are not likely to be affected inconsistencies between available > versions of Debian packages and upstream packages. > > Incidentally. when Debian is not frozen, this is not a major issu since > I can make "gratiutous" uploads and no special action is required in > order to get the packages propagated to testing. > > Also, keep in mind that there are other software systems out there that > are modular in nature that do not keep all components in lock step. For > example, the Horde framework has lots of different components. > Sometimes releases are synchronized, but oftentimes they are not. >I think that this boils down to an issue with the Debian freeze period. Were it not for the preference of the Debian release team to only accept uploads that actually correct problems, we would all agree that it is less confusing for users to have a matched set of components. Regarding your second approach above, I notice that Debian (and most other distros) add a "-n" to my version number. So my 4.5.5.3 is released as 4.5.5.3-1. So presumably, users would not be confused if they saw shorewall-core-4.5.5.3-1 and shorewall-4.5.5.3-2? If I were to release individual patches along with the consolidated patch for each product, would that help (I would only need to do that during the freeze period). You could then apply those patches that did not bump the version number and upload the patched product as -2, -3, etc. It would be more work for the two of us during the freeze period but would spare everyone else. An alternative would be for me to change my release numbering system from a.b.c[.d] to a.b.c-d, but I suspect that move would cause disruption to all of the distro maintainers (and some amount of work for me). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Fri, Jul 20, 2012 at 9:21 AM, Tom Eastep <teastep@shorewall.net> wrote:> I think that this boils down to an issue with the Debian freeze period. > Were it not for the preference of the Debian release team to only accept > uploads that actually correct problems, we would all agree that it is > less confusing for users to have a matched set of components.As a consumer of the Debian package, I say stick with what you''re doing and let Debian go stale for a while. It''s their freeze so they should be the ones to suffer the consequences, not you guys. Most people probably know about Debian''s annoying policy and have workarounds in place where needed anyway (like using Roberto''s personal repository). Brad C ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 07/20/2012 01:34 PM, Brad Clarke wrote:> On Fri, Jul 20, 2012 at 9:21 AM, Tom Eastep <teastep@shorewall.net> wrote: >> I think that this boils down to an issue with the Debian freeze period. >> Were it not for the preference of the Debian release team to only accept >> uploads that actually correct problems, we would all agree that it is >> less confusing for users to have a matched set of components. > > As a consumer of the Debian package, I say stick with what you''re > doing and let Debian go stale for a while. It''s their freeze so they > should be the ones to suffer the consequences, not you guys. Most > people probably know about Debian''s annoying policy and have > workarounds in place where needed anyway (like using Roberto''s > personal repository).It''s not that Debian will go stale; it is rather that it has bugs that we would like to correct so that people won''t be running into them for the next two years. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 19 July 2012 22:43, Roberto C. Sánchez <roberto@connexer.com> wrote:> On the flip side, Debian has just entered the freeze period for the next > stable release. So, any new releases introduced into Debian must > reeceive a freeze exception in order to be allowed to propogate. Since > it is the practice of the release managers to not allow gratiutous > changes, I have to choose one of these options: > > 1) (assuming all packages are released each time) I upload only the > packages which actually changed (potentially confuses users since the > Debian packages get out of sync with respect to version numbers > i.e., they are not all in lock step) > > 2) (assuming all packages are released each time) I patch in the > specific changes and upload them as a new Debian revision, which > risks confusing users even more > > 3) (assuming only changed packages are released each time) I keep the > Debian packages in sync and there is no confusion since upstream and > Debian match up > > Personally, I like the last option, since that would be the "least > surprise" to me (and I would think to users). Of course, there are > people out there using just upstream packages or just Debian packages, > and they are not likely to be affected inconsistencies between available > versions of Debian packages and upstream packages. >I don't follow Debian development at all, so I may be entirely misunderstanding what you wrote, but it sounds like you're wanting to change the release version numbering of the shorewall components to subvert the Debian freeze for shorewall, which seems counter to the intentions of a Freeze? Or is it that, the Freeze would require you to backport fixes to the frozen version? The Fedora shorewall packages bundle all tarballs into a single package (and then split them out into sub-packages) - in Debian, are you saying you have a package per tarball? If that's the case, I can see that you wouldn't want to build a new package for a tarball that is unchanged in all but version number. But then, there's nothing requiring you to do so. J ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
On Fri, Jul 20, 2012 at 07:21:02AM -0700, Tom Eastep wrote:> > I think that this boils down to an issue with the Debian freeze period. > Were it not for the preference of the Debian release team to only accept > uploads that actually correct problems, we would all agree that it is > less confusing for users to have a matched set of components. >I agree.> Regarding your second approach above, I notice that Debian (and most > other distros) add a "-n" to my version number. So my 4.5.5.3 is > released as 4.5.5.3-1. So presumably, users would not be confused if > they saw shorewall-core-4.5.5.3-1 and shorewall-4.5.5.3-2? If I were to > release individual patches along with the consolidated patch for each > product, would that help (I would only need to do that during the freeze > period). You could then apply those patches that did not bump the > version number and upload the patched product as -2, -3, etc. It would > be more work for the two of us during the freeze period but would spare > everyone else. >I am not sure this would be worth the extra trouble. I think that this may result in yet more confusion as well when you consider that there would be patches floating around out there with the exact same version numbers as the Debian packages, but with differences (e.g., the absence of the debian/ directory in your upstream tarballs).> An alternative would be for me to change my release numbering system > from a.b.c[.d] to a.b.c-d, but I suspect that move would cause > disruption to all of the distro maintainers (and some amount of work for > me). >I don''t think this would help at all. It would simply result in the Debian packages being versioned as a.b.c-d-n (which while technically being a valid Debian version number, just looks funny to me). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Fri, Jul 20, 2012 at 04:46:04PM -0400, Jonathan Underwood wrote:> > I don''t follow Debian development at all, so I may be entirely > misunderstanding what you wrote, but it sounds like you''re wanting to > change the release version numbering of the shorewall components to > subvert the Debian freeze for shorewall, which seems counter to the > intentions of a Freeze?Not at all. The version number associated with a change has nothing to do (or very little) with whether or not it is accepted into testing during the freeze. It is all about the severity of the bug being addressed and the extent of the change required to address it.> Or is it that, the Freeze would require you to > backport fixes to the frozen version? >This is only an absolute require if I make new uploads to unstable that are not targeted for the frozen release.> The Fedora shorewall packages bundle all tarballs into a single > package (and then split them out into sub-packages) - in Debian, are > you saying you have a package per tarball? If that''s the case, I can > see that you wouldn''t want to build a new package for a tarball that > is unchanged in all but version number. But then, there''s nothing > requiring you to do so. >I have one package per upstream tarball. It is possible to combine all the tarballs into one Debian source package. However, I have thus far chosen not to do this as it would be complicated if Tom decided to go to a release scheme where all the components were not always in sync from a versioning perspective. Additionally, it makes requesting freeze exceptions more challenging since it becomes one package with dozens or hundreds of "gratiutous" changes as opposed do to those changes being spread out over several packages. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 20 July 2012 17:23, Roberto C. Sánchez <roberto@connexer.com> wrote: [snip]> Not at all. The version number associated with a change has nothing to > do (or very little) with whether or not it is accepted into testing > during the freeze. It is all about the severity of the bug being > addressed and the extent of the change required to address it. >OK.>> Or is it that, the Freeze would require you to >> backport fixes to the frozen version? >> > This is only an absolute require if I make new uploads to unstable that > are not targeted for the frozen release. >OK.>> The Fedora shorewall packages bundle all tarballs into a single >> package (and then split them out into sub-packages) - in Debian, are >> you saying you have a package per tarball? If that's the case, I can >> see that you wouldn't want to build a new package for a tarball that >> is unchanged in all but version number. But then, there's nothing >> requiring you to do so. >> > I have one package per upstream tarball. It is possible to combine all > the tarballs into one Debian source package. However, I have thus far > chosen not to do this as it would be complicated if Tom decided to go to > a release scheme where all the components were not always in sync from a > versioning perspective.Yes, this is why I prefer Tom to stick with the current practice :). We could certainly review our packaging process and have a package per tarball, but that (for us) makes updates more laborious, and would involve having the new packages reviewed... not a small amount of work, but not impossible.> Additionally, it makes requesting freeze > exceptions more challenging since it becomes one package with dozens or > hundreds of "gratiutous" changes as opposed do to those changes being > spread out over several packages. >Well, that sounds like shifting the problem more than solving a problem. J. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
On 7/20/12 2:04 PM, Roberto C. Sánchez wrote:> On Fri, Jul 20, 2012 at 07:21:02AM -0700, Tom Eastep wrote: >> An alternative would be for me to change my release numbering system >> from a.b.c[.d] to a.b.c-d, but I suspect that move would cause >> disruption to all of the distro maintainers (and some amount of work for >> me). >> > I don''t think this would help at all. It would simply result in the > Debian packages being versioned as a.b.c-d-n (which while technically > being a valid Debian version number, just looks funny to me).My hope would be that the distributions would package my a.b.c-d as a.b.c-d. What is the point of adding "-n" by my version if ''n'' is always 1. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Fri, Jul 20, 2012 at 08:27:49PM -0700, Tom Eastep wrote:> > My hope would be that the distributions would package my a.b.c-d as > a.b.c-d. What is the point of adding "-n" by my version if ''n'' is always 1. >The only way that would be possible would be if I packaged your releases as "native" (meaning that I do not add the "-n" to indicate a Debian revision). However, that brings with it lots of other issues and I would rather not do that. Additionally, I do not think that a.b.c-d would be valid as a native version number. The way that version numbers are parsed, is that if any hyphen characters are present, then everything after the last hyphen is the Debian revision. If no Debian revision is present, then the package is considered native. So, two or more hyphens are permissible, but the presence of any hyphens prevents the package from being considered native. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 21/07/12 06:37, Tom Eastep wrote:> On 07/20/2012 01:34 PM, Brad Clarke wrote: >> ... >> As a consumer of the Debian package, I say stick with what you''re >> doing and let Debian go stale for a while. It''s their freeze so they >> should be the ones to suffer the consequences, not you guys. Most >> people probably know about Debian''s annoying policy and have >> workarounds in place where needed anyway (like using Roberto''s >> personal repository). > It''s not that Debian will go stale; it is rather that it has bugs that > we would like to correct so that people won''t be running into them for > the next two years.Most of the time, i''m perfectly happy to have a buggy version of Shorewall in Debian. The bugs are usually minor and only encountered under very specific circumstances. I consider that the cost of running a distribution that focuses on low-churn, stable releases, and it''s more than worth it to me. Paul ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Jul 21, 2012 at 05:18:08PM +1000, Paul Gear wrote:> > Most of the time, i''m perfectly happy to have a buggy version of > Shorewall in Debian. The bugs are usually minor and only encountered > under very specific circumstances. I consider that the cost of running > a distribution that focuses on low-churn, stable releases, and it''s more > than worth it to me. >I think that there is a bit of confusion over what is being considered here. Even if Tom changes nothing with respect to his release process, I will still be able to get the necessary important bug fixes into Debian during the freeze period. I will be able to do this by patching in just the relevant bug fixes and incrementing the Debian revision, or by uploading the new upstream releases of just the changed packages. What I had originally asked Tom that spwaned this discussion thread was if it was really necessary to always release all the packages for a point release, whether or not they had all been changed. It seems like there is sufficient controversy surrounding this particular issue so as to not warrant making a change at this time, given that the primary purpose at this point would be to keep the point release version numbers in sync with what is likely to be in Debian during a freeze/stable release. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 07/19/2012 06:05 PM, Jonathan Underwood wrote:> On 19 July 2012 10:31, Tom Eastep <teastep@shorewall.net> wrote: >> Recent questions from the Debian release team about the current practice >> have prompted me to revisit the issue. As I see it, there are three >> possible approaches: >> >> 1) Continue to release all packages. >> >> 2) Continue to release all packages and indicate which of them >> actually changed. That would allow individual packagers to release >> some or all of them. >> > > With my Fedora packager hat on, I''d prefer one of the above. >And me as the opensuse packager prefer the same Togan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 07/20/2012 04:21 PM, Tom Eastep wrote:> > Regarding your second approach above, I notice that Debian (and most > other distros) add a "-n" to my version number. So my 4.5.5.3 is > released as 4.5.5.3-1. So presumably, users would not be confused if > they saw shorewall-core-4.5.5.3-1 and shorewall-4.5.5.3-2? If I were to > release individual patches along with the consolidated patch for each > product, would that help (I would only need to do that during the freeze > period). You could then apply those patches that did not bump the > version number and upload the patched product as -2, -3, etc. It would > be more work for the two of us during the freeze period but would spare > everyone else.-n for opensuse build process means the build number> > An alternative would be for me to change my release numbering system > from a.b.c[.d] to a.b.c-d, but I suspect that move would cause > disruption to all of the distro maintainers (and some amount of work for > me).Please do not do that change as opensuse build service barks to releases with -d (d being anything) in it. I would vote that you keep the numbering as it is Thanks Togan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 23 July 2012 04:31, Togan Muftuoglu <toganm@users.sourceforge.net> wrote:> On 07/20/2012 04:21 PM, Tom Eastep wrote: >> >> Regarding your second approach above, I notice that Debian (and most >> other distros) add a "-n" to my version number. So my 4.5.5.3 is >> released as 4.5.5.3-1. So presumably, users would not be confused if >> they saw shorewall-core-4.5.5.3-1 and shorewall-4.5.5.3-2? If I were to >> release individual patches along with the consolidated patch for each >> product, would that help (I would only need to do that during the freeze >> period). You could then apply those patches that did not bump the >> version number and upload the patched product as -2, -3, etc. It would >> be more work for the two of us during the freeze period but would spare >> everyone else. > > -n for opensuse build process means the build number > >> >> An alternative would be for me to change my release numbering system >> from a.b.c[.d] to a.b.c-d, but I suspect that move would cause >> disruption to all of the distro maintainers (and some amount of work for >> me). > > Please do not do that change as opensuse build service barks to releases > with -d (d being anything) in it. I would vote that you keep the > numbering as it isYes, this is also the case with Fedora (and presumably any other RPM based distros); the "-" is used as the separator for the upstream version and the package release number. Hence the upstream version can''t have a "-" in it. If shorewall were to add one, we''d have to work around that in our packaging by eg replacing the "-" with a "_" or something. Do-able, but a Royal PITA. J ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 7/23/12 11:51 AM, Jonathan Underwood wrote:> On 23 July 2012 04:31, Togan Muftuoglu <toganm@users.sourceforge.net> wrote: >> On 07/20/2012 04:21 PM, Tom Eastep wrote: >>> >>> Regarding your second approach above, I notice that Debian (and most >>> other distros) add a "-n" to my version number. So my 4.5.5.3 is >>> released as 4.5.5.3-1. So presumably, users would not be confused if >>> they saw shorewall-core-4.5.5.3-1 and shorewall-4.5.5.3-2? If I were to >>> release individual patches along with the consolidated patch for each >>> product, would that help (I would only need to do that during the freeze >>> period). You could then apply those patches that did not bump the >>> version number and upload the patched product as -2, -3, etc. It would >>> be more work for the two of us during the freeze period but would spare >>> everyone else. >> >> -n for opensuse build process means the build number >> >>> >>> An alternative would be for me to change my release numbering system >>> from a.b.c[.d] to a.b.c-d, but I suspect that move would cause >>> disruption to all of the distro maintainers (and some amount of work for >>> me). >> >> Please do not do that change as opensuse build service barks to releases >> with -d (d being anything) in it. I would vote that you keep the >> numbering as it is > > Yes, this is also the case with Fedora (and presumably any other RPM > based distros); the "-" is used as the separator for the upstream > version and the package release number. Hence the upstream version > can''t have a "-" in it. If shorewall were to add one, we''d have to > work around that in our packaging by eg replacing the "-" with a "_" > or something. Do-able, but a Royal PITA.Let''s put this thread to bed -- I won''t be changing the release numbering or process. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/