On Mon, Jan 9, 2012 at 12:12 PM, sebb <seb...@gmail.com> wrote:
> On 9 January 2012 15:17, Gary Gregory <garydgreg...@gmail.com> wrote:
>> On Mon, Jan 9, 2012 at 9:58 AM, sebb <seb...@gmail.com> wrote:
>>> On 9 January 2012 14:42, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>> I think the whole formality of project state should be replaced with a
>>>> live activity widget like can be seen on other sites. Commit activity
>>>> and such. If someone were thinking of contributing to a project, the
>>>> incentive would be removed or seriously diminished by a dead/sleepy
>>>> project state.
>>>
>>> I think the activity widget could be counter-productive.
>>>
>>> Component activity tends to go in phases; there may be several weeks
>>> with no activity and then a flurry.
>>> Also commits are only a small part of the health of a component.
>>>
>>> Activity monitors can work well for frequently occuring activities,
>>> but component health is much more complicated.
>>>
>>> To take a simple example, try measuring committer productivity by SVN
>>> commits.
>>> Some committers commit large chunks, some commit per file; and that
>>> may vary for a committer.
>>> Some commits are not "productive" - e.g. whitespace fixes, reverts of
>>> a bad commit.
>>> Some commits represent lots of investigation and skill, some may be
>>> much simpler.
>>
>> The idea for me is to get a heartbeat representation, not hard
>> numbers; something that can be automatically generated. If we do
>> decide to change the state of a component, it should be a more serious
>> step.
>
> In which case, the measure should not be published externally, as it
> has no independent meaning.
>
> Which is one of the objections I have to the widget idea - it can
> easily give the wrong impression to outsiders.
>
>> A project can look asleep and be fine IMO, ready to go again.
>> IMO a project should be alive or dead, all this formality for
>> in-between states ("dormant" and whatnot) is not helpful. As soon as
>> someone commits, it's not dormant, and I should not have to officially
>> wake up (with a vote?) a commons project before committing to it IMO.
>
> Again, a single commit is not sufficient to show that a project is active.
> Certainly in the past, there have been global commits to all projects,
> e.g. to correct a problem with site generation.
>
>> Project states, if wanted, should be on the Wiki in a list, "this is
>> how we feel about projects, but a committer can still commit and do
>> work"
>
> That's a separate issue from attracting outside contributions.
>
> But I think there are some components that are clearly not going to be
> developed further, e.g. because the need for them has gone away.
Good point. But does that mean we need more states than alive and
dead? Thinking about The Princess Bride...
I was thinking of the edge case where someone wants a bug fix in a
sleepy project because they have to fix an older application that uses
the component directly or indirectly.
Gary
>
>> 2c,
>> Gary
>>
>>>
>>>> Gary
>>>>
>>>> On Jan 9, 2012, at 6:59, Christian Grobmeier <grobme...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Jelly did not see any activity for nearly two years:
>>>>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly
>>>>>
>>>>> Last release was in 01.2010.
>>>>>
>>>>> We had already discussion on a process to move proper components into
>>>>> another state, be it "dormant" or "inactive". I would like to
>>>>> resurrect this discussion. We have had a lots of discussion in the
>>>>> past: somebody wanted to progress with somehting, like graduating
>>>>> graph or using Java 5 in a component and the response sometimes was we
>>>>> have to less man power at Commons.
>>>>>
>>>>> Therefore I think we need to tell the people for which components they
>>>>> can expect releases and for which ones not. Otherwise outsiders may
>>>>> look at a huge bunch of components and see only little activity.
>>>>> Wouldn't it be better instead to show only a handful components which
>>>>> are actively developed?
>>>>>
>>>>> Looking at Jelly, it is orphaned. No releases, no releases to be
>>>>> expected. I would like to move it to dormant or to a new transition
>>>>> state, if people wish so, maybe called "orphaned" or "inactive" or
>>>>> whatever.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>> Cheers
>>>>> Christian
>>>>>
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
