Hello, On Jun 11, 2011, at 19:08 , Ludovic Rousseau wrote: > 2011/6/7 Martin Paljak <mar...@martinpaljak.net> >> >> Hello, >> On Jun 7, 2011, at 11:48 , Ludovic Rousseau wrote: >> >>> Hello, >>> >>> My first git contribution [1] :-) >>> " Fix compiler warning >>> >>> Declare the function static to fix: >>> pkcs15-lib.c:1069: warning: no previous prototype for >>> 'sc_pkcs15init_encode_prvkey_content' " >>> >>> What is the preferred way to submit patches? >>> - reference them on github or another public git server (as I just did) >>> - attach them in the email (easier for review) >>> - both >> >> I would say either link or link + patches. Or only patches if there's >> nowhere to link. But eventually it would be necessary to pull the changes >> from somewhere, either by cherry-picking or from a branch (preferred) or >> from mail attachments (would be nice to avoid if possible). Adding the patch >> files to the e-mail would probably be good as well (if/when github.com would >> go down or lose history or changes URL layout etc). Mailing list archive is >> one of the most valuable assets of a project communication medium, IMHO. >> >> As github allows to comment on patches and pull requests to single line >> granularity, having a link to some "gitweb" style location would be >> preferred. > > OK. So what should I do now with my patch? > > It looks like the "official" repository is still svn on opensc-project.org. > Should I commit my git patch on svn?
There was not much feedback on the "transition plan". I thus guess that seems to be fine for most people? I got interrupted on Friday from my planned activities on OpenSC (somehow all interrupts from The Wife seem to be non-maskable interrupts with Extremely High Priority...), so will continue on Monday where I left.. The plan would thus be: - halt commits to SVN trunk which are not necessary to fix any last minute issues with 0.12.2 (please test the latest revision, available through nightly builds as binary or a targzip) - release 0.12.2 from SVN trunk ASAP (first day(s) of the upcoming week) - freeze SVN and make it read-only after that. - continue with Git I hereby encourage people to clone my Git repository [0] (which is in sync with SVN trunk) and start hacking ASAP. Already set up are builders for two people: Ludovic [1] and Peter [2] (OpenPGP) which publish to opensc-project.org [3] [4], as I know they have Git repositories to build/pull from. Right now both build from "master" branches but eventually dedicated branches should be created by both persons, for example named like "to-be-merged". As the main theme of Peter's work seems to be OpenPGP, the name for the thread could as well be "openpgp". This of course is not fixed and the simplest step would be a "to be merged" branch for every active developer, until if/when dedicated feature branches seem reasonable. But the branches to be built should be more long-living than a branch used to implement a single small feature (which is of course a good practice, but that branch should be *separate* from the "feature branch" or "to-be-merged" branch against what the automatic builders and tarball generator will work. In fact, there could be separate branches for "to-be-built" and "to-be-merg ed", communication about the "readiness" of code (and thus pulling by others) in the "to-be-merged" branch is still up to every developer and the history of a single "to be built" branch can be rewritten if needed, as it is not supposed to be pulled from. It will only be pulled if called "frozen" by the author, after what the branch should stay constant until next release and consecutive rebase from blessed master [5] Viktor and Andre and Juan Antonio (DNIe) are persons who come to mind as people needing builders as well, but there are no known Git repositories at the moment. In parallel issues such as properly setting up the "master master" on opensc-project.org, setting up the commits mailing list integration etc can be done, and the workflow with Git practiced. As said, any of the "to be merged" branches is in fact a candidate for the next blessed master, but the goal is to make sure they all can be merged into master in a single go. Splitting up your own work into reasonable units is encouraged, so that the portions that actually shall be merged for the next master can be selected as needed. That's why I suggest to maintain a difference between "generic fixups" and "failsafe improvements" from "major features" - so that they could be pulled independently. I thus suggest to leave the minor fix to Git for future seed, or commit it to SVN if you feel it is important. Move it to a separate branch "tobemerged" and/or "compilerwarnings" branch. Your "tobemerged" branch would be built instead of the master and published to opensc-project.org (unless you have other preferences or proposals). Also put the PCSC pinpad PIN length commits to "tobemerged" branch. [0] https://github.com/martinpaljak/OpenSC [1] http://martinpaljak.net:8888/view/Ludovic/ [2] http://martinpaljak.net:8888/view/Peter/ [3] http://www.opensc-project.org/downloads/nightly/ludovic/ [4] http://www.opensc-project.org/downloads/nightly/peter/ [5] http://whygitisbetterthanx.com/#any-workflow 2nd option -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
