Hello, On Jun 9, 2011, at 16:37 , Andreas Jellinghaus wrote: > some small questions: > what about code review tools/sites like gerrit? Are those usefull for open > source projects? > > maybe those are also easier to use for both submitting patches and merging > those than posting patches to mailing lists or attaching them to tickets?
Gerrit is certainly useful at one point in time but I'm not entirely sure that OpenSC needs it or is ready for this, meaning that it won't start to hinder code inclusion or fade out of the tool usage loop altogether. Adding a new mandatory tool is not the same as adding a tool that helps transparently - like Jenkins builds without requiring any manual/repeated intervention or interaction. There seems to be a general consensus (at least no loud and reasoned objections) on moving to Git, which is nice. This step also facilitates more easy replication of what I've observed that the OpenSC development model seems to be, which is "working on trunk". Which is not bad per se - lets take this model and improve it step by step. By replicating the "trunk" and having several of them, and by providing equal useful services around those "trunks" (like automatic builds, hopefully Debian/RPM packages will also follow shortly), it is not *that* huge paradigm shift IMHO. The team of active people in OpenSC is not enormously huge and the number of more active developers even smaller and changes in time. Being pull-oriented (meaning the set of active "feature branches" can easily change between releases) should also help to keep it reflecting the actual situation, what is relevant and what is not and who has time and interest and who not. The situation I'd like to create is where there are, in fact, several virtual "forks" of OpenSC inside OpenSC project itself (how meta!). Be it a "fork" for every developer (now also called a maintainer) or a "fork" for feature branch. And make it so, that in fact any of those "forks" could become the "master" for the next release. (In fact, I'm thinking about a script which takes a Git commit hash as the argument and "automagically" helps creating the release, meaning doing the boring work of moving right files from nightly builds directories to proper locations, generating checksums etc) But given that it is really easy (or at least relatively easy) to move code between those forks, I assume this will usually not happen. Instead, by trying to set up a workflow where at least two people should "pull" some code before it reaches the next logical master in the ideal case, it will function as a natural double check that a) it is in fact relatively easy to merge a specific patch and b) at least one other person has already looked at a piece of code and either given comments about new code which resulted in those deficiencies being fixed, fixed/improved it itself if needed or pulled verbatim. Adding fun and competition to boring problems never hurts, I guess this is one of the lessons I've learnt from kids :) Also I don't think that submitting patches itself is a problem, nor that patch submission replaces tickets. They are different things, patch submission and problem reporting requires different skills - most patch submitters could also report the problem "correctly" but not vice versa. The only point of mailing list and tickets is history and associated communication - being able to track changes, when, why, by whom they were created. That's why Trac is nice - having the different backlinks... I wish mailing list could be pulled into Trac as well... Instead of requiring the use of a tool that requires stricter procedures, provide means of facilitating improvement "organically" I'm open to alternative proposals with arguments as well, or pointers to obvious flaws in my understandings and assumptions. > also I'd think that anyone doing release management (incl. documentation, > testing, communication etc.) is very welcome, and more releases would be a > good thing? thus "hard rules" could be a problem, if they create restrictions > or too much extra work or unrealistic goals. What kind of "hard rules" ? Yes, people writing documentation are always needed, that includes both user documentation as well as making sure the code remains "live" and documented. -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
