Many thanks for coming back on topic for OpenSC! :) Jean-Michel Pouré - GOOZE wrote: > In bazar development, we should agree to release unperfect code in > one "unstable" branch and let the community fix it.
I don't oppose having stable and unstable development processes per se. But usually it's not so meaningful for the smaller projects. > One reason is the limited time of reviewers. You write "we will not work > for you". We noticed, thanks and this is NOT a problem. Well, it is a problem if you (I don't mean you personally or your company, I mean everyone other than active developers) want a change in the code. There are of course many ways to encourage someone else to help, ranging from simply asking nicely to some form of payment. > This is where the process should evolve to take the notion of > limited resources into account and give the community at large > more power and freedom. The alternative, which is *always* available, and which comes with no risk for any party, is for those with interest in some changes to the code to generate it themselves. Of course, in order to avoid risk, it is important to work closely with the project community, so that there is no duplicated effort and so that the final result can be commited quickly. > I am worried that OpenSC GIT development is too scattered. It looks > like: Scooby-Doo, Where Are You! Nice reference hehe! :) Distributed development is IMO a feature, not a bug. As long as all parties consciously work together, having many git repositories and branches is not a problem at all. Linux is the textbook example and since they have very high standards for commits it is even easy for users to take advantage of the quite powerful features in git and combine multiple different branches into one. It's actually quite impressive how well this works with the Linux kernel. > In Scooby-Doo, whenever there is a challenge, the team decides to > split and look for the monster. Then when a monster shows up, the > character is alone to fix it and receives no help. Fortunately two git branches are only a command away, so when we find monsters we could quickly gather the entire gang and fight the monster together if this is what we want. > In other words: too many branches => No review Why, specifically? I can only think of a few reasons: * Because reviewers are overwhelmed by the number of changes to review. This would be no better if all changes were happening in one and the same place. Probably it would be worse, since all changes were mixed together, making targeted testing of specific features more messy. * Because reviewers can not find the changes to review. This can easily be remedied by gathering all repositories and branches in a single location, which is something I believe strongly in. Why does fewer branches mean more review? I would instead argue that lack of individual commit quality is what stifles review. The better a patch is the easier it is to review. For reviewers it starts with the commit message. The way to make a commit really easy to review is to write a commit message which educates the reviewers about the change, including some background for the relevant code and the process for making the decisions made during the change. The education is especially important if there aren't many other developers familiar with the code. Writing good commit messages and in particular writing education material requires a quite different skillset than writing code. This problem is inherent with peer review if peers are distributed in location and experience, like on the internet. > Unless patches are committed to GIT unstable branch very quickly, > let's say in days, there will be no testing/review of patches. Huh? Review happens before commits enter the staging branch, not the other way around. > So I would be in favor of letting main developers commit their > changes to ONE SINGLE git staging branch directly and let > developers/users fix the code. It's an interesting idea, but it places a significantly higher workload on the developers if there is more than one active at any given time, since instead of each person having to juggle only their own changes, everyone has to juggle everyone's changes. > Anyway, let's give some time to Gerrit to see if we are still in > the "Scooby-Doo, Where Are You!" situation. The key really is review, not testing. If you can help with review (or influence someone else to do so) that is incredibly valuable for any project! > If this does not work, Let's see if we get there. Thanks! //Peter
pgpbrXjOHKO6s.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
