Subject: Re: [RELEASE] 0.9.3 schedule ?
From: Paul Rohr (paul@abisource.com)
Date: Sun Aug 26 2001 - 18:54:47 CDT
At 11:43 PM 8/25/01 +1000, Martin Sevior wrote:
>The real issue is that once these binaries are made, it takes a long time
>to get feedback on the builds. Can we have also have volenteers to
>*quickly* test the Win32 and RH 7.1 binaries?
>
>Without this help the process becomes really frustrating for everyone.
>
>Then there are two sorts of bugs that can occur.
>
>1. Real source code bugs like 0.9.2 has.
>2. Packaging bugs.
>
>I suggest we make a preminary source code release followed by some quick
>builds and volenteers to test these.
>
>If these go OK with our volenteer testers on WIN AND Linux the preliminary
>release becomes THE release.
>
>However if we don't get volenteers to make a Win build and test them
>everything gets bogged down.
>
>The corollary is that if we don't have volenteers we should realize our
>limitations decrease the scope of our ambitions accordingly.
>
>If we can't find developers to test builds, maybe we could ask the users
>list?
>
>If we can't find volenteers to test the builds everyone will just have to
>live with either brown paper bag releases or a slower development
>rate.
Martin,
I think we're in violent agreement here on all points, so let me summarize
to confirm. For the sake of clarity, I'll use the vocabulary from my
original post:
http://www.abisource.com/mailinglists/abiword-dev/01/August/0401.html
Can we agree to do a lightweight release process as follows:
1. The release manager calls for a release, identifying the following:
- why ... which functionality to emphasize in the announcement,
- when ... it's scheduled to happen,
- what ... packages we plan to include (the "go / no go" set),
- who ... named maintainer/packager/tester(s) for each, and
- where ... we need to announce it.
If too many of these questions are still up in the air, we'll have trouble
pulling off a clean release that Just Works.
2. Maintainers use the remaining time to get their packages in shape for
that release. If people can be testing daily builds or CVS builds during
this period, that will make steps 4 and 5 (below) go more quickly.
3. At the appropriate time (when and why are in good shape), we apply a
freeze tag and create the relevant source packages.
4. As soon as this happens, packagers generate the relevant binary packages
(from the source packages), which confirms that the sources are buildable.
They then make them available (along with MD5s) for upload. The current
proposal is that the minimum set of binary packages for a release would be
the Win32 installer and Martin's two RPMs.
5. Then, of course, the big trick is just to make sure that we get
reasonably quick turnaround from the testers for each package. My belief is
that, so long as each tester knows far enough in advance to make their time
available, that shouldn't be too hard.
6. As soon as they say "go", we upload all the confirmed source and binary
packages to SourceForge, in preparation for the official release
announcement.
7. Finally, the evangelists (who I still need recruit) kick into action.
bottom line
-----------
I can see three main differences between this process and what we used to do
in the Sam era, namely:
- When starting the release cycle, we clearly identify who's doing what.
- We work a lot harder to do more of the pre-release work up front.
- We divide the work up among more people.
As Martin points out, the biggest obstacle here is making sure that we know
who's going to do the packaging and testing for a given release, so that
we're not waiting forever for someone to volunteer to get that work done.
Does that sound about right?
Paul
This archive was generated by hypermail 2b25 : Sun Aug 26 2001 - 18:47:18 CDT