Re: [opensc-devel] GetInvolved wiki page
On 06/05/2012 09:38 AM, Ludovic Rousseau wrote: Hello, [...] 3- the idea is to start gerrit with a new clean copy of what is on github The problem now is to find manpower (and expertise) to implement point 3. I have taken a look into it. It seems simple at first sight. Basically you just need to clone the repository to the host gerrit is running on, add write access for gerrit and configure gerrit.basePath using gerrit's config file. see http://gerrit.googlecode.com/svn/documentation/2.0/install.html#create_git_repository_base If you trust me with an access, I can do it, even if it turns out it is not _that_ simple. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] patch base in gerrit
Hi! We have the following symptoms: - some modifications come as a set of patches. Gerrit lets you review a patch a time. - sometimes it is not even clear what are really the changes - sometimes approved patches fail to apply It would be nice if - all patches in gerrit would be shown as relative to a common base - this base would be the currently approved head Is there a way to achieve this? Another nice feature would be to automatically normalize submissions wrt whitespaces. It is a pity that patches should be rejected only because some misplaced spaces, while there are tools out there to automatically reformat code. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] code review question
Would https://www.opensc-project.org/codereview/#/c/263/ also fall to the Commits that obviously should be bundled with some other change category? Half of the changes needed is at https://www.opensc-project.org/codereview/#/c/262/1, and the two or three lines being the main point has been changed between the two patches. And I am still confused by the place of gerrit in the development procedure. Maybe it is rtfm, then please point me to the fm. I see the patch in gerrit, its fate seems to be undecided for me, but the corresponding bug report is fixed as the patch got to staging. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] How the original patch submitter gets the review messages?
I have a little concern about the review procedure. If I go to the point in the code review comment, it will be short and not too encouraging. However the guys submitting the patches do the Right Thing, they are important ones, and some encouragement would be in place. Should I also include some thank you, and your patch is close to acceptable, just, or is it handled by other means? (maybe by some automated mailer enclosing the commit message, or some developer talking tu the submitter?) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/27/2012 03:19 AM, Peter Stuge wrote: Graeme did some rework of the patch, but generally did not seem to agree with the review. The new solution included the addition of new API calls, however without any documentation. As anyone who has looked at the code and doxygen output, libusb is quite well documented, so the lack of documentation was obviously a problem. We are talking about lack of some documentation vs. a serious useability issue. Have you noticed it yet? OpenSSL comes to mind. I am not saying it is perfect, but definitely better than known buggy code. It is the most widely used crypto library despite the fact that its documentation is seriously lacking. Another story is the early days of linux. You might remember: there was the code, and not much documentation, and we were so happy with it. And some guys stepped up and started writing documentation like hell. To reach that point, they needed two things: - functionality to document - functionality they are happy with enough to lend a hand by documenting it At the same time I expect you to understand that unless you or someone else produces a perfect patch according to peer review standards then you must accept that others will work for you in their own time exclusively when they choose to do so. This is a very important aspect to understand about open source software. Open source only works if you take responsibility for every single line of code that you are using. Open source only works if you understand both the technical and management issues. One question in any project is the what is the optimal size of a work unit?. While it is certainly not a question which can be exactly answered, it can be argued that: - it is not good to have work units which do not transform working code from working code - the smaller the work unit size, the better for the one doing it The operational words being working and small here. small is especially important for any crowdsourced effort, because the lower the entry threshold, the more the number of participants. And this is not linear but exponential. It can be argued that a feature and its documentation are two different work units. I recently saw a nice quote from Linus: I'm a big believer in technology over politics. ..in response to a question about Linux patches from Microsoft. Article: http://www.linux-mag.com/id/7439/ I agree with him. It's difficult to argue with perfect patches. However, when patches are anything less than perfect, as they often are, then the responsibility to perfect them lies with the contributor. While a project manager certainly have the authority to decide on what should be accepted, I would strongly suggest you to research the context of this Linus quote a bit more, and read through Cathedral and Bazaar once more a bit more thoroughly. You will find out that leading a succesfull open source project have much more to do with effectively motivate people to do the work than being a good programmer, and sometimes aiming for the perfect code is the slowest way to get good code. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/25/2012 01:14 PM, Peter Stuge wrote: Jean-Michel Pouré - GOOZE wrote: iterative modifications and evolutions. This only happens if the first version of a patch is committed fast and spreads using the Internet. WTF? This goes diametrically against the goal of software quality. Please calm down. Software quality is a complex issue, and sometimes does not work the way one would intuitively think. A good example is this false assumption you were building on. History has shown that the bazaar model is capable to provide quality software, and in a quite wide range of settings it is even more capable than cathedral. We also seen examples of very capable programmers unable to keep up with the bugs in their code, because lack of resources. Think about Hurd for a while. Bazaar shown to be more effective in code quality for a number of reasons: - it is more capable to bring in resources. programmers, reviewers, testers - its turn-around time is much faster; the same patch might get written in a faulty way, tested, fixed and enhanced in the same time while in cathedraal it gots written right at the first shot (but still not enhanced) http://www.catb.org/~esr/writings/homesteading/cathedral-bazaar/ with which I guess you are already familiar with. Moreover: code quality is traditionally defined in a non-functional way. However (at least to me) code quality also have a functional ingredient: how the code functionality fits the users' needs and expectations. We have plenty of proofs that bazaar just cannot be beaten on this one. For an example compare the Linux and FreeBSD user base (though I guess even the FreeBSD project does not count as a cathedral anymore). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] patch quality standards?
On 03/24/2012 09:45 AM, Ludovic Rousseau wrote: Most of your remarks were already in https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Movingmasterforward I added what was missing. Thanks Thank you, I added the link to the CodeReview page. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] removing libltdl?
Could someone tell me what happened with this change in gerrit? I see the messages but do not understand. On 03/24/2012 07:01 PM, Alon Bar-Lev wrote: On Sat, Mar 24, 2012 at 1:19 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Le 24 mars 2012 12:05, Magosányi, Árpád m4g...@gmail.com a écrit : I guess you might want to discuss the pros and cons of removing libltdl dependency. There is a heap of changesets about it in gerrit. I do not remember why libltdl was needed in the first place. Alon, do you know/remember why libltdl was added? Is it related to OpenSC on Mac OS X 10.5 for PowerPC? I found a reference in [1]. Bye, [1] https://www.opensc-project.org/opensc/changeset/53c3c486af54a60e4ea09bdd7ce936a3b538f420/OpenSC Because at that time it was simpler to port to Windows using libtool. As I wrote in the origin post, currently there are almost none libtool usage. In Gentoo tree OpenSC was the last. I don't know any reason why it should be used. I should have removed it long ago. I already fixed the libp11 in similar manner, there I still can commit. Alon. ___ 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
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Simple End User Joe here, A suggestion for all concerned: Please try to forget personal differences, and solve the problem ahead. You are all very bright, you do awesome work, we all endlessly admire you and thank you for all you have achieved so far. But. For me it seems that there IS a problem with development procedures, project structure AND communication. Take a look at your roadmap page. The fact that you are late is okay, this is an open source project after all. But 6 months worth of patches which cannot be reviewed is something which should something be done about. I would need no further support for the request of dropping gerrit or whatsnot than no one actually operates it. Okay, I understand, you are at the top of food chain are concerned with quality. And you simultaneously don't have enough time to review patches. Both are correct and understandable. And there is a way out of this situation. Require assurance of the stuff is working before even taking a look at it: unit tests and/or ack of an established developer, maybe even an end user report confirming the thing is working. Or formal verification with frama-c. Or whatever you read about in CC part 3 or the strike fighter air vehicle coding standards. But if the requirements are met, please take a quick look at it and commit it. And fast. Because if you raise the bar enough, you won't have much junk to sort out and you already have reasonable assurance. And please talk to each other. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Hi, On 03/23/2012 05:48 PM, Martin Paljak wrote: The trick is having a system that works and also helps to achieve the target of having more people *actually* looking at code and some testing (like automatic building) done before even considering ack-ing something. But lagging on processing any flow is of course not really acceptable. Given that resources are low, automation should help. Like Gerrit och Jenkins. Yes, but if you cannot sustain that infrastructure, then it is a stumbling block rather than a help. Maybe it could be solved by enabling more access to it. Or if this is not the way to go, than you can relay on people building and reporting back by hand. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. There is #opensc on freenode, but people on opensc-devel have most of the time to date been against such communication, either because of timezone differences or just because it is very difficult for a handful of otherwise busy people to find that time (I guess). doodle would help on that: http://doodle.com/ But a bi-weekly recap would be good idea to have. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/23/2012 07:10 PM, Peter Stuge wrote: Magosányi, Árpád wrote: 6 months worth of patches which cannot be reviewed This is simply not true. *Anyone* can register on Gerrit and review, and *all* review is a helpful contribution! The problem is not that the code can not be reviewed, but that noone is doing review. Anyone can do it. Nice. I can add some things to that: 1. I'm sure that there are patch owners, who would ask someone to review their patch if this would be communicated to them. 2. Okay, I'm here to review one patch or two if it helps the community. My first question is where can I find the patch reviewing guidelines, including practical usage information on this gerrit thingie, and the guidelines on what is acceptable. And be aware that I am so dumb to programming that I'm doing it in Java, and even that way I'm the only one accepting my patches. But I can compile and test things if it helps, and have a handful of smart cards and tokens at hand. 3. If you would actively seek contributors, you might find someone who can do that with some quality. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/23/2012 09:16 PM, Douglas E. Engert wrote: Another issues with this project is many of the modifications can only be tested by a subset of developers (maybe only one) who have the cards that can use the modification. I am more optimistic than that. If it is made clear that the patch submitter's role to find testers and ask them to ack the patch on gerrit, then it might even happen. In a lot of cases the developer knows some guys with the hardware in question. As an example I am one of the guys who have received an epass from gooze for free. If they would drop me please test this notice, I would even feel obligued to help out. This whole story is mostly about communication. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] gerrit - howto?
I have registered to gerrit, because saying stuff is one thing, doing it is another. I guess I am supposed to verify and/or review. Which is what, and how? I have choosen Change I1e6f787d to experiment with, which is a nice oneliner. Some guy have changed an email address in a comment to his own. I believe reviewing means I should take a look at the patch to ensure that it is up to the standards. Well, I don't know the standards still, but as it is in the same form as the previous, I would think it is. so my verdict here is PASS. Also I believe verifying normally means testing the patch. But in this case maybe verifying the authenticity of the contact change would be the correct way. So I write an email to the old guy, and to the email address in the same source code which is from the same domain, and to some guy I guess is associated with the driver in question. If any one says yes and none says no, then I will push the verify button. Is it what someone supposed to do with this gerrit thingie? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/23/2012 11:10 PM, NdK wrote: I'd do reviews, but the last time I tried to really understand OpenSC's flow, all I got was an headache (a big one...) :( So it's not a will issue, it's more an understandig issue. At least for me. And I'd really like to be able to help, but it seems only a handful of people fully understand code flow... I neither understood a bit about it today morning. What I figured out is here: http://www.opensc-project.org/opensc/wiki/UseGerrit I suggest you to make a gerrit account, try it out, and update the wiki page with your findings. There are patches which easy to comprehend, there are errors which easy to spot, and I believe sometimes stating the fact that we lesser beings cannot correlate the comment with the code helps code quality. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] patch quality standards?
Looking at https://www.opensc-project.org/codereview/#/c/150/ , which is a patch which is overwritten by a later patch in gerrit, I started to wonder again about quality standards. And this: http://lwn.net/Articles/328438/ And there should be others. This is what I have gathered so far: - whitespace problems marked red in gerrit are bad - unchecked null pointers are bad - with a warning cleanup patch state the warnings which had been cleaned up - comment. the comment and the code should be in sync - provide a (description of purpose? man page?) with a command-line program and there is that fighter airplane book, but maybe it is too long and I am a big fan of unit tests if someone else have to do them ;) the same about programming contracts ;) I'm in no position to draw the rules, so I am not creating a wiki page out of this, but I suggest that someone do. It would help the work of code reviewers. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
