Alon Bar-Lev wrote: > Peter, quality is not absolute term. In computing I actually think it is; a high quality program does exactly what it is supposed to do and never anything else.
Computers are very simple machines, so it is feasible for humans to create such programs. > best algorithm > "good enough" > service and responsive to user's issues > > I, personally, for (3), providing a great service and responsiveness > while perfecting the code as 2nd priority (exception are interfaces). > I think this approach was taken at opensc in the past. It doesn't work unless there's lots of feedback from users however. > I also like the (2) approach, while trusting the active core > developers to define what is "good enough", and if someone thinks > otherwise he is free to become core developer or show the code of his > alternatives to the point it is accepted by the core developers. Right, the real fun starts when the core developers actually don't agree on anything, or just have different areas of expertise. And pack mentality comes into play if the core developer pack is smaller than the opposition. Ideally the core developer pack is large enough to assimilate and mentor opposition before any conflicts, but personally I prefer to focus on code over trying to educate someone who insists on doing things their own way in any case. > Agree on commits is not something that can become reality as without > someone who can actually DECIDE, there can be non-ending arguments for > each change. The definition of agreement would be that multiple people decide the same thing. > We have this exact issue at OpenVPN project, which also reached a > complete stop as it does not have core developers and clear > responsibility for subsystems. I guess that perfect commits will still be included in the codebase? > Programming is human creative work, there can be N^^N ways to acquire > a goal, very hard to evaluate what is "correct" or "better" in most of > the cases, it depends on the people involved and the people who > actually review at specific point in time... I'd say that it must only ever depend on the users and never on the developers. But of course you are right in that developers must often try to judge what users want and need. > Same change can be accepted at week X and rejected at week Y as > other people review. Unfortunately yes, when there is not much agreement in the core developer pack. > Because of that trust in the "core developers" of a project is > essential, as it is the only constant factor in the process. But the trust doesn't materialize out of thin air. My point was that trust tends to come (at least for me) when there's also strong agreement. > Not sure what this discussion was, but I wanted to comment your > statement. Thanks for the comment - you make many valid points! It's a very interesting discussion, but of course we're already off topic for opensc since long. :) //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
