Jean-Michel Pouré - GOOZE wrote: > > Until newbies can demonstrate that they have learned the right things > > they are by definition not moving forward. > > Come-on, we are not in a class-room or in an administration.
We are also not in a democracy. We are in a security related open source project. > We all agree that Gerrit is the solution. So let's make it work and > open accounts for recognized developers to make sure simple patches > are committed. Everyone can register an account, which then allows to push commits into Gerrit, and to comment on and perform +1/-1 review of other commits. An OpenID is neccessary. If someone does not have an OpenID and would like me to provide one, feel free to send me your prefered username, md5(yourpassword) and your full name and email address, and I will create an identity for you on my OpenID provider. You then add two <meta> tags to any web page that you control, and the URL of that web page is your OpenID identifier. Note that many sites such as SourceForge, Google, Yahoo, etc. already have OpenID providers, so if you have an account there you can look around to find your OpenID identifier, which you then use to register with Gerrit. > If this is not done within a reasonable time frame, I will create a > Charity under French law open to everyone and we will have elections. Create as many charities as you like, I don't think it will make any difference. Working on code is unrelated to holding elections. I suggest that those who want to contribute to OpenSC start flooding Gerrit with perfect patches that are so obviously perfect and that are approved by so many contributors that they require nearly zero attention from Martin and Ludovic, and thus can be submitted (again, the Gerrit term for including in the main repo) very quickly. The only alternative to that is IMO for those who want to do development with a different goal and/or a different method than Martin and Ludovic to create a fork. Actually this is already what happens when using Git. Every repository is already a fork. Forking isn't neccessarily bad, but keep in mind that you will have to work very hard to be able to replace the de-facto standard. It will be significantly easier to focus on working with the existing project, on the terms of the existing project. Whenever a fork is created, it is important to decide right at the start what the purpose will be. If the purpose is to get changes back into the original codebase then it is obviously critical to follow the procedures and practises of that codebase, otherwise the effort will be wasted, since the forked codebase is unmergeable. Maybe someone wants to spend time fixing it up. This is very painful, and a complete waste of time. The alternative is to go full steam ahead and decide to never look back. Only with this attitude does it really make sense to fork. You already indicated that you don't really want to fork, so I guess your choice is made. This is all politics. Let's disregard the politics. That leaves code. It is impossible to argue against a perfect patch. //Peter
pgpB0rSN7Du1v.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
