As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase.
During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary.
For this release, I'd like to propose Mental and Bulia as the Change Control Team, and that we rotate who is on this team in future releases.
Because the Inkscape developers are trustworthy, I think we can rely on the honor system, rather than turning off everyone's access. If there happened to be any abuse, it can be handled on a case-by-case basis.
Here's how the process would work:
=== Hard Freeze Phase ===
0. The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker.
1. The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found.
2. Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point.
3. Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase.
=== Release Phase ===
4. The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s).
5. Packagers begin creating the 0.XX.0-1 packages of this release for their platforms.
6. The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release.
7. If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose:
a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case.
8. Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released.
9. Finally, announcements about the release are made. This also marks the end of the Release Freeze.
10. Normal development resumes.
Bryce
On Sun, 2004-07-11 at 10:43 -0700, Bryce Harrington wrote:
As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase.
During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary.
Why not use branches so people can continue committing whilst you have a temporary release branch to which you apply the freeze? That is what branches are for - having different versions of a codebase for varying purposes (in this case continued development vs. frozen code).
On Sun, 11 Jul 2004, Charles Goodwin wrote:
On Sun, 2004-07-11 at 10:43 -0700, Bryce Harrington wrote:
As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase.
During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary.
Why not use branches so people can continue committing whilst you have a temporary release branch to which you apply the freeze? That is what branches are for - having different versions of a codebase for varying purposes (in this case continued development vs. frozen code).
Actually, yes we will be creating a release branch as part of the release cycle, once the Hard Freeze has been completed.
For the question of why make the branch at the end rather than the beginning of the Hard Freeze, recall what happened last time, that caused us to have to do a 0.38.1 release. There was a problem with the release branch because of a bug fix that had *just* been checked in, so we needed a fix that was done in the main branch, but new development had also started in the main branch; luckily there were no major problems, but we had to scramble a bit to get everything together. After that, we decided we needed a more orderly and strict process.
Thus, by keeping the _main_ branch in a hard freeze state for a few days, such issues should settle out quickly. We can just do a final check that all the bug fixes were done right, and that no new bugs slipped in. Hopefully it should not require more than 2-3 days max.
Finally, note that this does not need to prevent people from continuing development, so long as they do it on branches. This way, during the release phase, if we needed to pull in someone's work to fix an issue, we could select just that particular branch to include. If all work was being done directly on the main line, it would be difficult to separate out the necessary fixes from other new stuff, as happened last time.
Bryce
We are now entering the Hard Freeze Phase of our release process.
In theory, bug fixing is now complete. Mental and Bulia will review the application and ensure that recent bug fixes have not broken anything, and that there are no show stoppers.
At this point nobody except Mental and Bulia should be committing to CVS.
When both announce that they consider the codebase Good For Release, we will tag the release branch and initiate packaging activities.
Bryce
=== Hard Freeze Phase ===
The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker.
The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found.
Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point.
Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase.
=== Release Phase ===
The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s).
Packagers begin creating the 0.XX.0-1 packages of this release for their platforms.
The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release.
If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose:
a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case.
Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released.
Finally, announcements about the release are made. This also marks the end of the Release Freeze.
Normal development resumes.
Bryce
On Mon, 2004-07-12 at 23:59, Bryce Harrington wrote:
We are now entering the Hard Freeze Phase of our release process.
pre4 is tagged and uploaded to Sourceforge. It is key that everyone take a look at this, it is very close to the final release. Let's make sure that everything is beautiful!
--Ted
We need a few more packages such as a Windows package before we can announce, but I'm hopeful that within the next day this will be done.
I've begun writing a release announcement here, based on our Release Notes:
http://inkscape.org/cgi-bin/wiki.pl?ReleaseAnnounce039
Please feel free to work on improving it, although remember we need to avoid letting it get *too* long.
Bryce
On Sun, 11 Jul 2004, Bryce Harrington wrote:
=== Hard Freeze Phase ===
The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker.
The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found.
Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point.
Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase.
=== Release Phase ===
The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s).
Packagers begin creating the 0.XX.0-1 packages of this release for their platforms.
The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release.
If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose:
a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case.
Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released.
Finally, announcements about the release are made. This also marks the end of the Release Freeze.
Normal development resumes.
participants (3)
-
Bryce Harrington -
Charles Goodwin -
Ted Gould