Re: OpenSC write access to main trunk, discussion
Peter Stuge <peter <at> stuge.se>
2012-02-17 16:52:19 GMT
Jean-Michel Pouré - GOOZE wrote:
> > With Git, anyone and everyone is a committer.
>
> The question here is flexibility:
What flexibility is needed? My point is that everyone can easily
create perfect patches, and given perfect patches which have been
peer reviewed there is no need for flexibility as in lots of people
with write access to the main repository. Even just one person can
easily handle that effort, like Linus shows in the much larger
kernel project.
> * OpenSC used to have a very flexible approach. OpenSC is NOT
> kernel.org with thousands of developers and no need for hierarchy.
OpenSC is smaller, but I do not agree that there is no need for any
kind of hierarchy. Now, please understand that this is not about
power hierarchy as in politics, but it is about technical experience
with the code and with the problem domain.
I am personally familiar with the smart card domain but I haven't
spent much time with the OpenSC codebase and therefore I absolutely
do not want some patch I create to be included without being reviewed
first.
The review is criticial. Especially in a codebase like OpenSC, to
which I might indeed delegate my legal authority, I want the review
to be merciless.
Don't make the mistake of believing that only people with write
access can do review. It is quite the opposite. I have been trying
to make this point many times before, but it seems difficult for many
to grasp that all peer review is helpful and important for the
codebase, regardless of who is doing it. Everyone who cares about a
software can and should help with review.
A side effect of doing review is of course that knowledge about the
codebase increases in the community. After having done some amount of
review, people might even get write access, because they have
demonstrated that they can be trusted. This is demonstrated by
finding difficult-to-spot problems in others' patches. It is not
demonstrated by quickly giving every patch a thumbs-up.
Some say that it feels pointless to do review for someone who does
not have write access. I disagree with this, and I think this is a
very dangerous, almost complacent, attitude. If you do not believe
that your review is worth anything to those with write access, why
should you yourself have write access? This becomes a negative spiral
where in the end a project has no resources to do review, simply
because people do not have enough self-esteem to believe that the
review they can contribute matters. I don't know what the answer is.
I've tried time and time again to convince people that doing review
is helpful and important and a significant contribution to any
project, but it often doesn't really stick.
> * Setting-up a compilation farm is no reason for closing write access
> to historical developers of OpenSC.
I agree, but I don't think one has anything to do with the other,
even if they happened at the same time. I guess that anyone who had
write access to the repository earlier can get it again if they just
send a public ssh key and their prefered username.
> * Discussions are the base of Free Software. Once discussions have
> occurred, there should be several people with write access. You
> have to trust people. No need to lock write access to the main GIT.
I disagree about having to trust people out of the blue. Generally,
people write really shitty software, and the poor way that a lot of
open source software works is all the proof we need.
I love open source, not neccessarily because it is technically
superior, but because it allows *me* to fix things which are broken.
I believe that open source is as good as it is primarily thanks to
the practise of peer review.
The purpose of more write access as far as I can see is to have
faster, ie. less well reviewed and thus less well understood, changes
in the main repo. I do not agree at all with that goal.
> From my point of view, OpenSC is becoming a semi-private project
> with two people in charge: Ludovic and Martin. Personally, I don't
> want OpenSC to be organized the same way as libccid.
I find both Martin and Ludovic to be quite reasonable people. I've
never had any problem discussing any issue with them, actually quite
the opposite.
If there are perfect patches (well reviewed, well understood) then I
am convinced that they would race each other to add those patches
into the repository.
I have no experience from libccid development, but I'm happy with it
as a user, so Ludovic must be doing something right.
> We demand more freedom and transparency or this can only lead to
> endless flamewars.
Let's focus on a concrete problem. Have you created a patch which has
been peer reviewed and is well understood, but has been rejected by
Martin and Ludovic? If yes, let's try to find a solution. If no, you
can't really demand more freedom and transparency, because you
haven't exercised the freedom to create perfect patches yet.
I did review the epass2003 commits when their availability was
announced, and I've looked at the entersafe github account
again just now. Here is some feedback:
There are three branches; ePass2003_1, epass2003 and ep2k3. These
names are non-descript.
Commit 902e637c is quite long with over 2k lines added for the card
driver. That seems much to me. It's infeasible for me as careful
programmer but OpenSC internals newbie to review this code. My gut
feeling is that much of the code could be factored out.
The commits are not very well described in the commit messages.
The commits include unrelated changes.
The commits include whitespace changes mixed with actual code
changes.
The following commit undoes some of the unrelated changes in the
previous one.
This is what was immediately obvious to me just by looking at one and
a half commits in one of the branches. The things I point out above
are all things which do not belong in a perfect patch, and do not
beling in the OpenSC codebase that I want to use.
All these things, and probably more!, must be obvious to any other
programmer who has looked at the commits. I do not believe that I
have some special vision and only I can see these things.
It seems to me that the commits have been created without
self-review, which is of course the very first thing to do before
proposing any change for inclusion.
> Keep in mind that before doing business, I have been a politician
> fighting during 4 years for more freedom.
I did not know - that is quite commendable! Thank you for working on
making the world a better place!
Keep in mind that open source is not a democracy.
> Now I am retired, but if need be, we will create a charity for
> OpenSC and organize a duly elected board. I am not talking about
> a fork, which will never happen, but about elections.
But elections do not increase code quality. I think software quality
is more important than flat democracy. The meritocracy that is open
source *is* a hierarchy. I don't think this is bad.
//Peter
RSS Feed