harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] Harmony M2 schedule
Date Tue, 05 Jun 2007 05:06:48 GMT
On the 0x2EC day of Apache Harmony Mikhail Loenko wrote:
> Let's have end of month (June, 30?) as a release date. Now we need to
> define a date for code freeze (when only critical bugs are fixed) and
> define how we will commit between code freeze and release (each commit
> approved by one more committer?)

one should be enough. I think, the common process should be well
applicable here: we will have comitter responsibility, discussions
over dev@, etc. No reason for tight commit process, IMHO. 

Tightening commit criteria requirements (that you are proposing) is good.

> I think the code freeze date should depend on the longest test cycle
> we have (I've seen somewhere about 48-hour scenarios?) and be ~2-3
> cycles (1 week?) prior the release.
>
> We also need a feature freeze date (1-2 weeks prior code freeze?) when
> no major changes or redesigns are allowed.

reasonable, thanks

2 weeks for feature freeze before M2 should be OK, IMHO

> And we need to set up requirements for the release. We already see a
> good wish-list here. The only concern I have is that its focus is
> almost everything: stability, performance, and completeness. Though I
> completely agree with each of these directions, I have a feeling that
> having everything in focus means not having a focus.
> 
> So I propose that we go this way: we have directions, we already
> discussed them many times. Now let's create requirements based on the
> list of directions: *each person who adds something to requirements is
> committing to and will be responsible for meeting that requirement*
> 
> The requirements could be to have something specific in stability,
> have something specific in performance, completeness, java6, etc
> 
> Once we compose a list, say 1..N of requirements, we create keys or
> tags for JIRA, say M2-REQ1, ..., M2-REQN and mark bugs affecting
> requirements with these key words. So each person would easily find
> bugs affecting requirements he is responsible for.

1. why numbering? let it be descriptive requirement names. Example:
M2-req-stable-linux-x86_64-regression-tests

2. why req tags for JIRA? Does this help committers to follow their
areas of responsibility? If so, they could, please, please, speak
up. I thought, all guys follow their bugs, have reasonable priorities
regarding them, etc, etc.

I do not mind such a small "commit process enhancement", but there is
nothing but an extra burden in it for me)

> Comments? Requirement proposals?

-- 
Egor Pasko


Mime
View raw message