harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [general] Harmony M2 schedule
Date Wed, 06 Jun 2007 05:39:18 GMT
+1 to Rana's proposal about having Milestone field in JIRA. This'll
help to mark those bugs we have to fix for the milestone.

As a JIT developer I'd like to propose also adding subcomponents to
DRLVM component, such as gc_cc, gc_gen, jit etc - this will simplify
tracking bugs related to components people work on.

A "Developer" field will be helpful as well. A developer who did
initial evaluation and set a milestone for the issue may put his/her
name there and an estimate when he/she may start working on this
issue. Thus the submitter gets a clue when the issue will be resolved
and may adjust the priority accordingly or discuss the issue with the
developer. As a developer I often need to discuss the issue with
another developer who has an expertise in this area and the
"developer" field will help me to identify the proper person. Another
developer may pick the issue, put his name into "developer" field and
fix it earlier.

Thanks,
Pavel

On 6/5/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> 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
> >
> >
>

Mime
View raw message