On 3/23/2012 11:48 AM, Martin Paljak wrote:
> Hello,
>
> On Fri, Mar 23, 2012 at 15:17, "Magosányi, Árpád"<m4g...@gmail.com> wrote:
>> 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.
>
> True.
>
> 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.
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.
SM - I don't have any cards that can use this, others may.
ePass2300 - GOOZE was willing to sending them out to developers, I don't
know how many may have them, and if they do have they voted?
It worked for me and I voted +1. (I think I voted.)
ECDH/C_Derive - One needs a smart card that can do ECC key derivation.
I have some test cards and some demo cards from NIST that can do this,
The NIST people were using the mods for testing with thunderbird,
so there are at least 2 of us.
What this means is that you are not going to get many votes because
in some cases only the author can test the code. A +1 from the author
may be the most you will get!
Many can compile and verify code does not cause other problems,
but I suspect most developers will wait for the next pre release
before doing and testing at all. That what has happened in the past.
>
>
>> 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).
>
> But a bi-weekly "recap" would be good idea to have.
>
>
> Best,
> Martin
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
