[Gnue-dev] Release Process [Was Re: Kudos - keep up the hard work!]

[Jason Cater]

I moved this to gnue-dev. 

I mostly agree with Jan.  However, this highlights a few issues in this
project. 

[ I apologize in advance if this turns into a rant. ]

I was a little frustrated when packaging the last release -- I could not
get much feedback at all from others.  I was asked to speed up a release
and get it out the door, so I spent a few weeks trying to get a release
ready. One week alone was spent trying to create Windows .EXE's, which in
the end didn't work for everyone, but did work for others -- myself
included. (Thanks, btami, for fixing my Win32 packaging problems!!!)

Btami, Jan, and a handful of others were the primary people to get
involved with bug-fixing the release. And I do thank them. It wouldn't
have been what it was without their help. 

Now, I have to ask, why!?!?  We have a growing community and we were on a
prerelease cycle for a good while. Prereleases take time to package and
are done for one purpose only: TO GET OTHERS TO TEST! Start testing your
forms from prerelease 1, and with each additional prerelease. Don't wait
until I give up and release the final packages before reporting bugs with
your applications. I test against my in-house applications and get those
bugs out, but I can't test against others. It's up to you! 

Don't come crying that your form doesn't work with the latest release
unless you gave us feedback during prereleases. And we usually announce
our intentions to start the release cycle a few weeks prior to even doing
prerelease 1. There is a several week period from the time we start
talking about releases to the time we actually finalize it -- this last
time, that was about 4 weeks for internal people, and 2-3 weeks for
external people. Oddly enough, the complaints about non-working forms are
from INTERNAL people. Come on, guys. 

The releases are FOR the community, not for the primary developers.  If I
were the only one using the packages, I would NEVER release -- When CVS
has a feature I need and it works well for me, I install that version. 

We can yell "ROADMAP" all we want to, but that's not the underlying
problem. We have too many chiefs and not enough indians in this project.
That's the problem.  I have never seen a project so over-managed. I mean,
when so much time is spent arguing over documentation formats, over
roadmaps, and over what doodahXML standard we should be conforming to, how
can anything get done. 

But back to Jan's comments. I agree we need a set of test forms.  I've
actually asked for contributions before. I would REALLY, REALLY like to
see this happen -- unfortunately, I don't have the time to begin the
process. So, this is an open call for a GNUe smoketest. 

But as far as the web interface for tested platforms, we'd actually have
to get people to test before that would be of any use!!!  I'm all for the
concept, but if tradition continues, it's one more thing that will end up
on the shoulders of the primary developers to carry out come release time.

I do understand that as we come closer to 1.0, this will become less of an
issue. We are still only 0.x.0 software and are still defining exactly
what we are. Eventually, we will move from "new feature" mode, to "bug
fix/minor improvement" mode. Hopefully that will be sooner than later. 

The more complicated the release process becomes, the less frequently we
will be able to release -- UNLESS we have release coordinators separate
from the main developers. As much as I like this, I don't really see this
happening. At any given time, despite the breadth of this project and size
of its community, you only have a handful of people actively coding. 

Now, of course, anyone who knows me in IRC can attest, I don't like
frequent releases.  I didn't particularly want the last release. But the
overwhelming attitude I've seen from others is "release early, release
often." Well, folks, let's pick one. Early and often? or infrequent,
feature-complete, and rock-solid?

Ok, I feel better now. 

-- Jason

On Sat, 19 Oct 2002 16:20:33 +0200
Jan Ischebeck <address@hidden> wrote:

> On 17 Oct 2002 08:22:48 Derek Neighbors <address@hidden> wrote:
> > This and some other release type issues makes me wonder about road
> > maps.  Should we fix a few things and do a 0.4.1 release of things or
> > a 0.5.0 and then begin roadmapping for the future? =20
> > 
> > Jason/Jan???
> 
> IMO the main problem with this release seems to be that there were many 
> changes and too little testing of the prereleases. 
> 
> Although roadmapping could solve some release type issues, because you
> can plan things more concrete, it is not the most important part needed
> to get a release, which is working in 90% percent of all cases.
> 
> More important is to document which parts of the gnue prereleases are
> tested on which platforms. (f.e. appserver was not tested in combination
> with python2.2, etc.)
> 
> To reach this goal,  we need to define
> 
> 1. a list of platforms/configurations to test:
> "Debian Woody (deb install,python2.1),Debian Sid
> (setup-cvs.py,python2.2), Windows (setup.exe,python2.2)" should be the
> minimum
> 
> 2. a list of tests to run: 
> I thought of something like http://www.mozilla.org/quality/smoketests/.
> there are already some test cases in the samples/testcases directory.
> testing should be made as easy as possible, f.e. file
> samples/testcases/testrun.gpd can be used to start all forms in the
> subdirectories of samples/testcases.
> 
> 
> 3. a way to document which testcases were tested on which configurations
>    and if they worked or not.
> 
> The status of testing efforts could be shown on a web page. like:
> http://www.openoffice.org/dev_docs/source/643/release_notes.html#qa 
> 
> for now a simple php script which creates a web page out of database
> records and a gfd file to populate the database would be sufficient.
> 
> A web form to add/change entries would be the next step. Later this
> functionality could be implemented in DCL.
> 
> 
> 
> Although having a fixed testing environment will be another thing to be
> maintained (and to be created), but it will help to increase the QA of
> gnue, and there will be one point in the nearer future, when it will
> become mandatory.
> 
> 
> Jan
> 
> 
> ---------------------
> Jan Ischebeck e-Services
> address@hidden
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gnue mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue