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. 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. > 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; Work in progress will always exist. Beta testing of work in progress is good and important, and Git makes this extremely easy. Anyone in the world can publish their work in progress. Proposing a commit for inclusion in the main repo is something quite different. Whenever something is pushed to Gerrit it must indeed be perfect, or it is just some lazy or sloppy developer wasting the time of others. I think we are all busy and want to avoid wasted time. > - 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. 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. > - 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. > 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 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
