On 06/16/05 18:51, Andrei Pelinescu-Onciul wrote:
On Jun 15, 2005 at 22:42, Daniel-Constantin Mierla daniel@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