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.
Martin is not the only person who you can talk to about code. Try asking the mailing list, and if that fails it is always possible to do self-review and iterate locally. > > 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. Jenkins may have a problem, but Gerrit looks like it is functioning fine, at least now. It is trying to merge commits which have been pushed, reviewed and submitted for merge, but where the commits have been pushed with dependencies, and where the dependencies have not yet been reviewed and submitted for merge. Here is where perfect patches make all the difference. The dependency looks wrong, and if there was no dependency, the commit would already have been included in the repository. Granted, Gerrit was introduced recently and will take a little getting used to, for people to learn the ins and outs. But in the end it is an incredibly helpful tool. > Believe me, I have other interesting things to do. Yes, I believe you. :) > 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. I think everyone is on the same side. > Decision to pull the ECDH, the ePass2003 into SM branch is my > isolated desperate attempt to 'move forward'. :) Well, maybe nothing desperate is neccessary. Ludovic can submit commits in Gerrit to the main repository, so work on making the commits in Gerrit trivial for him to submit. I believe he will do it quickly. One very nice thing about Gerrit is that anyone can push an improved version of anyone else's work. In order to not make a mess, it is important to preserve the Change-Id inside the commit message, but everything else can change, both the rest of the commit message and the contents and the history of the commit. So for example: https://www.opensc-project.org/codereview/#change,7 has status Submitted, Merge Pending Ludovic has approved and submitted this change. Gerrit tries to include it, but a dependency is missing. Change 7 has one dependency: https://www.opensc-project.org/codereview/#change,6 which has been verified by Jenkins, but not reviewed and submitted by Ludovic. This change has no further dependencies. There are two ways to move forward on change 7: 1. Ludovic can review and submit change 6 for merge, which will then also make change 7 get included in the repository. 2. Anyone with a Gerrit account can fetch the commit in change 7 according to the download instructions, and cherry-pick it onto a new branch of the main repository, and then push that branch to Gerrit. This will make the change no longer have a dependency. Dependencies are created when a branch with several commits is pushed to Gerrit. Gerrit prefers that any branch being pushed is strictly for logically related commits. Gerrit prefers very many different branches, rather than only few. Fortunately, branches are fast and easy with git! After someone has done 2. above Ludovic will have to review and submit the updated change 7 for merge. So it seems more efficient to convince Ludovic to review and submit change 6, and then change 7 will automatically go in right after it. Repeat for all open and later added :) changes. > > 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. It looks good to me? https://www.opensc-project.org/codereview/ I've just registered and signed in. It works for Ludovic as well, and I'm sure he will submit commits as long as they need no further work. I don't really see a problem. > >> - 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. Yes of course. And perhaps it is not highest priority to work on style cleanup. On the other hand, doing that might be a way for everyone to contribute very simple changes and get comfortable with the tools, and trivial things like how to create nice looking commit messages and so on, the technicalities. Remember to install the Gerrit commit-hook locally in all clones of the repository, so that a Change-Id is generated locally when you commit. Avoid pushing anything to Gerrit which doesn't have a Change-Id, in order to reduce issues you may have if and when you start reworking either a patch you yourself created, or a patch from someone else. If no commit-hook is installed locally, Gerrit will generate a Change-Id on push. If two different versions of the same commit are pushed, Gerrit will generate two distinct Change-Id, and thus they will appear to be different changes, when in fact they are only different versions of one and the same change. Running the commit-hook locally avoids this problem, because the Change-Id is only generated the first time that the commit is created. The commit-hook will not replace an existing Change-Id. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
