Is our objective for 2.0 too ambitious? (was Re: Ivy 2.0 planning)

[Xavier Hanin]

More than one month ago we agreed to focus on bug fixing for 2.0 final (see
my original mail below).
At that time we had about 80+ issues targeted at 2.0.
Since then it seems we have fixed 57 issues:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310580&fixfor=12313012

But we still have 64 issues to fix, which shows that new issues comes up (or
some where retargeted or created to detail issues being fixed).

This leads me to one question: is our objective to fix all open bugs for 2.0
too ambitious? I'm not sure I'll have much time to dedicate to Ivy in the
coming months, I don't know for you guys, but maybe this objective will lead
us to a delayed release. At the end of the month Ivy 1.0 will be 3 years old
(1.0 was released on April 26th, 2005), almost half of those three years
were spent @ ASF, with no final release.

I think Ivy community need a release labelled as final no later than may or
june, and I'm not sure we can reach this with our current objective.

So, what do you think? Shall we reconsider our objective for 2.0, and
retarget some of the issues for a 2.0.x?

Xavier

On Thu, Feb 28, 2008 at 8:32 PM, Xavier Hanin <xavier.hanin@...>
wrote:

> Hi,
>
> Ivy 2.0 beta 2 being around the corner, I've reviewed some of the current
> open issues in JIRA. I've marked all open bugs to be fixed in 2.0, as I
> would like to make 2.0 final as stable and clean as possible. I even think
> that fixing bugs should be our main focus now toward 2.0 final. The current
> feature set is pretty good, so if we don't want to dilute too much our
> effort and the time frame for 2.0 final, I think focusing on bug fix is a
> good option. I don't say we should stop developing features, sometimes we
> may have some needs or specific interest in some new features. Moreover
> fixing bugs is not the most entertaining thing to do, so we'll probably need
> some rest with more interesting stuff :-).
>
> So, do you guys agree with this plan?
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Stefan Bodewig]

On Wed, 16 Apr 2008, Xavier Hanin <xavier.hanin@...> wrote:

> So, what do you think? Shall we reconsider our objective for 2.0,
> and retarget some of the issues for a 2.0.x?

Comments from the peanut gallery:

There are certain categories of bugs that you can't really re-target,
those that would require API (both Java and XML) changes or those that
are critical and break existing use-cases of Ivy 1.x.

Then there are "nice-to-have" features or "can-be-worked-around" bugs.

You'll probably never get to any final release without accepting that
it will ship with issues of the later category.  Fix those of the
first category and call the result final, probably is the best way
forward.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gilles Scokart]

On 16/04/2008, Stefan Bodewig <bodewig@...> wrote:

> On Wed, 16 Apr 2008, Xavier Hanin <xavier.hanin@...> wrote:
>
>  > So, what do you think? Shall we reconsider our objective for 2.0,
>  > and retarget some of the issues for a 2.0.x?
>
>  Comments from the peanut gallery:
>
>  There are certain categories of bugs that you can't really re-target,
>  those that would require API (both Java and XML) changes or those that
>  are critical and break existing use-cases of Ivy 1.x.
>

+1 for the XML, but -1 for the java API.
We discussed already in the past about 'publishing' our API [1].  I
think the API is now a way too complexe, and cleaning it would
requires a lot of effort.  I think we should warn our users that the
API may (and I hope will) change in the futur

[1] http://markmail.org/message/dm54bglzuvrsgddm

>  Then there are "nice-to-have" features or "can-be-worked-around" bugs.
>
>  You'll probably never get to any final release without accepting that
>  it will ship with issues of the later category.  Fix those of the
>  first category and call the result final, probably is the best way
>  forward.
>
>  Stefan
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

--
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bruce Atherton]

I think you have to accept that there will be bugs. After all, would you
halt the whole release if a minor bug was found the day before it was
due to be published?

But there are different categories of bugs. Some are so serious that you
don't want to roll a release with it no matter what. This category
really should result in pulling a release the day before publishing.
Then there is a descending scale after that.

My suggestion would be to use the Priority field for this purpose. Here
is how I use the Jira priorities:
  - Anything labeled "Blocker" should be fixed ASAP. It might be
impacting other developers working from the tip or perhaps breaking Gump.
  - "Critical" is for anything that has to be fixed before a release can
go out.
  - "Major" issues should be targeted for fixing for a release and their
number kept as low as possible, but if any ended up in a release you
wouldn't lose sleep over it.
  - "Minor" issues are the "nice-to-haves".
  - "Trivial" issues are ones that someone has complained about but the
developers don't see that fixing them would significantly improve the
product.

If you have some sort of standard like that to go by, I think you can
fairly rapidly differentiate the bugs and then define a release as: No
Blockers or Criticals, and as few Majors as is practical to accomplish
within the time span available. The number of Minors and Trivials are
ignored.

Xavier Hanin wrote:

> More than one month ago we agreed to focus on bug fixing for 2.0 final (see
> my original mail below).
> At that time we had about 80+ issues targeted at 2.0.
> Since then it seems we have fixed 57 issues:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310580&fixfor=12313012
>
> But we still have 64 issues to fix, which shows that new issues comes up (or
> some where retargeted or created to detail issues being fixed).
>
> This leads me to one question: is our objective to fix all open bugs for 2.0
> too ambitious?
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <bruce@...> wrote:

> I think you have to accept that there will be bugs. After all, would you
> halt the whole release if a minor bug was found the day before it was due to
> be published?
>
> But there are different categories of bugs. Some are so serious that you
> don't want to roll a release with it no matter what. This category really
> should result in pulling a release the day before publishing. Then there is
> a descending scale after that.
>
> My suggestion would be to use the Priority field for this purpose. Here is
> how I use the Jira priorities:
>  - Anything labeled "Blocker" should be fixed ASAP. It might be impacting
> other developers working from the tip or perhaps breaking Gump.
>  - "Critical" is for anything that has to be fixed before a release can go
> out.
>  - "Major" issues should be targeted for fixing for a release and their
> number kept as low as possible, but if any ended up in a release you
> wouldn't lose sleep over it.
>  - "Minor" issues are the "nice-to-haves".
>  - "Trivial" issues are ones that someone has complained about but the
> developers don't see that fixing them would significantly improve the
> product.
>
> If you have some sort of standard like that to go by, I think you can
> fairly rapidly differentiate the bugs and then define a release as: No
> Blockers or Criticals, and as few Majors as is practical to accomplish
> within the time span available. The number of Minors and Trivials are
> ignored.

That sounds like a good practice. What do others think? How do we proceed to
classify the open bugs?

Xavier

>
>
> Xavier Hanin wrote:
>
> > More than one month ago we agreed to focus on bug fixing for 2.0 final
> > (see
> > my original mail below).
> > At that time we had about 80+ issues targeted at 2.0.
> > Since then it seems we have fixed 57 issues:
> >
> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310580&fixfor=12313012
> >
> > But we still have 64 issues to fix, which shows that new issues comes up
> > (or
> > some where retargeted or created to detail issues being fixed).
> >
> > This leads me to one question: is our objective to fix all open bugs for
> > 2.0
> > too ambitious?
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Nicolas Lalevée-2]

Le jeudi 17 avril 2008, Xavier Hanin a écrit :

> On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <bruce@...> wrote:
> > I think you have to accept that there will be bugs. After all, would you
> > halt the whole release if a minor bug was found the day before it was due
> > to be published?
> >
> > But there are different categories of bugs. Some are so serious that you
> > don't want to roll a release with it no matter what. This category really
> > should result in pulling a release the day before publishing. Then there
> > is a descending scale after that.
> >
> > My suggestion would be to use the Priority field for this purpose. Here
> > is how I use the Jira priorities:
> >  - Anything labeled "Blocker" should be fixed ASAP. It might be impacting
> > other developers working from the tip or perhaps breaking Gump.
> >  - "Critical" is for anything that has to be fixed before a release can
> > go out.
> >  - "Major" issues should be targeted for fixing for a release and their
> > number kept as low as possible, but if any ended up in a release you
> > wouldn't lose sleep over it.
> >  - "Minor" issues are the "nice-to-haves".
> >  - "Trivial" issues are ones that someone has complained about but the
> > developers don't see that fixing them would significantly improve the
> > product.
> >
> > If you have some sort of standard like that to go by, I think you can
> > fairly rapidly differentiate the bugs and then define a release as: No
> > Blockers or Criticals, and as few Majors as is practical to accomplish
> > within the time span available. The number of Minors and Trivials are
> > ignored.
>
> That sounds like a good practice. What do others think? How do we proceed
> to classify the open bugs?

I am in favor of a such classification too. About the process to classify
them, I would say that it would be the same process as fixing issues. A
committer get interested to an issue, try to found out to what's behind, and
then decides its priority. And the other committers check via the
notifications@ant list.

Nicolas

>
> Xavier
>
> > Xavier Hanin wrote:
> > > More than one month ago we agreed to focus on bug fixing for 2.0 final
> > > (see
> > > my original mail below).
> > > At that time we had about 80+ issues targeted at 2.0.
> > > Since then it seems we have fixed 57 issues:
> > >
> > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> > >d=12310580&fixfor=12313012
> > >
> > > But we still have 64 issues to fix, which shows that new issues comes
> > > up (or
> > > some where retargeted or created to detail issues being fixed).
> > >
> > > This leads me to one question: is our objective to fix all open bugs
> > > for 2.0
> > > too ambitious?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...

--
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : [phone]
Fax : [phone]
http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Thu, Apr 17, 2008 at 10:38 AM, Nicolas Lalevée <
nicolas.lalevee@...> wrote:

> Le jeudi 17 avril 2008, Xavier Hanin a écrit :
> > On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <bruce@...>
> wrote:
> > > I think you have to accept that there will be bugs. After all, would
> you
> > > halt the whole release if a minor bug was found the day before it was
> due
> > > to be published?
> > >
> > > But there are different categories of bugs. Some are so serious that
> you
> > > don't want to roll a release with it no matter what. This category
> really
> > > should result in pulling a release the day before publishing. Then
> there
> > > is a descending scale after that.
> > >
> > > My suggestion would be to use the Priority field for this purpose.
> Here
> > > is how I use the Jira priorities:
> > >  - Anything labeled "Blocker" should be fixed ASAP. It might be
> impacting
> > > other developers working from the tip or perhaps breaking Gump.
> > >  - "Critical" is for anything that has to be fixed before a release
> can
> > > go out.
> > >  - "Major" issues should be targeted for fixing for a release and
> their
> > > number kept as low as possible, but if any ended up in a release you
> > > wouldn't lose sleep over it.
> > >  - "Minor" issues are the "nice-to-haves".
> > >  - "Trivial" issues are ones that someone has complained about but the
> > > developers don't see that fixing them would significantly improve the
> > > product.
> > >
> > > If you have some sort of standard like that to go by, I think you can
> > > fairly rapidly differentiate the bugs and then define a release as: No
> > > Blockers or Criticals, and as few Majors as is practical to accomplish
> > > within the time span available. The number of Minors and Trivials are
> > > ignored.
> >
> > That sounds like a good practice. What do others think? How do we
> proceed
> > to classify the open bugs?
>
> I am in favor of a such classification too. About the process to classify
> them, I would say that it would be the same process as fixing issues. A
> committer get interested to an issue, try to found out to what's behind,
> and
> then decides its priority. And the other committers check via the
> notifications@ant list.

But how do we know that the issue priority has been reviewed, especially if
it doesn't change?

Xavier

>
>
> Nicolas
>
> >
> > Xavier
> >
> > > Xavier Hanin wrote:
> > > > More than one month ago we agreed to focus on bug fixing for 2.0
> final
> > > > (see
> > > > my original mail below).
> > > > At that time we had about 80+ issues targeted at 2.0.
> > > > Since then it seems we have fixed 57 issues:
> > > >
> > > >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> > > >d=12310580&fixfor=12313012
> > > >
> > > > But we still have 64 issues to fix, which shows that new issues
> comes
> > > > up (or
> > > > some where retargeted or created to detail issues being fixed).
> > > >
> > > > This leads me to one question: is our objective to fix all open bugs
> > > > for 2.0
> > > > too ambitious?
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
>
>
>
> --
> Nicolas LALEVÉE
> ANYWARE TECHNOLOGIES
> Tel : [phone]
> Fax : [phone]
> http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Nicolas Lalevée-2]

Le jeudi 17 avril 2008, Xavier Hanin a écrit :

> On Thu, Apr 17, 2008 at 10:38 AM, Nicolas Lalevée <
>
> nicolas.lalevee@...> wrote:
> > Le jeudi 17 avril 2008, Xavier Hanin a écrit :
> > > On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <bruce@...>
> >
> > wrote:
> > > > I think you have to accept that there will be bugs. After all, would
> >
> > you
> >
> > > > halt the whole release if a minor bug was found the day before it was
> >
> > due
> >
> > > > to be published?
> > > >
> > > > But there are different categories of bugs. Some are so serious that
> >
> > you
> >
> > > > don't want to roll a release with it no matter what. This category
> >
> > really
> >
> > > > should result in pulling a release the day before publishing. Then
> >
> > there
> >
> > > > is a descending scale after that.
> > > >
> > > > My suggestion would be to use the Priority field for this purpose.
> >
> > Here
> >
> > > > is how I use the Jira priorities:
> > > >  - Anything labeled "Blocker" should be fixed ASAP. It might be
> >
> > impacting
> >
> > > > other developers working from the tip or perhaps breaking Gump.
> > > >  - "Critical" is for anything that has to be fixed before a release
> >
> > can
> >
> > > > go out.
> > > >  - "Major" issues should be targeted for fixing for a release and
> >
> > their
> >
> > > > number kept as low as possible, but if any ended up in a release you
> > > > wouldn't lose sleep over it.
> > > >  - "Minor" issues are the "nice-to-haves".
> > > >  - "Trivial" issues are ones that someone has complained about but
> > > > the developers don't see that fixing them would significantly improve
> > > > the product.
> > > >
> > > > If you have some sort of standard like that to go by, I think you can
> > > > fairly rapidly differentiate the bugs and then define a release as:
> > > > No Blockers or Criticals, and as few Majors as is practical to
> > > > accomplish within the time span available. The number of Minors and
> > > > Trivials are ignored.
> > >
> > > That sounds like a good practice. What do others think? How do we
> >
> > proceed
> >
> > > to classify the open bugs?
> >
> > I am in favor of a such classification too. About the process to classify
> > them, I would say that it would be the same process as fixing issues. A
> > committer get interested to an issue, try to found out to what's behind,
> > and
> > then decides its priority. And the other committers check via the
> > notifications@ant list.
>
> But how do we know that the issue priority has been reviewed, especially if
> it doesn't change?

ha, good point :)

So I guess the review have to be done by some volonteers, the list of
remaining issues being shared between them.
I think I can get some time at the end of next week to help.

Nicolas

>
> Xavier
>
> > Nicolas
> >
> > > Xavier
> > >
> > > > Xavier Hanin wrote:
> > > > > More than one month ago we agreed to focus on bug fixing for 2.0
> >
> > final
> >
> > > > > (see
> > > > > my original mail below).
> > > > > At that time we had about 80+ issues targeted at 2.0.
> > > > > Since then it seems we have fixed 57 issues:
> >
> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> >
> > > > >d=12310580&fixfor=12313012
> > > > >
> > > > > But we still have 64 issues to fix, which shows that new issues
> >
> > comes
> >
> > > > > up (or
> > > > > some where retargeted or created to detail issues being fixed).
> > > > >
> > > > > This leads me to one question: is our objective to fix all open
> > > > > bugs for 2.0
> > > > > too ambitious?
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > > For additional commands, e-mail: dev-help@...
> >
> > --
> > Nicolas LALEVÉE
> > ANYWARE TECHNOLOGIES
> > Tel : [phone]
> > Fax : [phone]
> > http://www.anyware-tech.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...

--
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : [phone]
Fax : [phone]
http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bruce Atherton]

Typically you would use a new Status, but I am uncertain about how much
control you have over the Apache Jira instance. Can you introduce new
workflow for your project?

I don't think that merely setting the priority should result in moving
between Open and In Progress. There should be an intermediate state.

Xavier Hanin wrote:

> On Thu, Apr 17, 2008 at 10:38 AM, Nicolas Lalevée <
> nicolas.lalevee@...> wrote:
>
>  
>>
>> I am in favor of a such classification too. About the process to classify
>> them, I would say that it would be the same process as fixing issues. A
>> committer get interested to an issue, try to found out to what's behind,
>> and
>> then decides its priority. And the other committers check via the
>> notifications@ant list.
>>    
>
> But how do we know that the issue priority has been reviewed, especially if
> it doesn't change?
>
> Xavier
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Thu, Apr 17, 2008 at 7:49 PM, Bruce Atherton <bruce@...> wrote:

> Typically you would use a new Status, but I am uncertain about how much
> control you have over the Apache Jira instance. Can you introduce new
> workflow for your project?

It seems I can, but I'm not sure about the policy. Maybe other Ant members
can comment on this?


>
> I don't think that merely setting the priority should result in moving
> between Open and In Progress. There should be an intermediate state.

Cocoon workflow has "OnHold" and "Continued" status, that we could use to
indicate that all bugs are OnHold until we review their priorities.

What do you guys think?

Xavier

>
>
> Xavier Hanin wrote:
>
> > On Thu, Apr 17, 2008 at 10:38 AM, Nicolas Lalevée <
> > nicolas.lalevee@...> wrote:
> >
> >
> >
> > >
> > > I am in favor of a such classification too. About the process to
> > > classify
> > > them, I would say that it would be the same process as fixing issues.
> > > A
> > > committer get interested to an issue, try to found out to what's
> > > behind,
> > > and
> > > then decides its priority. And the other committers check via the
> > > notifications@ant list.
> > >
> > >
> >
> > But how do we know that the issue priority has been reviewed, especially
> > if
> > it doesn't change?
> >
> > Xavier
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Matt Benson]

--- Xavier Hanin <xavier.hanin@...> wrote:

> On Thu, Apr 17, 2008 at 7:49 PM, Bruce Atherton
> <bruce@...> wrote:
>
> > Typically you would use a new Status, but I am
> uncertain about how much
> > control you have over the Apache Jira instance.
> Can you introduce new
> > workflow for your project?
>
> It seems I can, but I'm not sure about the policy.
> Maybe other Ant members
> can comment on this?
>
>
> >
> > I don't think that merely setting the priority
> should result in moving
> > between Open and In Progress. There should be an
> intermediate state.
>
> Cocoon workflow has "OnHold" and "Continued" status,
> that we could use to
> indicate that all bugs are OnHold until we review
> their priorities.
>
> What do you guys think?

I don't think you need permission to use resources
already at your disposal, here JIRA statuses (stati?),
as you see fit.  ;)

-Matt

>
> Xavier
>
>
> >
> >
> > Xavier Hanin wrote:
> >
> > > On Thu, Apr 17, 2008 at 10:38 AM, Nicolas
> Lalevée <
> > > nicolas.lalevee@...> wrote:
> > >
> > >
> > >
> > > >
> > > > I am in favor of a such classification too.
> About the process to
> > > > classify
> > > > them, I would say that it would be the same
> process as fixing issues.
> > > > A
> > > > committer get interested to an issue, try to
> found out to what's
> > > > behind,
> > > > and
> > > > then decides its priority. And the other
> committers check via the
> > > > notifications@ant list.
> > > >
> > > >
> > >
> > > But how do we know that the issue priority has
> been reviewed, especially
> > > if
> > > it doesn't change?
> > >
> > > Xavier
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>

---------------------------------------------------------------------

> > To unsubscribe, e-mail:
> dev-unsubscribe@...
> > For additional commands, e-mail:
> dev-help@...
> >
> >
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gilles Scokart]

On 17/04/2008, Nicolas Lalevée <nicolas.lalevee@...> wrote:
>  >
>  > But how do we know that the issue priority has been reviewed, especially if
>  > it doesn't change?
>
>
> ha, good point :)
>

Maybe updating the target release...  Using the release 2.0-RC1 and
creating a new release named 'later'.


--
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Fri, Apr 18, 2008 at 8:48 AM, Gilles Scokart <gscokart@...> wrote:

> On 17/04/2008, Nicolas Lalevée <nicolas.lalevee@...> wrote:
> >  >
> >  > But how do we know that the issue priority has been reviewed,
> especially if
> >  > it doesn't change?
> >
> >
> > ha, good point :)
> >
>
> Maybe updating the target release...  Using the release 2.0-RC1 and
> creating a new release named 'later'.

This is the easiest thing to do, it doesn't require changing the workflow.
BTW, instead of creating a release named 'later', we can simply use the
"Unknown" entry, which let issues appear as "unscheduled" in Ivy page on
JIRA.

If I sumup the proposal is that any committer can review any issue currently
marked with fix for 2.0, change its priority if required, and change the fix
for to 2.0-RC1 if the priority is blocker or critical, and Unknown if the
priority is lower. All issues will be considered reviewed once there's no
more issue with fix for 2.0.

Do we all agree to use this strategy?

Xavier

>
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Nicolas Lalevée]

Le 18 avr. 08 à 12:07, Xavier Hanin a écrit :

> On Fri, Apr 18, 2008 at 8:48 AM, Gilles Scokart <gscokart@...>  
> wrote:
>
>> On 17/04/2008, Nicolas Lalevée <nicolas.lalevee@...>  
>> wrote:
>>>>
>>>> But how do we know that the issue priority has been reviewed,
>> especially if
>>>> it doesn't change?
>>>
>>>
>>> ha, good point :)
>>>
>>
>> Maybe updating the target release...  Using the release 2.0-RC1 and
>> creating a new release named 'later'.
>
> This is the easiest thing to do, it doesn't require changing the  
> workflow.
> BTW, instead of creating a release named 'later', we can simply use  
> the
> "Unknown" entry, which let issues appear as "unscheduled" in Ivy  
> page on
> JIRA.
>
> If I sumup the proposal is that any committer can review any issue  
> currently
> marked with fix for 2.0, change its priority if required, and change  
> the fix
> for to 2.0-RC1 if the priority is blocker or critical, and Unknown  
> if the
> priority is lower. All issues will be considered reviewed once  
> there's no
> more issue with fix for 2.0.
>
> Do we all agree to use this strategy?

Sounds good.
+1

Nicolas

>
>
> Xavier
>
>
>>
>>
>>
>> --
>> Gilles Scokart
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...