kicad-developers team mailing list archive
Mailing list archive
Re: Concerns about clearing disagreements before committing.
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.
On 21/11/2011 12:42 p.m., AndreyAF wrote:
> IMHO, you overly harsh in his statements and actions in relation to
> Vladimir. He began to do a great and necessary work, in which need is
> lasts long.
> On rework of internal representation of the coordinates have said
> repeatedly in KiCad-team. But when found a developer who took the time
> and effort to make this work - it instead of help and support
> immediately get a rap on the knuckles. For the leader kicad-team (as I
> understand, you think yourself so), this approach is not entirely
> correct. There should be constructive criticism, not voluntarism.