On Tue, Nov 23, 2010 at 7:10 AM, Julia Lawall <[email protected]> wrote: > > No. I don't want the responsibility of the commits having to make sense.
I can't resist commenting haphazardly on this :) Often a repository starts as a personal whiteboard or scratch pad where the important parts are: - If I screw up, I want to be able to reclaim an older version so I can get back on track agian. - If my harddisk takes a trip to the graveyard, the repository acts as a safety and backup. - I have multiple places I develop and this is the easy way to push between machines. The other use of a repository is what I call "software archeology": - Who made this change and why? - I have a regression. Which commit introduces it? - I want to track changes by other parties and review them. Notice the vast difference from the personal repository. Finally there are the social aspects: - We are several people and need to coordinate changes. - We need to ease the integration of patches for foreigners to the project. - We need quality assurance and to control what parts of the code is production ready and what is not. With CVS or Subversion it tend to be the case that if you have neglected one or several of these paths, access to the repository is usually not worth it, I find. There is little value in having a stream of quick or empty commit messages to peruse (i.e., it was the personal scratch pad). > I don't see any use of my development style serving as entertainment for > others. The git repository is only there because people asked for it. Git is interesting because it supports the individual style rather than obstruct it. You can have your own local branches you don't share with the world, and on those you can do whatever you want. When you publish you tend to take a series of patches and squash them into a single commit you then publish to others. In that respect, other people essentially get to work on what is published in the git repository at the moment: stable baselines on which you can be sure the code will compile and work. I do quite a lot of work on Erlang these days and the Erlang/OTP team at ericsson tend to drop some quite heavy commits from time to time (about once every 7-14 days). But you can always get a fairly recent stable tree to work with and know it will not deviate too much. Hence I am not stepping on their toes and they not on mine. Nobody are obstructed. End of Advertising :) > The only use for it that I can see is if someone wants to add some > fairly independent feature on their own, eg support for another language. My take is that the coccinelle team needs to look out for the situation where somebody forks the project and begin providing patches. There is a "github effect" which happen on some projects: as soon as they are present on github, contributions start to flow. The reason is that the barrier to entry is considerably lowered. There are two approaches, any of which works, but it may be beneficial to take a stance early on: - Let someone from the coccinelle team integrate the patches back into the main repository. There is some added responsibility tied into this, granted. But you can often queue up patches and take them all at once. - State that it is up to somebody else to do the maintenance since you don't have time. Essentially you might get a volunteer who is willing to do the work of maintaining the integration, while still controlling the flow in from the Coccinelle team at the same time. Communication with this volunteer has to occur or otherwise it gets near impossible to do. // Adding the second language can have from almost none to far reaching impact on the code base. If the C-specific parts are leaking deeply into the guts of the extended model checking algorithm or smPL for instance, the first series of commits will have to untangle this before an attack on the new language can begin. Hence, any such change will have an impact on the correctness and stability of the existing code base. If there is modularity however, the changes can work almost independently of the main code. It is worth keeping in mind should one come by, wanting to add another language to the system. I am probably not alone in wanting an Erlang-frontend, but being functional with a dynamic typing discipline may be too much at first. And even just getting the isomorphism on an Erlang parser/unparser pair is a considerable project by itself. -- J. _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
