Hello, One of the often mentioned benefits of open source software is "many eyes see the code, thus it is more secure/neat/better than closed source". Well, I'm personally not sure this is generally the case. At least in OpenSC, the approach has been a "kitchen sink" style for as long as I remember, with occasional retrospective actions/corrections.
I don't think that the current small team could actually set up and "enforce" a code review process, but it would be nice to make the code actually flow through different people (not necessarily "reviewers") I've tried to map the "fields of interest" or "areas of maintenance" in OpenSC wiki for every current commiter [1] (not all of them are actually active), what I hope could make a base for the "feature branch" maintainers. This is where Git could help to "enforce" that code travels through at least two people before ending up in master. I'm not trying to assert that those people actually engage in active reviewing/improving activity, but it probably increases the chance of this happening and individual diffs improving along the way. I also created a picture to accompany this process [2]. Don't be frightened by the apparent complexity of the picture, the normal workflow for newcomers would still be the same: write code, create a patch and some "core developer" will deal with it (commit/merge). This is how I envision the process of collecting patches from familiar developers and random commiters would end up as a published release: - Basically there are people who write some kind of code (or documentation or whatever). Could be "active developers" (like current SVN commiters list) or anyone who decides to fork OpenSC (benefits of Git) and publish the changes. Github has excellent tutorials for people new to Git (even people new to any kind of version control) - New code can also come from the miling list (or Trac) in the form of individual patch files, if the contributor decides not to use Git for some reason, just as they come now. This is picked up by an active developer, or maybe even by several. - Every active core developer has his own tree he develops in. Could be hosted anywhere, but must be pullable. Github should be a preferred channel. Different columns represent different trees (users) in Github. - The important part: "feature branches" as I explained in a previous e-mail, something that group a set of interesting and related tidbits that require attention into a meaningful "testable unit" (individual card drivers, installers, PKCS#11, core OpenSC library etc). Working on a feature branch should have as close feeling as working with current SVN trunk: continuous published installers and tarballs, that allow testing the specific branch easily. For some reason I want to distinguish "fixup branches" from "feature branches" even though they should not be treated as *that* different from feature branches. I still envision that generic fixes and small improvements (typos, documentation updates, compiler warnings etc) should be handled somewhat separately. For example, when constructing the NEWS file for a release it would mostly only list the changes/summaries of feature branches. Every feature branch would have a dedicated maintainer, who "oversees and maintains" what is happening in that area or delegates it to someone else. To split OpenSC up into smaller pieces where at least somebody would know reasonably well what is going on in some part of the code and why. - Feature branches and fixup branches are regularly (weekly?) pulled into the "staging" branch, which also has continuous builds. The staging release would be something similar than a release candidate. If merging something to a staging branch fails for some reason, like too interdependent changes, this calls for a change and restructuring and a new try sometimes later. This would make the "staging" branch builds possibly more broken than an individual feature branch (which is based on previous release, which should be "mature enough"). Staging branch is actually a throwaway branch, if things go wrong, it could be totally erased or reverted or whatever. - If a staging branch merge from other branches and resulting builds happen smoothly and resulting binaries work smoothly, a release can be constructed. The release can then be created by pulling the necessary branches directly to the master from feature branches, no feature -> staging -> master path is necessary, as it makes no difference - the changes are the same and the Git commands as well. But this help to guarantee that only reasonably tested code gets merged to master and released. Setting up builders for branches requires some work but is straightforward (I still need to update wiki NightlyBuilds page with Git related changes, but the process is repeatable and simple, taking maybe 10 minutes per branch per platform). Thus from development perspective the whole mumbojumbo would not be that visible. It mostly only complicates release process. But the code bouncing "back and forth" hopefully causes intervention "as it happens" instead of retrospective corrections to the "master branch", as it is with SVN currently Would this make sense? Thoughts, comments, suggestions? [1] http://www.opensc-project.org/opensc/wiki/GetInvolved [2] http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Gitworkflow -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
