[Nut-upsdev] Stack corruption in newhidups.c

[Peter Selinger]

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? 

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). 
 
> Lastly, I'm really about to finish my internal big projects, so I'll
> be back really soon...

Great! -- Peter