Commons-Math release schedule

[Hassan Siddiqui <hs...@sciops.esa.int>]

Dear Commons-Math developers

My name is Hassan Siddiqui and I am working on a Java scientific project 
that involves a significant amount of numerical analysis code. There are 
some 300+ developers and scientist involved in this project.

We are using Commons-Math already to an extent but we do intend to be 
more involved.

But one question I would like to ask is what is the process for 
arranging for a new release of Commons-Math. I ask because we have 
6-month release schedule for our mathematical and utility library, which 
makes use of Commons Math, and we would like to see whether we can have 
releases of Commons Math that could fit that release cycle.

We are more than happy to assist in Commons Math releases, if this helps.

Regards

-Hassan.



This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.


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

Re: Commons-Math release schedule

[Gilles Sadowski <gi...@harfang.homelinux.org>]

Hi Luc.

> > I have to agree with James here.  However, if the mysterious
> > team-who-wishes-to-contribute is dead set on 6 month release cycles,
> > it is certainly within their power to make sure 4.5 months ahead of
> > time that every open JIRA issue has a patch attached, and to nag the
> > team incessantly for the following 1.5 months.  ;P
> 
> I agree too that a fixed schedule would be almost impossible to do. We
> have already proven we were not good at schedules ...

I want to stress that scheduling releases is simple; it is scheduling code
development that has proven problematic (cf. Commons Math v2.2).

> On the other hand, we really need to improve, our current release
> frequency is clearly much too low. This almost force people to use
> development version when they are eager to have some bug fix or
> important feature they need.

What I propose has been more clearly explained by Sébastien. We all want to
"release often"; so when the "due" (but not promised!) date (say, every 6
months) comes close, we really do our best to clean up the code (and
postpone all issues that will need more development time), and release all
the work that has been done and agreed on until then.
This will greatly alleviate the problem you cite above.

> 
> A fuzzy objective like "at least twice a year" sound a good compromise
> to me.

If you want to call "twice a year" what I call "every 6 months", that's
fine. ;-)


Best,
Gilles

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

Re: Commons-Math release schedule

[Luc Maisonobe <Lu...@free.fr>]

Hi,

Le 27/03/2012 21:08, Matt Benson a écrit :
> I have to agree with James here.  However, if the mysterious
> team-who-wishes-to-contribute is dead set on 6 month release cycles,
> it is certainly within their power to make sure 4.5 months ahead of
> time that every open JIRA issue has a patch attached, and to nag the
> team incessantly for the following 1.5 months.  ;P

I agree too that a fixed schedule would be almost impossible to do. We
have already proven we were not good at schedules ...

On the other hand, we really need to improve, our current release
frequency is clearly much too low. This almost force people to use
development version when they are eager to have some bug fix or
important feature they need.

A fuzzy objective like "at least twice a year" sound a good compromise
to me.

Luc

> 
> Matt
> 
> On Tue, Mar 27, 2012 at 1:53 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> I don't have a problem saying something like "we will attempt to
>> release at least twice per year."  I don't think it would be wise to
>> say, "we will have a release on 1/1 and 7/1 every year."
>>
>> Release early!  Release often!  Have 12 releases a year if you want.
>> Just don't promise them.
>>
>> On Tue, Mar 27, 2012 at 2:49 PM, Sébastien Brisard
>> <se...@m4x.org> wrote:
>>> Hello,
>>> maybe we could mix both approaches.
>>>
>>> Following James, releases could be feature-based, using the JIRA
>>> system. If after 3 months, the goal is reached, we could release.
>>>
>>> However, as Gilles suggested we could at least do our best to at least
>>> try and release twice a year. This means that about a month before the
>>> "deadline", we could all review the present state of the library, and
>>> decide what should be done to get it released. That's what happened in
>>> 3.0: there was an urge for a release, so some feature requests were
>>> just postponed, and we all tried to clear up the most urgent JIRA
>>> tickets.
>>>
>>> As for working both on 3.1 and 4.0, I'm all for it (means I'll
>>> probably be struggling again with svn, though...).
>>>
>>> Sébastien
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


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

Re: Commons-Math release schedule

[Matt Benson <gu...@gmail.com>]

I have to agree with James here.  However, if the mysterious
team-who-wishes-to-contribute is dead set on 6 month release cycles,
it is certainly within their power to make sure 4.5 months ahead of
time that every open JIRA issue has a patch attached, and to nag the
team incessantly for the following 1.5 months.  ;P

Matt

On Tue, Mar 27, 2012 at 1:53 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> I don't have a problem saying something like "we will attempt to
> release at least twice per year."  I don't think it would be wise to
> say, "we will have a release on 1/1 and 7/1 every year."
>
> Release early!  Release often!  Have 12 releases a year if you want.
> Just don't promise them.
>
> On Tue, Mar 27, 2012 at 2:49 PM, Sébastien Brisard
> <se...@m4x.org> wrote:
>> Hello,
>> maybe we could mix both approaches.
>>
>> Following James, releases could be feature-based, using the JIRA
>> system. If after 3 months, the goal is reached, we could release.
>>
>> However, as Gilles suggested we could at least do our best to at least
>> try and release twice a year. This means that about a month before the
>> "deadline", we could all review the present state of the library, and
>> decide what should be done to get it released. That's what happened in
>> 3.0: there was an urge for a release, so some feature requests were
>> just postponed, and we all tried to clear up the most urgent JIRA
>> tickets.
>>
>> As for working both on 3.1 and 4.0, I'm all for it (means I'll
>> probably be struggling again with svn, though...).
>>
>> Sébastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: Commons-Math release schedule

[James Carman <ja...@carmanconsulting.com>]

I don't have a problem saying something like "we will attempt to
release at least twice per year."  I don't think it would be wise to
say, "we will have a release on 1/1 and 7/1 every year."

Release early!  Release often!  Have 12 releases a year if you want.
Just don't promise them.

On Tue, Mar 27, 2012 at 2:49 PM, Sébastien Brisard
<se...@m4x.org> wrote:
> Hello,
> maybe we could mix both approaches.
>
> Following James, releases could be feature-based, using the JIRA
> system. If after 3 months, the goal is reached, we could release.
>
> However, as Gilles suggested we could at least do our best to at least
> try and release twice a year. This means that about a month before the
> "deadline", we could all review the present state of the library, and
> decide what should be done to get it released. That's what happened in
> 3.0: there was an urge for a release, so some feature requests were
> just postponed, and we all tried to clear up the most urgent JIRA
> tickets.
>
> As for working both on 3.1 and 4.0, I'm all for it (means I'll
> probably be struggling again with svn, though...).
>
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: Commons-Math release schedule

[Sébastien Brisard <se...@m4x.org>]

Hello,
maybe we could mix both approaches.

Following James, releases could be feature-based, using the JIRA
system. If after 3 months, the goal is reached, we could release.

However, as Gilles suggested we could at least do our best to at least
try and release twice a year. This means that about a month before the
"deadline", we could all review the present state of the library, and
decide what should be done to get it released. That's what happened in
3.0: there was an urge for a release, so some feature requests were
just postponed, and we all tried to clear up the most urgent JIRA
tickets.

As for working both on 3.1 and 4.0, I'm all for it (means I'll
probably be struggling again with svn, though...).

Sébastien


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

Re: Commons-Math release schedule

[James Carman <ja...@carmanconsulting.com>]

As opposed to calendar-based release scheduling, I would suggest
perhaps using a more feature-based approach.  For transparency, use
JIRA's target version (or whatever it's called) to schedule which
releases will contain fixes for which issues.  The reason I'm hesitant
to put something on the calendar is because we are a volunteer-based
organization (for the most part).  What if the developers just don't
have time to get to anything?  Of course, there's the flip side of
that equation.  What if our developers rock out everything that should
be in a release?  Why wait until the end of the 6 month window?
Release now! :)


On Tue, Mar 27, 2012 at 1:52 PM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> Hi.
>
>> I am -1 to publishing any sort of release schedule to which we would
>> be held accountable.
>
> I was speaking for Commons Math. IMHO, it is a disservice to the project to
> have releases more than 12 months apart, as it has just been the case.
> This gives the feeling that the code is stable and in maintenance mode,
> which is totally wrong for Commons Math (contrary to most of the projects in
> Commons).
> Moreover there is no notion of accountability, just a little effort to be
> more transparent.  Indeed, what I'm asking is a presentation of the criteria
> such that this statement is true:
>  "[...] the component has reached a state where another release is worth
>   doing [...]"
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: Commons-Math release schedule

[Gilles Sadowski <gi...@harfang.homelinux.org>]

Hi.

> I am -1 to publishing any sort of release schedule to which we would
> be held accountable.

I was speaking for Commons Math. IMHO, it is a disservice to the project to
have releases more than 12 months apart, as it has just been the case.
This gives the feeling that the code is stable and in maintenance mode,
which is totally wrong for Commons Math (contrary to most of the projects in
Commons).
Moreover there is no notion of accountability, just a little effort to be
more transparent.  Indeed, what I'm asking is a presentation of the criteria
such that this statement is true:
  "[...] the component has reached a state where another release is worth
   doing [...]"


Gilles

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

Re: Commons-Math release schedule

[James Carman <ja...@carmanconsulting.com>]

I am -1 to publishing any sort of release schedule to which we would
be held accountable.

On Tue, Mar 27, 2012 at 8:33 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> Hello.
>
>> > [...]
>> >
>> > But one question I would like to ask is what is the process for
>> > arranging for a new release of Commons-Math. I ask because we have
>> > 6-month release schedule for our mathematical and utility library, which
>> > makes use of Commons Math, and we would like to see whether we can have
>> > releases of Commons Math that could fit that release cycle.
>>
>> Yes. We have not been very good at this for the last release and it was
>> way too late. However, we do want to be more in line with the "release
>> early, really often" credo.
>>
>> What is most needed is help in resolving the issues that are registered
>> in our JIRA tracking system
>> (<https://issues.apache.org/jira/browse/MATH>). Opening new issues also
>> help improving the product, of course, but help in solving them is most
>> wanted.
>>
>> As far as simple issues are concerned, they can be dicussed on the JIRA
>> tracker itself, and patches can be attached (not forgetting to check the
>> box allowing us to include the patch in the main code). Testing the
>> already provided patch and cleaning them so they do have appropriate
>> comments, javadocs and test cases helps. When discussion on issues is
>> too long, it is better to switch the discussion to the developers
>> mailing list, as it is a more appropriate place for this.
>>
>> When the component has reached a state where another release is worth
>> doing, then asking for such a release on the dev list and helping in
>> freezing the code and polishing it is greatly appreciated.
>
> IIUC, the issue is indeed to have a more objective definition of "component
> has reached a state where another release is worth doing".
>
> From a user's point-of-view, _any_ improvement, be it a bug fix or a new
> feature, is worth being released.
> In order to "release early, really often", I would thus propose that we
> stick to a time-based release schedule. Every 6 months would be nice indeed.
>
> [I also think that the shorter the span between releases, the easier the
> pre-release work (code cleanup, etc).]
>
>> >
>> > We are more than happy to assist in Commons Math releases, if this helps.
>>
>
> Apart from the "usual" CM work described above, I wonder whether the
> proposed additional human resources could allow parallel development of the
> 3.x (backward-compatible) releases and the 4.0 release.
> Until now, this could not be achieved due to the low number of active
> developers (w.r.t. to the amount of code).
> The advantage would be that some interesting, but compatibility-breaking,
> ideas could be
>  * implemented and tested without delay, and
>  * readily compared with the "stable code".
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: Commons-Math release schedule

[Gilles Sadowski <gi...@harfang.homelinux.org>]

Hello.

> > [...]
> > 
> > But one question I would like to ask is what is the process for
> > arranging for a new release of Commons-Math. I ask because we have
> > 6-month release schedule for our mathematical and utility library, which
> > makes use of Commons Math, and we would like to see whether we can have
> > releases of Commons Math that could fit that release cycle.
> 
> Yes. We have not been very good at this for the last release and it was
> way too late. However, we do want to be more in line with the "release
> early, really often" credo.
> 
> What is most needed is help in resolving the issues that are registered
> in our JIRA tracking system
> (<https://issues.apache.org/jira/browse/MATH>). Opening new issues also
> help improving the product, of course, but help in solving them is most
> wanted.
> 
> As far as simple issues are concerned, they can be dicussed on the JIRA
> tracker itself, and patches can be attached (not forgetting to check the
> box allowing us to include the patch in the main code). Testing the
> already provided patch and cleaning them so they do have appropriate
> comments, javadocs and test cases helps. When discussion on issues is
> too long, it is better to switch the discussion to the developers
> mailing list, as it is a more appropriate place for this.
> 
> When the component has reached a state where another release is worth
> doing, then asking for such a release on the dev list and helping in
> freezing the code and polishing it is greatly appreciated.

IIUC, the issue is indeed to have a more objective definition of "component
has reached a state where another release is worth doing".

>From a user's point-of-view, _any_ improvement, be it a bug fix or a new
feature, is worth being released.
In order to "release early, really often", I would thus propose that we
stick to a time-based release schedule. Every 6 months would be nice indeed.

[I also think that the shorter the span between releases, the easier the
pre-release work (code cleanup, etc).]

> > 
> > We are more than happy to assist in Commons Math releases, if this helps.
> 

Apart from the "usual" CM work described above, I wonder whether the
proposed additional human resources could allow parallel development of the
3.x (backward-compatible) releases and the 4.0 release.
Until now, this could not be achieved due to the low number of active
developers (w.r.t. to the amount of code).
The advantage would be that some interesting, but compatibility-breaking,
ideas could be
  * implemented and tested without delay, and
  * readily compared with the "stable code".


Best regards,
Gilles

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

Re: Commons-Math release schedule

[Luc Maisonobe <Lu...@free.fr>]

Le -10/01/-28163 20:59, Hassan Siddiqui a écrit :
> Dear Commons-Math developers

Hi Hassan,

> 
> My name is Hassan Siddiqui and I am working on a Java scientific project
> that involves a significant amount of numerical analysis code. There are
> some 300+ developers and scientist involved in this project.

I guess I (and Gilles even more than me) know which project you are
talking about ...

> 
> We are using Commons-Math already to an extent but we do intend to be
> more involved.

Fine.

> 
> But one question I would like to ask is what is the process for
> arranging for a new release of Commons-Math. I ask because we have
> 6-month release schedule for our mathematical and utility library, which
> makes use of Commons Math, and we would like to see whether we can have
> releases of Commons Math that could fit that release cycle.

Yes. We have not been very good at this for the last release and it was
way too late. However, we do want to be more in line with the "release
early, really often" credo.

What is most needed is help in resolving the issues that are registered
in our JIRA tracking system
(<https://issues.apache.org/jira/browse/MATH>). Opening new issues also
help improving the product, of course, but help in solving them is most
wanted.

As far as simple issues are concerned, they can be dicussed on the JIRA
tracker itself, and patches can be attached (not forgetting to check the
box allowing us to include the patch in the main code). Testing the
already provided patch and cleaning them so they do have appropriate
comments, javadocs and test cases helps. When discussion on issues is
too long, it is better to switch the discussion to the developers
mailing list, as it is a more appropriate place for this.

When the component has reached a state where another release is worth
doing, then asking for such a release on the dev list and helping in
freezing the code and polishing it is greatly appreciated.

> 
> We are more than happy to assist in Commons Math releases, if this helps.

Thanks for your help.

Luc

> 
> Regards
> 
> -Hassan.
> 
> 
> 
> This message and any attachments are intended for the use of the
> addressee or addressees only. The unauthorised disclosure, use,
> dissemination or copying (either in whole or in part) of its content is
> not permitted. If you received this message in error, please notify the
> sender and delete it from your system. Emails can be altered and their
> integrity cannot be guaranteed by the sender.
> 
> Please consider the environment before printing this email.
> 
> 


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