Le 17/02/2012 17:52, Peter Stuge a écrit : > Jean-Michel Pouré - GOOZE wrote: >> * 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.
Nobody doubts that review in critical. But what shall we do now, how can we 'move forward', if the review/acceptance process is stopped at the Gerrit level and the only person that is capable and has authority to do something is absent for a long time already ? ... >> * 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. I agree, compilation farm is extremely useful. But it has to be adapted/configured in accordance with the available human and other resources. There has to be no definitive obstacle for 'moving forward', otherwise this 'compilation farm' stuff loose it's sense of being. > >> 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. Probably you have a reason -- 'whitespace', 'commit messages', 'undoes unrelated changes', ... But from my point of view: - commit history do not needs to be perfect for the new driver, before it's commited into one of the official branches; - personally, I'm ready to correct myself the limited number of the coding style ot other issues when merging newbie commits, but to not make the 'ping-pong' last for ages; - historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' . (It's the module approach, that Nikos Mavrogiannopoulos talking about in his mail in this thread.) Certainly, the 'newbies' have to be 'educated' in the 'right' direction, but the process could not be so rigorous and finally to not block the 'moving forward'. ... > //Peter Kind regards, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
