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

[Arnaud Quette]

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

for sure. I'd be happy to see nut automake'd, but remember it also
need to be libtool'ized (for libupsclient first, and the upcoming
libupsconfig next).

> 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".

I guess you mean "making more frequent testing releases"?
that's doable, though I'm not sure we'll have more feedback since it's
linked to the precompiled releases, and these are only done against
stable releases atm. So that would either mean we'll generate our
packages set, or release more frequently stable source. I'm for the
2nd, though we must not release too much (4 stables / year of the same
branch, ie 2.0) since packagers can't update all the time (trust me
;-) and we're providing a tool for HA.

> 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?

has been, is being. It depends on the system we're talking about. But,
yeh, that's the aim of the NUT Packaging Standard, and packagers
recruitment.

> > 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 guess ;-)

> 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

for sure. Another point I never had time to investigate...
thanks for your work on this ;-)

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/