Le 17/11/2006, "Sylvain Beucler" <[EMAIL PROTECTED]> a écrit:
>On Thu, Nov 16, 2006 at 03:20:40PM +0100, Mathieu Roy wrote: >> Le Mercredi 15 Novembre 2006 21:56, Sylvain Beucler a écrit : >> > Hi, >> > >> > More than once I and Mathieu have disagreed on what to implement in >> > Savane and how to do so. This usually led to discussions that did not >> > reach a consensus and took lots of time. >> > >> > I would like to avoid feeling completely constrained by the thought of >> > such discussions and refusals whenever I think about improving Savane, >> > hence I'd like to start a branch where ideas will be implemented and >> > tried so as to be later discussed on solid ground, and rules reduced >> > to minimum. >> > >> > I think it would be appropriate to place it in the Savane repository, >> > given that we still share a lot in common about free software >> > philosophy and web design, although I wouldn't mind storing code >> > somewhere else if need be. >> > >> > Is it ok? >> >> No. > >Ok. >I'm taking a break off Savane then. > >I did read your answer and wrote some lengthy answer, but people just >end up throwing nastities at each other in such cases, so here's a >short answer instead. > >Main points are that I think you sound too much unflexible (you know, >"must", "no go", etc. - flawed English heh?) One thing: I hate arguing on no basis. If someone have a complain, then it is a waste of time to make general statements instead of going to the point. Criticizing with general statements is just too easy - gratuitous And frankly, I believe you are unfair. You absolutely wanted the ability for a user to have a fixed feedback box? I frankly thought that useless, but I even wrote that option for you. I could come up with tons of examples like that. I think you do not realize fully what inflexible would mean. But I sincerely hope that the most inflexibles guys you'll meet in your life are like me, just unflexible on a set of rules like "post an item when you create a branch". > even if maybe you're not; >that our relationship wrt justifications is not symetrical (I have to >justify to you what I do, but not the other way around); and I am >pretty disappointed to have learnt about you working full-time on >Savane only the day you started. No ones has to justify the choices he makes as long as he stick to the tiny set of rules. Tobias wrote alone the whole markup thing, we just discussed on the markup style. I trust people to do the right thing when they code. As long as they respect the simple set of rule, I think they deserve this trust. It is as simple as that. I did not object to your commits about the way it was implemented. Also, I believe that someones that come up with something that works and that has been made according to the tiny set of rules have rock solid arguments to get his thing merged into the trunk. I'd like to remind that I never refused, as of today, contributions. >Oh yeah, and I do hate using corporate-style policies when there's 1.5 >people working on the project but that's only a tiny part of the >point. To me it is helpful to know what is going on - checking all commits is frankly not something I like to do. I do not think it is too much to ask. I think this is very necessary on a project with developers that do not meet regularly around a coffee table. You said in this mail that you feel there's no symetry: well, I do respect the rules. All important moves that could raise questions (implementation of spam checks and whatever) have a related opened task where I usually tell that what is my plan. This is not just for the pleasure of using Savane (yes, because I also feel a good developer benefits a lot by using his tool - that's another reason - I think a very valid reason, in regard of the necessity to deliver a good piece of software), not just as a reminder for myself. It is also a way for someone interested to learn what I intend to do and to, if he wants, suggest changes or to oppose. If you read https://gna.org/task/?2874 you'll see an example of what I consider to be a good discussion. Brainstorming, etc. And I do not think it oppressed Tobias. And it did not prevent him to completely decide on the way to implement the markup (with internal functions that work line by line, that I've only read afterwards when doing final fixes - I think his approach was very sensible). If you read https://gna.org/task/?3787 you'll see an example of what I consider to be an explanatory plan. Finally, if you check https://gna.org/task/?3633 you wont be surprised that I'm at CERN when there is a release "that will contain improvements made at CERN after release 1.6 [aka 2.0]" due to be made before December the 1st. (with high priority, I do not think we can consider this item to be hidden) This is all a storm in glasswater ("une tempête dans un verre d'eau" - no clue how to translate that properly). You are welcome back if you understand that this rule of rules are no big deal and that they can be convenient to follow what is going on. Rules are not by essence oppressive, they just lead the path to collaborative work. Humans have not found anything better to avoid and to resolves conflicts. So please, dont make a fuss of this, our time would be better spent of Savane code. Mathieu Roy _______________________________________________ Savane-dev mailing list Savane-dev@gna.org https://mail.gna.org/listinfo/savane-dev
