[Gnue-dev] Re: Release Process

[Stanley A. Klein]

This is a response to Jason's reasonable rant.  No apologies needed for it.  

We need to work out ways that make it easier to participate in pre-release
testing.  

I finally got my database connection problem fixed (Jason was cc:'ed on the
play by play messages; I am summarizing the results in a separate message
for this list).  But even if I didn't have the connection problem and had
wanted to participate in the pre-release testing, it would have been
difficult for me.  I think I've fixed part of the problem, but other parts
need some work.

What Jason has called my "mutant install" (for tar.gz files) seems to work
and makes it relatively easy to create a GNUe installation in my user
directory that doesn't have consequences for my system configuration.  I
think it is a good way to install pre-release versions for testing.  It is
easy to delete the installation when the testing is finished.

I also think that if there are CVS branches for the pre-release versions
(or actually for anything else) there needs to be documentation on the web
page on how to access them.  I only know how to get to the main CVS.

We probably need (if we don't already have them) pre-planned test cases,
and a plan for going through them.  We need to include a plan for
regression testing, and that needs to be provided to potential testers.

Something else that might help is a package distriuted with the pre-release
versions that contains files and tools that might help in testing.  One
thing it could contain is setup-cvs.py.  I used it for my "mutant"
quasi-cvs install.  I copied it from CVS, but someone who doesn't have a
CVS copy might find its inclusion in a test support package useful.

I can't comment on other parts of Jason's rant, such as the intensity of
management, frequency of releases, role of core team versus other community
members, and similar items.  As the saying goes, they are "above my pay
grade."  :-)  

Except that I will say that GNUe has developed to the point where a python
newbie (which I am) finds many parts of it difficult to follow.  I will
help where I can, especially in the area of advocacy, but there are some
areas that will necessarily rest on the shoulders of the key developers,
because they are the ones who understand the guts of the code.

And may they keep up the great work.


Stan Klein


At 06:38 AM 10/20/2002 -0400, Jason Cater <address@hidden> wrote:

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