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 Wed, 06 Jun 2007 06:49:14 GMT
On the 0x2ED day of Apache Harmony Pavel Ozhdikhin wrote:
> Mikhail,
> 
> Thanks for capturing the requirements. IMO the requirements still lack
> good tests to ensure stability and reliability. I propose to include
> the following recently accepted tests:
> 
> 1. VM validation test suite - http://issues.apache.org/jira/browse/HARMONY-3206
> 2. Functional test suite - http://issues.apache.org/jira/browse/HARMONY-3528
> 3. Stress tests - http://issues.apache.org/jira/browse/HARMONY-3536
> 4. Reliability test - https://issues.apache.org/jira/browse/HARMONY-2918
> 
> Olegs seems proposed a reasonable target for the tests-  98% pass rate
> of all valid tests from these test suites.

what is the % today? where can I find these numbers to make sure 98% is real?

If we formulate M2 in percentage terms, then it makes sense to
regularly update a wiki page with percentage of tests passed for each
platform/testsuite. I think, Oleg would be glad to do that :)

> Thanks,
> Pavel
> 
> On 6/6/07, Mikhail Loenko <mloenko@gmail.com> wrote:
> > I've captured all the proposed requirements and schedule here [1]
> > (it should appear shortly, until that you may find it here [2])
> >
> > The requirements do not look quite aggressive, can we do more
> > by the end of month?
> >
> > Should I put there names of the people who proposed requirements?
> >
> > Sure, we can use "Due Before" field to mark JIRA issues, what is the most
> > natural way to find which bugs affect some specific requirement?
> >
> > I personally don't like having many [sometext] in JIRA summary...
> > Maybe we can add some specific text to comments?
> >
> > For example if requirements have names, we could add comments like
> > "this one badly affects M2-REQ1" to JIRA and then use e.g. M2-REQ1 as
> > a search string.
> >
> > The only problem I see with that is that people could drop dash or misspell
> > the name in other way, and these bugs might be overlooked. Though the
> > due before field won't probably allow us to overlook...
> >
> > Opinions?
> >
> > Thanks,
> > Mikhail
> >
> > [1] http://harmony.apache.org/m2.html
> > [2] http://svn.apache.org/viewvc/harmony/standard/site/docs/m2.html?view=co
> >
> > 2007/6/5, Rana Dasgupta <rdasgupt@gmail.com>:
> > > 2 months sounds like a reasonable interval. How about just expanding
> > > the jira to mark milestone..(.in fact existing fields like "Due
> > > Before" etc. could be used)...but keeping the milestone requirement
> > > list on the Wiki?
> > >
> > > On 05 Jun 2007 18:23:22 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
> > > > On the 0x2EC day of Apache Harmony Alexei Zakharov wrote:
> > > > > 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.
> > > >
> > > > that makes sense, sounds good, thanks
> > > >
> > > > > 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
> > > > >
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> > >
> >
> 

-- 
Egor Pasko


Mime
View raw message