On 06/09/2011 09:24 PM, Martin Paljak wrote: > 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)
'in fact any of those "forks" could become the "master" for the next release.' This is going to be very confusing for outside contributors. I would instead suggest having a canonical central repository. Although git can operate in a fully distributed setup, having a central repo is for HUMANS so that they actually understand what is going on. Github has a concept called "organization" for hosting projects where several people have access. With such setup, you could move all the opensc related projects (opensc, libp11, openct etc.) to github's OpenSC organization, and give access to several people for merging patches and forks. -- Kalev _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
