Hello, On Sat, Jul 2, 2011 at 13:39, Kalev Lember <kalevlem...@gmail.com> wrote: > 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.
I guess I did not make myself entirely understandable. There *is* a canonical repository to clone. On opensc-project.org (because there's never enough paranoia, hell knows what happens to Github and when they turn evil) and a synced mirror on Github as well. The "blessed master" for pushing a release is thus on opensc-project.org [1] (this can be changed of course, due to decentralized nature of Git) What I meant by "any of those could become the next master" means the (internal?) workflow of preparing the series of commits to the "blessed master". I created a small doc on how to prepare releases for OpenSC [2]. With the goal of having more "granular releases", instead of dumping code to "trunk" and cutting it off as a release, the purpose of the nightly builds is to provide the similar feeling than it is was with the builds from trunk. Somebody has to deal with code and commit it *somewhere*. Somebody also has to prepare a release, which is still some manual work. Making a release meaning pulling in changes from different people, mostly "active developers". I'd like to encourage people pulling changes from each other, and also doing some review and nagging before that happens (on opensc-devel). Thus for a release to happen, it could happen in many ways: for example, just merging one branch from somewhere and declaring it a release (a branch that can already include code from several other people). Or pulling in different branches at release time and declaring it a release. Thus any branch, that gets tested and eventually merged for next release, will be the "master" (that will be available from the "canonical source", of course) I propose to have a rotating (?) releaser role, for several reasons: - to make sure the process works, is repeatable (documented) and it could be refined by different people along the way - to give the releaser one more chance (read: responsibility) of looking at what gets pulled for released and to draw attention to possible problems - to adjust to availability of attention and time among active developers > 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. OK. I created "OpenSC" organization, to where the OpenSC source is also synced. I would not rush with libp11/openct/engine_pkcs11 etc, until there is actual development in that field. [1] https://www.opensc-project.org/opensc/wiki/SourceCode [2] https://www.opensc-project.org/opensc/wiki/ReleaseHowto _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
