[Nut-upsdev] Re: NUT release process (was: Stack corruption in newhidups.c)

[Peter Selinger]

Arnaud Quette wrote:
> 
> 2006/10/2, Peter Selinger <selinger at 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/
>