commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From A Leg <hale_in...@yahoo.com>
Subject Re: commons development practises (was maven : why marmalade ?)
Date Fri, 24 Jun 2005 10:50:00 GMT
Hi Simon

Thank's for your answer. I understand much better this one than previous 
one.

Simon Kitching wrote:

>On Fri, 2005-06-24 at 09:52 +0000, A Leg wrote:
>  
>
>>Hi Simon
>>
>>Thank's for your answer.
>>
>>I don't see any answer about the community process.
>>
>>To help for answer I explain this question below giving an example on 
>>how it works with Jini :
>>When Jini team want to change/improve some specification. Before to do 
>>it they propose it to the community, so community can vote.
>>
>>This is the way that all standards works (Iso, Env, etc..).
>>
>>Why maven, and more generaly, apache projects does not follow similar way ?
>>    
>>
>
>You'll need to ask the maven team why they make the decisions they do -
>this is the jakarta commons list, not the maven list.
>
>Things like moving to subversion and maven *are* well discussed
>beforehand. You'll find lots of email on these subjects in the archives.
>
>  
>
You are right, I will ask to maven mailing list.

>>It could be costly, for users, to change to often and standards try to 
>>be stable.
>>That is why I was asking for the reasons of change : to know what will 
>>be the benefits, to understand and appreciate.
>>    
>>
>
>Jakarta commons doesn't define standards, nor does it implement them.
>Standards have to move very slowly, painfully (and expensively).
>
>  
>
Open source user needs standards to be able to answer to TCO agrguments.
And Apache fondation seems to me one of rare organisation capable to 
produce some.

Example I gave you : Jini community process is moving fast and not 
expensively.
It is arealy cutting edge technology. That is why I gave it as example. 
Are you afraid to "change" your process ?

>No project here in commons has dozens of full-time architects and coders
>(if they do, I want to join!!). So the work has to move at a pace that
>keeps developers involved, or the project will die. Of course old
>releases are always available if you *don't* want to move up to the
>latest releases; they are never deleted. 
>
>  
>
I understand this concern, I have he same. Having a well involved 
community is also a good way to get people motivated.

>Backwards compatibility is taken seriously; features are seldom dropped
>without providing at least one intermediate release where both the old
>and new functionality are present to allow code to be changed over. If
>you (or any other user) do see this happening for a particular release
>of a commons component then please speak up. Even better, offer a patch
>that provides a nicer way of changing from the old to the new behaviour.
>
>And users are very welcome to subscribe to the development list and
>comment on any changes they see. Though comments like "I think you
>should spend lots of your time doing X because I want it" may not get a
>lot of respect (an offer to pay for the work may get a different
>response).
>
>  
>
I agree 100%.

>In fact, I think I can speak for most projects when I say we would
>*really like* more feedback from users. In particular, when release
>candidates are announced there is very seldom any feedback at all from
>the user community for the project - yet you're the ones who should care
>the most. And providing QA by testing candidate releases with your
>software is one of the easiest ways for users of a component to
>contribute back.
>
>  
>
That is why I sent my feedback, to try to explain that backward 
compatibility with maven 1 tags is important.

Regards

Andre

>Regards,
>
>Simon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>  
>


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