[haiku-development] Re: Wrapping up R1 alpha 2
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 18 Apr 2010 12:32:36 +0200
On 2010-04-17 at 14:04:45 [+0200], Simon Taylor <simontaylor1@xxxxxxxxxxxx>
wrote:
> What kernel_debug setting is going to be used? I assume 2 to enable
> better bug reports?
Yep, I think at least for the alphas we should stick to level 2.
> I tried a build with it set to 0 and Haiku did feel
> noticeably quicker though, but it could have been my imagination.
The kernel is measurably faster with debugging disabled. Locking is cheaper
(mostly inlined) and a lot of checks are left out. The -j8 Haiku image build
was about 20% faster last time I measured it on my machine. The block cache
has heavy-weight checks at debug level 2. Block cache intensive file system
implementations (reiserfs) benefit significantly from a level < 2.
Though for normal desktop use a different kernel debug level shouldn't really
be noticeable, I guess.
On 2010-04-17 at 15:11:36 [+0200], Niels Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
> On 17 April 2010 11:36, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > using the momentum of the rather productive BeGeistert coding sprint, I
> > guess now is the perfect time to initiate the final launch sequence for
> > the
> > alpha 2 release. Haiku, Inc. accepted my contract proposal for focussed
> > work on the alpha 2 release [1], I'm offering to take over the not
> > particularly popular task of the (technical) release coordination (*) at
> > least until my contract ends (expected in early May), but, if my spare
> > time
> > permits, hopefully until the release. I would like to start a vote on
> > appointing me the release coordinator on Monday and, to not waste time,
> > also start acting preliminarily in that position at the same time. Unless
> > concerns are raised that is.
>
> Why not start the vote right now?
I wanted to give people a bit of time to voice objections or volunteer as
release coordinator themselves. I'm not that eager to do the job to stand in
the way of someone who really wants to do it. :-)
> I offer my time as a wing man to
> take care of the non-dev stuff in case you'd like the help.
Great, thanks!
> > Regarding the organization of the release I propose the following:
> >
> > * The 10th of May (Monday) is the official release date. To allow for some
> > time to spread the final image to the download mirrors the final version
> > should be tagged and built a day before.
>
> I would suggest doing the tagging a bit earlier; I would like to see
> the final images getting some testing. What about tagging at May 6?
If the testing turns up serious errors that need to be addressed, we'd have
to tag again later. If it doesn't, we'd have lost several days that would
have allowed us to fix more smaller issues. I think we should simply build
nightlies from the release branch (and maybe turn off the trunk nightlies
until the release) so they are available for public testing the whole time. I
believe that's what we did for the alpha 1 release at least. I wasn't
involved in the process at that time, but my impression was that it worked
well.
> > * The release branch should be created on Monday.
> >
> > * All developers continue to make their changes in the trunk. Only the
> > release coordinator will commit changes to the branch.
>
> What are the criteria? Fix-only?
I would also allow small features and polishing at the beginning and get
stricter closer to tag day (maybe fix-only mode in the last weak).
> > * The release coordinator will monitor the ongoing trunk activity and list
> > all change sets on a Wiki page. All release-relevant change sets will need
> > to pass a review (by any other developer or by the release coordinator)
> > before being merged into the release branch. (**) The idea behind the
> > review process is to ensure a high quality of the changes that end up in
> > the release branch.
>
> I guess this does not differ from the previous workflow, but why not
> have devs put 'Alpha2' in their commit message. The manual work of
> maintaining a wiki page is replaced with the magic of a query.
I'd like to have a table with a revision column and several manually editable
columns (reviewer, comment, merged flag). If that can be done with a query,
then I'm all for it. I'd prefer an opt-out commit message tag ("-alpha2"), so
forgetting it wouldn't do any harm.
> > * A discussion/vote must be held what optional features to include. This
> > should be finished during the next week.
>
> I guess we are talking about optional packages, right? Because I doubt
> a month will be long enough to make feature changes, right?
Yeah, sorry, I meant optional packages.
> > (**) While there's always the release coordinator to review patches of
> > other developers, someone else would have to review his patches. We'll
> > have
> > to see how that works out.
>
> I'd say: release coordinator's privilege. Though last time I thought
> axeld and stippi both maintained the alpha1 branch, so if you get help
> this theoretical problem is solved.
I believe the access to the release branch was a bit unstructured last time.
At least three people were committing to it. I'd like to keep things simple
by having only one person who commits to the branch. Help with the reviews
would be much appreciated, though.
On 2010-04-17 at 15:39:43 [+0200], Jorge G. Mare <koki@xxxxxxxxxxxxx> wrote:
> As noted on...
>
> http://dev.haiku-os.org/wiki/R1/Alpha2/StatusAndCoordination
>
> ...I volunteer to:
>
> * Write the website announcement/press release
> * Update website front page & atwork
Excellent, thanks!
> With regards to the "Determine press plan" item on the same page, I have
> a couple of ideas:
>
> 1) Wrap up the announcement one week before release and have the various
> international communities translate it into their languages in time for
> release day. This would require coordination with trusted members of
> each community, but I think it is doable.
>
> 2) Push the new to the new wire: not that it will guarantee any exposure
> in mainstream media, but it may be a good exercise to start getting the
> name out for whenever R1 is release. I can do this if you want.
Sure, sounds good!
On 2010-04-17 at 16:50:09 [+0200], Matt Madia <mattmadia@xxxxxxxxx> wrote:
> Is it safe to assume serial debugging will also be disabled in R1 Alpha 2?
I'm all for disabling it for alpha 2 as well. I would keep the "debug syslog"
option enabled, though. That allows to access the same information, if
necessary.
On 2010-04-17 at 16:55:45 [+0200], Niels Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
> On 17 April 2010 16:50, Matt Madia <mattmadia@xxxxxxxxx> wrote:
> > On Sat, Apr 17, 2010 at 13:11, Niels Reedijk <niels.reedijk@xxxxxxxxx>
> > wrote:
> >> I guess this does not differ from the previous workflow, but why not
> >> have devs put 'Alpha2' in their commit message. The manual work of
> >> maintaining a wiki page is replaced with the magic of a query.
> >
> > if it matters, "+alphabranch" was used to denote a changeset to be
> > merged and "-alphabranch" for one to not be merged.
>
> We can even enforce the developers using that keyword using svn hooks.
> If a log message does not contain those keywords it will fail.
Hoping that people will get into release mode, I'd rather only have an
opt-out tag.
CU, Ingo
Other related posts:
