Can you set up standard ports so it passes firewalls? First choice: http / https Second choice: git/ssh
On Thu, Dec 8, 2011 at 9:32 PM, Martin Paljak <mar...@martinpaljak.net> wrote: > Hello, > > Here is an overview of updates to opensc-project.org plumbing and Git. > > * Jenkins (build master) has been moved to opensc-project.org. > opensc-project.org will move soonish (probably during the Christmas > time) to a new bare metal home. This allows to run the builders close > together on a decent machine. I'm thus consolidating all bits and pieces > that are needed for running the site onto a single filesystem image for > easy syncing before the IP address change. The new URL for Jenkins is: > > https://www.opensc-project.org:8888/ > > * Gerrit code review has been set up to manage the construction of the > staging branch. All patches sent to Gerrit get automatically built and > verified by Jenkins (currently on Linux only, unfortunately). Commits > that don't build shall get Verified = - 1 automatically and should not > be processed further. Gerrit uses OpenID for authentication (google.com > has one, as do many other websites) thus no new passwords needed. Gerrit > is accessible on: > > https://www.opensc-project.org:8881/ > > Go and log in/register, the existing list shall be included in the > "submitters" group. > > * Github.com pull requests are automagically sent to Gerrit (polled > every 5 minutes). This is a convenience method to get pull requests to a > central location [1] [2], direct pushing to Gerrit's refs/for/staging > should be preferred. > > * Because of Gerrit, the majority of Git plumbing is kept on > opensc-project.org site. Github integration script makes sure that > master and staging branches are available on github.com/OpenSC/OpenSC > while picking up pull requests from Github. Github is thus acting more > or less like off-site backup of source code. > > * Signing of OpenSC source releases > I'm planning to sign the next release of OpenSC with GnuPG. OpenPGP v2.0 > cards or the GPF CryptoStick token (supported by OpenSC to some extent) > are currently the "best" RSA hardware readily available, supporting up > to 4096bit keys. After some tweaking it is possible to use it with > Thunderbird/PKCS#11 but co-operation (and initialization with OpenSC) > requires some further work. > > * Removing password logins from opensc-project.org ? > By relying on OpenID and SSH keys, opensc-project.org would be a much > "safer place" as there are no secrets to guard on the site (except for > internal passwords for databases etc) and it is also easier on users, as > there are less things to remember. > > > == Moving master forward, AKA how to create staging == > > Preparing the next master, please keep in mind: > - the idea is to keep development separate from releasing, so to say. > - to have meaningful changes with enough review and documentation go > into the master release history. > - git rebase --interactive can do miracles on development trees > - commit messages are supposed to be meaningful. There is some ideas > and links on DevelopmentPolicy wiki page. > - have topic branches. Seriously. Many. > > I fed Viktor's secure-messaging branch in whole to Gerrit (and thus also > Jenkins for building), and the reason why development must be separated > from change proposals to master is obvious: > > https://www.opensc-project.org:8888/job/Gerrit_tarball_test/buildTimeTrend > > (or the unverified changes in Gerrit > https://www.opensc-project.org:8881/#q,status:open,n,00199205000000cf) > > Red parts of the graphic are commits that result in a stage where the > tree does not build on Linux. Windows and OS X might probably be even > more different (I'm working on getting Gerrit changes to be built and > verified by default on Windows and OS X as well). While merging the tree > in whole would result in a buildable state, it is not meaningful to have > intermediate commits which are not meaningful enough or even put the > tree in unstable state. > > git rebase --interactive / git commit --amend is the preferred method of > fixing such issues. The NightlyBuilds machinery (meaning "a tree per > developer") is supposed to help by providing access to all released > platforms to all developers in a convenient way in terms of > building/packaging changes for testing. But the branch to be built is > not even supposed to be be the main development branch. > > What I suggest: > > Have: > master (master branch, from opensc-project.org, ff-only updates to this) > staging (staging branch, from opensc-project.org, used to send patches > to Gerrit and to rebase against staging on opensc-project.org. Used to > build pre-releases) > nightly (fed to Jenkins for building. reset/rebased/deleted as needed by > a person. Constructed by merging topic branches as needed for > distributing changes and testing building against the infrastructure) > topic-a (to help separate a logical change and to help communicate it to > others) > topic-b (ditto) > topic-c (ditto) > > > More tomorrow. > > > [1] http://zbowling.github.com/blog/2011/11/25/github/ > [2] http://v3.sk/~lkundrak/blog/entries/github-ribbons.html > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
