On Mar 15, 2010, at 16:51 , Andreas Jellinghaus wrote: > Am Montag 15 März 2010 14:26:53 schrieb Martin Paljak: >> On Mar 14, 2010, at 16:25 , Andreas Jellinghaus wrote: >>> So please have a look at attached diff. If there are no objects, I would >>> like to apply it. Further improvement can then be made by everyone. >> >> If posting a patch (especially one that goes through every single source >> file) to the list in the first place, giving it more than 48hours of >> replying time would be sensible. In fact, three days would be even better. >> Less than 24 hours (16.27 yesterday -> 14.19 today in my e-mail client) is >> not OK. > > martin, why are you so negative about everything? I did a lot of the things > you proposed, and as result you still only complain. I tend to get defensive when things where I consider myself the sole maintainer (like esteid code) get touched, which this patch did. Even though it probably did not change any functionality, I still care about what's going on. I like to think that this is for a reason.
> maintaining large patches is a pain. for example the simple change > from viktor (this morning or so) needed a manual merge. thus it is > preferable to merge such things fast, to avoid the need for many > manual merges. Yes, software development is pain. Debugging is annoying. Lack of documentation is bad. >> I noted it down in the DevelopmentPolicy wiki page. > > thats not how it works. we discuss development policy, and after we have > a consensus, we can write that down in a wiki page, reflecting it. not > the other way round. Such things don't create themselves out of the blue sky. 3 days is a minimal functioning grace period that also takes into account weekends. The fact that sometimes you get near-realtime responses from mailing lists does not mean that it actually reaches even 20% of the subscribers (i.e. they at least read the subject or even the body of the e-mail if they find it interesting) in one day. As discussed before, the feedback loop of opensc-devel e-mail list can be quite long (see when people have replied to the opensc-porject(.org) re-organization thread), people have real lives, families and jobs as well. If you find 3 days period too long so that the patch can rot, or slip through peoples e-mail reader cracks, add it to trac instead. (And the rest in that wiki page is the same old page, edited to remove outdated or useless text and added minimal good style suggestions to justify some of the edits and deletions I did/will do) >> Not everybody read e-mail on Sunday evening or deal with incoming list >> e-mails first thing on monday morning. > > I didn't expect everyone to read it so fast, thats why I wrote, that it could > be reverted as well. still I think it is easy o have it commited, than let > it rot. If you send a patch to the list with the intent of getting feedback and somebody actually takes the time to look into the (huge) patch .... then why just send it to dev null? I'd be super happy if somebody reviewed my code and give (IMHO) practical feedback. Otherwise commit your code and send a link to the list that "did this, go on re-do if you want". Don't bother sending an e-mail asking for somebody to view the patch. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
