[Users] Re: openser/ser - avoiding forks

[Daniel-Constantin Mierla]

On 06/16/05 18:51, Andrei Pelinescu-Onciul wrote:

>On Jun 15, 2005 at 22:42, Daniel-Constantin Mierla <daniel at voice-system.ro> wrote:
>
>[...]
>  
>
>>Now, we are not saying that fork is good in general, otherwise it will 
>>be a fork each day :-), but when there is no willing to cooperate, 
>>hold-back policies and abuses for self-promoting I see no other way.
>>    
>>
>
>Let's try not to degenerate in another flame war and please try not to 
> exagerate it:
>
I don't think I do at all, but this is my opinion, so I might be wrong, 
you can have yours ... but how should I call ...

> no willing to cooperate,
>
no response for more than 8 months

> hold-back policies
>
TLS until a few days ago when that experimental repository was born 
(after more than 3 months, for something mandatory in RFC)

> and all the
> other stuff...
>  
>
I stop here, too.

>  
>
>>We will gladly participate in a *really* open source project. A very 
>>good example is the Linux kernel -- it is clear that many of the main 
>>developers and contributors are employed by major Linux vendors, which 
>>have enterprise/closed releases, but you don't see on the main page of 
>>kernel.org advertising for none of them. In the sources is no explicit 
>>advertising message, and so on ...
>>
>>So the proposal is:
>>
>>- move the project's main site on an independent host (I bet there are 
>>people willing to sponsor the hosting)
>>
>>- remove all references that are intended for private publicity
>>    
>>
>
>This will take a while as some of the other core devepers are either
>traveling or will be away for the next days (e.g.: me).
>
>  
>
>>- introduce a better management of the project, allowing people to be 
>>able to take over when someone is very busy or unwilling to cooperate
>>    
>>
>
>That sounds very scary... The general ser approach so far was every one
>is maintaining its own code and other people should not go over it
>without his approval (except for fixing bugs). The ideea here is that
>the code maintainer might have his own plans for its own module and he
>wouldn't want it changed "under him".
>If I'm away for two months I wouldn't like to not recognize what I've
>been working on when I'm back (this of course doesn't include bugfixes).
>There is some  other point: a code maintainer might not accept a change.
>While the change submitor, might think it's the best thing in the world,
>not everyone might share his opinion.
>  
>
So if a maintainer leaves for 10years, everything should freeze because 
he wants to start again along with his grandkids the development. My 
grandkid will love to start using again the project ... Of course, this 
is an exaggeration, but even half an year is much too long.

What we want is __a way to move forward in critical situations__. What 
can guarantee that the maintainer does not act against the project? Do 
not understand wrong, there will not be accepted all patches, but what 
the community requires and needs. When someone spent time to do it, and 
does not harm what exists, but brings more features or quality, give me 
a reason not to accept it. Do not think that the developer and 
maintainer is going to be thrown away day by day. It  must be a strong 
reason behind.

So that a community of people is more impartial that a single person, 
and this should somehow guarantee for fairness.

>  
>
>>- make the project really open for contributions and contributors. 
>>Outstanding developers can be good reviewers for new contributors when 
>>the others are busy
>>    
>>
>
>Yes, I agree, but this doesn't mean that each and every contributions
>will be applied. In fact I do think this problem is exagerated a lot,
>given ser's history (you can look even at your linux kernel example,
>lots of patches are unanswered, and very few make it to the kernel).
>  
>
I said above, not every nit is going to be applied, but if it is 
something good and needed by many users, and someone contributed for 
free, why not? And we can say that ser's history has two parts, the old 
age, when everything went smooth and the last period. As you can see, 
from other reactions, too, there is a strong reason behind this move.

>>- don't hide the new features from the community, we are on open source, 
>>what is the reason to have that ... so each new featured should be 
>>described shortly to the community, otherwise keep it in a private 
>>repository
>>    
>>
>
>
>I don't agree with this (and with calling it "hiding"). This is a
>documentation problem. I don't think "document everything or don't add
>new features" is a good ideea. We do accept documentation patches, is
>just not realistical to ask all developers to document each new minor
>feature.
>  
>
I am going to believe that you see only the extremes. We talk about 
important features, which were committed, and nothing about them. Don't 
ask for examples, there were "waves" about some...

How to expect users to contribute to documentation if no announcement of 
new features are made. Also, this features are not added day by day, so 
3 minutes to write a mail should be acceptable.

>  
>
>>- the next steps in develpment should be discussed between the 
>>developers to avoid overlapping and waste of time and to select the best 
>>way to do it
>>    
>>
>
>This depends on what you understand by next steps. I do see the
>potential for interminable discussion.
>  
>
So you will end up discussing all your live :-) If primary needs cannot 
be identified, then it is waste of time.

Daniel

>
>  
>
>>- members should have a fair attitude to the others and try to discuss 
>>each issue is a nice manner (without trying to impose from beginning own 
>>opinion and ideas)
>>
>>This is shortly how we see it. If you agree (improvements are welcome), 
>>then we can move forward together, otherwise we will maintain further 
>>our code from SER as well as openser.
>>
>>    
>>
>
>
>Andrei
>
>  
>