2007/6/7, Tim Ellison <t.p.ellison@gmail.com>:
> Mikhail Loenko wrote:
> > 2007/6/7, Tim Ellison <t.p.ellison@gmail.com>:
> >> Mikhail Loenko wrote:
> >> > I've added new requirements from this thread to [1,2]
> >> >
> >> > I've also put names of the requirements.
> >> > We may use these names in comments to JIRAs to simplify search.
> >> >
> >> > Please comment
> >> >
> >> > Thanks,
> >> > Mikhail
> >> >
> >> > [1] http://harmony.apache.org/m2.html
> >> > [2]
> >> http://svn.apache.org/viewvc/harmony/standard/site/docs/m2.html?view=co
> >>
> >> I have a problem with the way the requirements are being stated for M2.
> >>  Maybe it is just the terminology I'm uncomfortable with, that they are
> >> being stated as 'requirements' and not 'goals'.
> >>
> >> What happens if these requirements are not met?  Do you slip the date of
> >
> > It's probably just the terminology. No, I'm not suggesting slipping the
> > date.
>
> Ok, then I'm fine with the idea, and apologies for the misunderstanding.
>  To my ear, a 'requirement' is mandatory/necessary, whereas a 'goal' is
> an aim/direction.

I think you understanding is more correct, you have a native ear :)

I'll change "reguirement" to "goal"

>
> Having goals and themes that we work towards for the milestones is quite
> reasonable.  People will work on whatever their 'itch' dictates, but it
> is fine to allow people to declare what they are working towards.  Just
> to be clear, we would not stop people working on a problem because it
> does not fit in with a written goal.
>
> >> M2 or drop some requirements?  I would suggest that instead we have
> >> timeboxed stable development cycles, and plan what should get into each
> >> stable milestone.
> >>
> >> I still haven't heard a good reason why these should be put into JIRA
> >> titles either.  Can't we just agree that a JIRA should be in Milestone
> >> 'X' or not?  Are you looking to group the JIRA issues into themes?
> >
> > I did not talk about the titles, I suggested some way to be able to sort
> > out requirements (or goals) and see which bugs need to be fixed to meet
> > some specific goal.
> >
> > I guess that our goals will be quite aggressive and we probably won't
> >  meet all of them. And if 3 days before milestone I see that 100 bugs
> > left and to meet goal N I need to fix one bug and to meet goal M I
> > need to fix 10 bugs I'll probably start with that only bug necessary
> > to meet the goal N. For that reason I need to be able to find bugs
> > affecting reqs (goals). I suggest that we use reg (goal) name in
> > comments, so that we can easily find which JIRA issues impact this
> > specific req.
>
> We welcome JIRAs from any Harmony user, so creating a new issue or
> reading an existing issue should not become burdened with undue process.
>  A comment that an issue, for example, "blocks running a simple Tomcat
> scenario" makes sense to everyone, but a comment saying "M2_APP4" is
> just lingo.
>
> I wonder what is the best way of marking a JIRA issue so we can 'query
> by goal' without having to embed unreadable tags?
>
> Maybe open a JIRA for the 'run a simple Tomcat scenario' and make it
> dependent upon JIRAs that block that success.  Just thinking aloud...any
> other ideas?

... and put this JIRA no into the list of goals. It's a good idea!
Those scenarios that currently work (the goal is no regression) won't have
corresponding JIRA number.

Are there other proposals?

Thanks,
Mikhail


>
> > One more question:
> > should the reqs (goals) be on website or wiki?
>
> I'd expect them to be on the wiki, but whatever.
>
> Regards,
> Tim
>