Le 19/02/2012 11:23, Peter Stuge a écrit : > Viktor Tarasov wrote: >> 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 ? > I suggest to iterate over proposed patches until they are perfect.
Iterate with who? There is nobody on the other side of the wire. For months the only person that is capable to do/answer something is absent. > That way, those who can submit commits in Gerrit (this is the Gerrit > term for including a commit into the main repository) will need to > spend close to zero time on doing so. Their job becomes so easy that > it is a no-op. Then it also gets done quickly and frequently. This > must be the goal. I'm completely agree with you, and admire the beauty of your abstract considerations, but what have we do here & now, in our current situation -- Jenkins is dead, Gerrit is in mute coma. ... >> - 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; > This is a trade-off. It's fine to do this once or twice for a new > developer. It's however quite hopeless when the developer whose work > you review consistently makes the same mistakes that you have > corrected and possibly even pointed out several times before. It is a > waste of time for humans to do such work. Believe me, I have other interesting things to do. But for months I'm looking the way to help to 'move OpenSC forward' and but had no answers -- there is no activity on the other side. Decision to pull the ECDH, the ePass2003 into SM branch is my isolated desperate attempt to 'move forward'. > Static analysis of commits, > e.g. using checkpatch.pl from Linux possibly with som modifications, > can and must be automated. Gerrit is the perfect place to do it. Please, come back to earth -- Gerrit is not actually functional. >> - historically, afais, driver authors where relatively free in >> coding style, implementation particularities, etc. in the part >> that concerns it's 'own space' . > I find this problematic since it leads to low reusability. Even just > visual style differences are not really helpful. A uniform codebase > is more coherent and easier to deal with for everyone involved. The > coding style rules do not have to be very many, but having project > wide rules is a good thing. Completely on you side. But that's the current state of art. To change something we need more resources. >> 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'. > Until newbies can demonstrate that they have learned the right things > they are by definition not 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
