Arnaud Quette
2006-Oct-03 10:22 UTC
[Nut-upsdev] NUT release process (was: Stack corruption in newhidups.c)
2006/10/2, Peter Selinger <selinger@mathstat.dal.ca>:> Arnaud Quette wrote: > > > > 2006/9/29, Peter Selinger <selinger@mathstat.dal.ca>: > > > > > I don't really understand the purpose of the "Testing" branch. It has > > > not been touched since July, as far as I can see. I also don't > > > understand NUT's release cycle. > > > > > > Shouldn't we be making releases much more frequently? I.e., throw away > > > the current "Testing" branch and create a new one from the current > > > trunk? Is anybody actually testing the "Testing" branch? Release 2.0.4 > > > is now so outdated that we tell most users on nut-users to ignore it > > > and download SVN sources. > > > > > > Our trunk is reasonably stable; I think we should just pick a random > > > date, then copy the trunk to a branch called "2.0.5", wait for bug > > > reports for a few weeks, then release it, then repeat. I know that > > > there are many ambitious changes in progress that will make it into a > > > future 2.2 release, but perhaps that is a bit too far in the future? > > > > in fact, this results from legacy things that have not been reworked. > > > > The NUT release process separate the development and stable things. > > > > The idea is to have only bugfixes on Stable. > > Testing is only there for pre Stable release. > > Though I've had in mind to produce Stable from the trunk, that can't > > apply everytime, since we don't want to lower reliability when we add > > new features. That would also create new constraints for developers. > > But I think we'll move to such things soon, possibly after 2.2 or 2.4. > > Yes, it makes sense to derive stable releases from a testing branch, > and not directly from the trunk. But perhaps this should happen more > frequently. Currently we have three levels of code: "trunk", > "testing", and "stable". > > I envision a standard release cycle would be this: a testing branch is > created, at some arbitrary time T, by making a copy of the trunk. It > should be immediately released as a "testing" release. Between time T > and T+D, only bugfixes should be copied between the trunk and the > testing branch (in both directions), and the testing release should be > updated often. At time T+D, when there are effectively no more bugs to > fix, this testing release should be declared "stable". At this time, > the branch is abandoned (except for continuing post-release bugfixes > when necessary), and a new "testing" branch should be spawned off from > the trunk. The parameter D should be something relatively short, like > a month or two. > > Here is a picture, where "#" denotes a feature added, and "x" denotes > a bug fixed. > > trunk > | testing > +-----+- release 2.0.5-pre1 > x x > # |- release 2.0.5-pre2 > | | > | | > x x > # |- release 2.0.5-pre3 > | | > # | > x | > # | stable > | +------------------------------------------+- release 2.0.5 (stable) > # | > | testing | > +-----+- release 2.0.6-pre1 | > x x x > | | |- release 2.0.5-2 (bugfix) > | | | > | | ... > x x > # |- release 2.0.6-pre2 > | | > | | > # | > x | > # | stable > | +------------------------------------------+- release 2.0.6 (stable) > # | > | testing | > +-----+- release 2.0.7-pre1 | > x x | > | | | > | | | > | | ... > x x > ... ... > > I think this is what we are supposed to have, but the problem is that > our Testing branch is very old, and is not being tested, so probably > will never lead to a stable release? Perhaps we should abandon it and > create a new Testing branch from the current trunk?I've thought a bit about it last night, and I think we'll go that way. 2.0.5 will so be spawned from the current trunk, before I engage the big merges of the new conf and HAL... That will solve many points that would be hard to backport otherwise.> Perhaps what is keeping us from releasing more frequently is a lack of > automation? If we used "automake", making a source code release would > be as simple as updating a version number, followed by "make dist" and > "make distcheck". (And some standardized check to see if the > documentation files are up-to-date).I don't think the build process is stopping us here. But more the release process itself, that is to say the time to check if all known problems have been fixed, the tarball building and testing, the webpage update, the alioth management, ... A best solution would be to have a release manager role, such as in debian, who's job is to focus on the above, since I'm currently the weak link (and things won't get better since I'll have a 2nd baby by 2 months, and a house to build...)> > Lastly, I'm really about to finish my internal big projects, so I'll > > be back really soon... > > Great! -- Peter >For those interested in, these big projects are for the new MGE Network Shutdown Module (with a multiplatform graphical installer and systray), available as a beta: http://www.mgeups.com/email/forms/nsmv3.htm Arnaud -- Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ OpenSource Developer - http://arnaud.quette.free.fr/
Peter Selinger
2006-Oct-03 14:21 UTC
[Nut-upsdev] Re: NUT release process (was: Stack corruption in newhidups.c)
Arnaud Quette wrote:> > 2006/10/2, Peter Selinger <selinger@mathstat.dal.ca>: > > > > I envision a standard release cycle would be this: a testing branch is > > created, at some arbitrary time T, by making a copy of the trunk. It > > should be immediately released as a "testing" release. Between time T > > and T+D, only bugfixes should be copied between the trunk and the > > testing branch (in both directions), and the testing release should be > > updated often. At time T+D, when there are effectively no more bugs to > > fix, this testing release should be declared "stable". At this time, > > the branch is abandoned (except for continuing post-release bugfixes > > when necessary), and a new "testing" branch should be spawned off from > > the trunk. The parameter D should be something relatively short, like > > a month or two. > > > > Here is a picture, where "#" denotes a feature added, and "x" denotes > > a bug fixed. > > > > trunk > > | testing > > +-----+- release 2.0.5-pre1 > > x x > > # |- release 2.0.5-pre2 > > | | > > | | > > x x > > # |- release 2.0.5-pre3 > > | | > > # | > > x | > > # | stable > > | +------------------------------------------+- release 2.0.5 (stable) > > # | > > | testing | > > +-----+- release 2.0.6-pre1 | > > x x x > > | | |- release 2.0.5-2 (bugfix) > > | | | > > | | ... > > x x > > # |- release 2.0.6-pre2 > > | | > > | | > > # | > > x | > > # | stable > > | +------------------------------------------+- release 2.0.6 (stable) > > # | > > | testing | > > +-----+- release 2.0.7-pre1 | > > x x | > > | | | > > | | | > > | | ... > > x x > > ... ... > > > > I think this is what we are supposed to have, but the problem is that > > our Testing branch is very old, and is not being tested, so probably > > will never lead to a stable release? Perhaps we should abandon it and > > create a new Testing branch from the current trunk? > > I've thought a bit about it last night, and I think we'll go that way. > > 2.0.5 will so be spawned from the current trunk, before I engage the > big merges of the new conf and HAL... > That will solve many points that would be hard to backport otherwise. > > > Perhaps what is keeping us from releasing more frequently is a lack of > > automation? If we used "automake", making a source code release would > > be as simple as updating a version number, followed by "make dist" and > > "make distcheck". (And some standardized check to see if the > > documentation files are up-to-date). > > I don't think the build process is stopping us here. > But more the release process itself, that is to say the time to check > if all known problems have been fixed, the tarball building and > testing, the webpage update, the alioth management, ...Tarball building and testing is what "make distcheck" does. It is really quite useful. It builds the tarball, then simulates a configure/compile/install directly *from* the generated tarball, thereby catching any files that were inadvertently left out of the distribution. This even checks features like bulding with separate source/build directories, to ensure that all the Makefiles have been written correctly. It also runs any automated tests, if some have been defined. It even tests if "make dist" works from within the generated tarball, to make sure some files are not missing that might be needed to generate a distribution. I found with my other projects that this saves quite a lot of time. Also, by making frequent testing releases, we are more likely to catch situations where a known problem has not been fixed, or the documentation is not up-to-date, because someone will likely catch it before the release becomes "stable". One time consuming aspect of making releases is to generate the precompiled releases and packages for the various platforms (and it's important to do so, since this often catches problems that weren't apparent on the reference platform). But I guess we have a mailing list to alert package maintainers of a new release, so that this process has been delegated?> A best solution would be to have a release manager role, such as in > debian, who's job is to focus on the above, since I'm currently the > weak link (and things won't get better since I'll have a 2nd baby by 2 > months, and a house to build...)Congratulations! Yes, I guess you'll be even busier... I'll do some experiments with NUT and automake. Converting it is not 100% trivial, because of the special Makefile mojo needed for usb drivers and other assorted special cases. But once done, it could be extremely portable. -- Peter> > > Lastly, I'm really about to finish my internal big projects, so I'll > > > be back really soon... > > > > Great! -- Peter > > > > For those interested in, these big projects are for the new MGE > Network Shutdown Module (with a multiplatform graphical installer and > systray), available as a beta: > http://www.mgeups.com/email/forms/nsmv3.htm > > Arnaud > -- > Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt > Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ > Debian Developer - http://people.debian.org/~aquette/ > OpenSource Developer - http://arnaud.quette.free.fr/ >