savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers] submission of Release Early, Release Often - savannah


From: mike
Subject: [Savannah-hackers] submission of Release Early, Release Often - savannah.gnu.org
Date: Mon, 25 Nov 2002 10:30:06 -0500
User-agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913 Debian/1.2.6-2

A package was submitted to savannah.gnu.org
This mail was sent to address@hidden, address@hidden


Michael L. Brownlow <address@hidden> described the package as follows:
License: gpl
Other License: 
Package: Release Early, Release Often
System name: rero
Type: GNU

Description:
RERO is a release manager. It can be used to perform static or
automatic releases of software. Its primary focus is support for the
GNU Autotools and CVS; however, support for custom build environments
exists. In addition to making a release, RERO can also send
notifications by email of the release and log statistical information
about the release process. A supplemental script that comes with RERO can parse 
the log to create gnuplot charts of information useful for
release analysis. Here is an extract from the Texinfo documentation
that describes, perhaps more formally, RERO\'s purpose:

   RERO is an acronym that stands for \"Release Early, Release 
   Often.\" This phrase was first used by Eric S. Raymond in his
   work \"The Cathedral and the Bazaar,\" a significant piece of
   literature being written during the free software revolution.
   In his work, the phrase is used to describe the benefits of Linus
   Torvalds\' open development process for the Linux operating system.
   RERO was written as a means of accomplishing the same, or similar,
   aspects of this innovation in a way that is consistent with
   current development patterns while also acting as a general
   release manager.

   Automation is another critical aspect that RERO attempts to
   implement. If it is possible to characterize when a release should
   be made, then RERO should be able to make a release at that point
   in time without developer intervention. Knowing whether software
   is stable is a different problem that RERO does not address. It
   only addresses whether a release can be made. This is important
   to consider if one desires to use RERO as a metric for software
   improvement.

   It is quite possible that many do not see the advantages RERO has
   to offer over current solutions. For example, when using the GNU
   Autotools, it is very easy to create and distribute a release.
   Indeed, just using basic aspects of Unix in general allow for
   release automation to be accomplished after some effort. What RERO
   tries to do is provide a basis for those models for consistency
   across projects with the perspectives of automation and process
   improvement in mind. Is it really necessary for minor releases to
   be done by hand? Is it possible to make a release of software
   based on how stable it appears to be?  These issues, along with
   providing a tool for formally addressing release management, are
   the goals of RERO.

The website is currently at:
   http://rero.wsmake.org/

It already exists and you can download the latest distribution at 
http://ftp.wsmake.org/pub/rero/rero-0.0.53.tar.gz


Other Software Required:
Runtime:
  Perl
  gnuplot (for charts)

Maintainers:
  Autotools
  Texinfo


Other Comments:
Contact: Michael L. Brownlow <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]