kicad-developers team mailing list archive
Mailing list archive
Re: Concerns about clearing disagreements before committing.
On 11/21/2011 02:39 PM, hauptmech wrote:
> I've been rubbed the wrong way by Dick before, but in this case I was
> surprised at his initial effort to handle this nicely and openly. Dick
> I think if you could count to ten before replying and make them all like
> that, you'd have a lot more eager to pitch in. Even between two native
> speakers, dealing with this sort of thing is difficult to do over email
> without understanding. Apart from Dick loosing his cool a few times
> later on, I think Dick and the rest of the core are doing a good job in
> trying to handle this.
> While I appreciate the need for code format standards, using them as a
> basis of criticism come across as petty (to me anyway). Perhaps a better
> way is to keep the formatting standards front and center in the
> developer community FAQ and code base. Then simply repeat to newcomers
> that the KiCad way is to adhere strictly to the standards, make it a
> requirement for patches & commits, and most importantly, continue to
> offer help with checking and correcting new code for adherence.
> Nonconforming patches (and commits) can be dropped into a bug report,
> along with any notes, if the committer doesn't have time to do the
> correction himself, and it gets fixed by the community.
> Finally, rather than going through kicad oligarchy, vladimir always has
> the option of forking and starting his own little kingdom as he
> mentioned. I hope he doesn't. Kicad needs the help. I'm not sure how
> the core team organizes themselves but the repository mainline should
> never anyone committing their own code.
what made this situation a little different is that:
1) The changes had been discussed and it was obvious that there was resistance to the
strategy put forth by Vladimir before. But rather than trying to reach agreement, he
simply started committing code. In contrast, often new work has not been discussed
before, and is never subjected to pre-existing resistance. We know there was more than
one way to implement this feature, since it is a moderately large change. Nobody was
against the feature, just how to best do it, was under discussion.
2) The strategy adopted by Vladimir was extremely invasive, changing more files than
necessary. My first alarm bell went off when I saw changes to specctra_export.cpp, and we
suddenly had code like this:
doubledx =scale( TO_LEGACY_LU( aPad->m_Size.x ) ) /2.0;
The purpose of scale() was to scale, so now we are scaling the input to scale() before
scale() gets to scale.
Number 2) simply means that the discussion needs to be completed, and the senior
developers need to reach agreement with the strategy. During such a discussion phase, one
would hope that compromise and and movements of opinions would arise, along with the best
solution. One rarely reaches the best solution until one has explored more than one solution.
Protecting the source code integrity is one of the jobs of the project leadership. Linus
has full control over his tree, nobody commits to it other than him. That is where his
power comes from. Exclusion. But then he pulls into that tree from trusted
contributors. That trust is based on personality traits of the trusted, previous
discussions, and friendships.
In the case of Brian Buldulock, he already has a fork. What he wants is a team. In fact,
he wants to be a team leader.
"Team building" is not a personality trait that everyone has. Even being a good team
member is not easy for some people.
KiCad is more than a project. It is a team. And this team has been built by establishing
things like procedures, coding standards, repositories, mailing lists, and team member
identification and *encouragement* .
There are 3 kinds of open source project broadly:
1) Single person
2) Team with volunteers
3) Team with corporate sponsorship.
I suggest that getting from 1) to 2) is probably more difficult than most people think. I
suggest that anyone thinking of doing this, should first find a salesman and team builder.
If everyone could simply contribute to the source code, then you'd end up with alphabet
soup, and some of the developers like me, would then leave. I don't want to look at
alphabet soup. I will argue strongly that one reason KiCad has garnered more attention
lately is that the source code is now readable. Wayne Stambaugh and I lead this effort.
Jean-Pierre came around. Wayne has been relentless in making the code readable. It has
to be readable before it can be re-architected.
In 2008, I was the largest contributor to KiCad's source code. Since then, I have been
contributing in other ways, such as planning, designing and team building. SoftPLC
Corporation has been a corporate sponsor of this work, which has not been insignificant.
The source code to KiCad is not perfect, so one should not be so naive as to think that
because we defend the source code that we like it. We defend it to keep it from getting
worse, while we try and make it better.
All the while we try and find folks that we want to work with. And this is the key
thing. The pay is low, so to avoid making the act of team membership painful, one has to
factor in how we can get the personalities on board who make it fun and productive. This
means to be a trusted team member, you go through a phase where you listen and cooperate
more. Then later once it is clear that you are not a bull in a china shop, you gain
trust. Then you even become a leader yourself. Wayne is a perfect example of that. I'd
be happy to let him lead the whole project. But he came in and was respectful, and still
is respectful. That respect earns you respect.
You gain respect by being respectful.
In accordance with YOUR point about publishing the coding standards, just two days ago I
put a link to them in a FAQ.
I am happy that Vladimir is now having the conversation with Jean-Pierre. I just hope
that Jean-Pierre is not so exasperated at this point that he will not participate. This
is the state that I am in, exasperated, and since I have trust and respect in Jean-Pierre,
I am happy to have him work with Vladimir to find the proper solution.
However, I would not be certain that this is going to happen. And I would be supportive
of Jean-Pierre if he decided to simply code this feature himself. Everyone has limits to
their patience: Vladimir, Jean-Pierre, me, Wayne, Brian, everyone.
This is free software, but our time is not free. And it is difficult to direct volunteer
efforts. Therein lies part of the problem.