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

[Arnaud Quette]

2006/10/2, Peter Selinger <selinger at mathstat.dal.ca>:
> Arnaud Quette wrote:
> >
> > 2006/9/29, Peter Selinger <selinger at 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/