harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [general] Harmony M2 schedule
Date Tue, 05 Jun 2007 07:36:05 GMT
I also think that two months period is well balanced. As well as two
weeks for feature freeze.  So I am +1.

Egor Pasko wrote:
> > 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.

I agree with Egor. The number of active committers is not so big
currently. So I think it is enough just to establish a good committing
policy and let the committer to decide for himself about each commit.
We may always find the author of bad commit and blame him publicly.

> 2. why req tags for JIRA? Does this help committers to follow their
> areas of responsibility?

IMO requirement tags will help to set right priorities to JIRAs. Say
you have a patch that  greatly improves stability of some particular
scenario REQ1 but may affect performance of other scenarios in a bad
way. If the list of requirements is defined then you can set the
priority to critical and put [REQ1] into JIRA summary. Without this
tag it is not clear what this issue is critical for.

Alexey Petrenko wrote:
> About M2 marking... Can we create something like "Target milestone"
> field in our JIRA with predefined values?

Do we have enough power to customize JIRA in this way?

Regards,

05 Jun 2007 09:06:48 +0400, Egor Pasko <egor.pasko@gmail.com>:
> 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?


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message