commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <>
Subject Re: [ALL] Do we need help?
Date Mon, 01 Dec 2014 00:42:44 GMT
Hello Benedikt!
I guess I'm being too cautious to commit or work on issues in other components :)
I'll slowly start working on [jelly] to port the changes made in Jenkins. But first will spend
more time on [text], [functor] and [lang].
      From: Benedikt Ritter <>
 To: Commons Developers List <>; Bruno P. Kinoshita <>

 Sent: Sunday, November 30, 2014 4:15 PM
 Subject: Re: [ALL] Do we need help?
Hello Bruno

2014-11-30 0:31 GMT+01:00 Bruno P. Kinoshita <>:

Hi Thomas!
I use Jelly almost every week in Jenkins plug-ins. Talked about the forked repo they have
in the project, and even told them I could spend some hours every week to fix the necessary
Even though it is possible to use Groovy in Jenkins views too now, there are so many existing
plug-ins (that are used as basis for new plug-ins) that I find it very hard to see jelly removed
from Jenkins.
Would anyone be interested and have time to push a new release ? I could check what needed
to be done in [jelly] and either update or add new issues.

You always seem to be forgetting, that you're commons committer :-) If you feel like working
on any component, just drop a mail on the ML and start work ;-) Other people will eventually
join you.


      From: Thomas Neidhart <>
 To: Commons Developers List <>
 Sent: Saturday, November 29, 2014 2:31 PM
 Subject: Re: [ALL] Do we need help?

On 11/29/2014 11:53 AM, Benedikt Ritter wrote:
> Hi all,
> currently I feel really overwhelmed by the stuff I'd like to do at commons
> and the little time I can spend for it. Here is an (incomplete) list of the
> things I'd like to work on:

Hi Benedikt,

> - get a new release of the build plugin out of the door for auto creating
> and
> - Work on [VALIDATOR] and get a new release out of the door
> - Work on [DBUTILS] and get a new release out of the door
> - Push [lang] 3.4 out of the door
> - Have a look at [compress] 2.0
> - Backport important fixes from [collections] 4.0 to 3.x and create a last
> service update
> - work on [text]
> - help releasing [imaging] 1.0
> - Improve docs on how to get involved at commons
> - Organize a logo contest for commons
> - ... many more

this sounds like you set your goals too high and are frustrated that you
don't get all the things done. I guess this is a common scheme for
ambitious/passionate people. Try to set more realistic goals and finish
them before doing other / more things. Then you will get the positive
feedback of achieving something and everything will be better.

> I wonder how you feel about this. I have the feeling that a lot of people
> ask us to fix stuff and release components but we don't really catch up
> with this. This will give people the feeling that we are slow or we simply
> don't care.
> Whenever I see someone posting on JIRA "can you please fix this, we need
> this in out application" and nobody is reacting, I feel tempted to jump
> right in, even if I don't know the component (which adds another entry to
> the list above).
> I don't see a way how we can improve this. My feeling is, that we need more
> committers. But then I have the comments of people I've talked to in my
> ear: "to old school", "to difficult to get involved", "to slow development
> process", "to unwelcoming community". So what do we do? Do we need help?
> I'm excited to hear your thoughts :-)

yeah, this is a general problem of commons imho. There are too many
components for a too small community as most of the original committers
have long left.

The only way out is to do what we tried a couple of months ago: move not
maintained components to dormant, and keep the others alive with the
existing people.

Just one example: jelly is a nice thing and actually used within jenkins
as the backbone html generator. But it is re-packaged within jenkins
custom bugfixes as the last jelly release (1.0) was in 2005.

Similar things apply for el or primitives.

These components are long dead and there are very good alternatives
available, so they should be abandoned. Cut off the dead branches to
keep the tree alive.


To unsubscribe, e-mail:
For additional commands, e-mail:



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message