[haiku-development] R1/A3 -- Third Time's the Charm(?)
- From: Matt Madia <mattmadia@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 23 Jan 2011 10:57:54 -0500
Hi all,
Since entering the Beta stage is not in the near future and a possible
Google Summer of Code 2011 is approaching, could we release another
alpha?
The last R1/A3 thread was back in Nov. [1]
Summing up that thread, here are the components that may raise concern today:
* Locale Kit / ReadOnlyBootPrompt
* print_server crashing on shutdown (status?)
* CD read errors while installing (was mentioned on [haiku]) [2]
Adrien [3]:
---
ReadOnlyBootPrompt has trouble with line breaking chinese text, but
works fine otherwise. This can only be solved properly by using ICU
layouting engine for linebreaking the text. I hope I'll have some time
to do it, but I can't be sure.
---
The visual appearance of ReadOnlyBootPrompt may need to be addressed too
* http://dev.haiku-os.org/ticket/5786
* //www.freelists.org/post/haiku-commits/r39342-haikutrunkdataartwork,5
Other than these, are there any new issues that would absolutely delay
a release?
As noted in the first thread [1], here's the bare minimum for doing a release
* Adjusting versioning to R1 alpha 3 (r36348)
* updating gcc to r1a3-version (r36378)
* disable serial debug output (r36721)
* enable HAIKU_OFFICAL_RELEASE (r36768)
* user guide (r36743, r36744)
* rebuilding pre-built packages used in the build system
Here's also some snippets from Ingo, which are worth repeating: [4]
---
IMO filtering what goes to the release branch through a single person is a
good idea, as that allows to implement a simple policy and prevents
misunderstandings. AFAIK that's also how other bigger projects handle
releases.
* The reviews took a lot of time. So either we drop the review idea
completely or at least we don't require reviews anymore. A patch could
have, say, three days for a review to be made and, if none happened, the
decision whether to commit it to the branch or not would be made anyway.
This way unreviewed patches wouldn't be pending for a long time and the
pressure on the release branch manager to do most of the reviews would
lessen.
* There should be a longer branch life time with a stricter merge policy.
Like two weeks with only small changes and two more weeks with only very
small cosmetic changes or changes that fix serious issues. This would give
the almost final version a lot more time for being tested without risking
significant regressions at the same time.
---
1:
//www.freelists.org/post/haiku-development/R1A3-a-thought-about-the-release-cycle
2a: http://dev.haiku-os.org/ticket/6723
2b: //www.freelists.org/post/haiku/Problem-with-cprivmsgtxt
2c: //www.freelists.org/post/haiku/Problem-with-cprivmsgtxt,31
2d: //www.freelists.org/post/haiku/Problem-with-cprivmsgtxt,35
2e: //www.freelists.org/post/haiku/Problem-with-cprivmsgtxt,42
2f: //www.freelists.org/post/haiku/Problem-with-cprivmsgtxt,46
3:
//www.freelists.org/post/haiku-development/R1A3-a-thought-about-the-release-cycle,3
4:
//www.freelists.org/post/haiku-development/R1A3-a-thought-about-the-release-cycle,8
Other related posts:
