Am 30.10.2015 um 18:53 schrieb Jeffery Ciesielski: > As a contributor (with no stake in maintenance at the moment), it was > rather discouraging to go through 14 rounds of code review, have +2 on a > couple of different occasions, but to not have my support patches merged > for the xmc4xxx flash driver. (They're still bitrotting after 9 months > as someone found a few bugs, and I've not had the time to bring it back > up to speed with master). > > I love the rigor, but hate having to nag (I feel rude doing so as this > is a volunteer venture). Relaxing requirements or bringing in a few > more volunteers who can merge flash drivers would be a welcome change. > I still absolutely 100% agree with having review on them, but the worst > thing that happens if I introduce a bug with a flash driver I'm going to > use is that it'll be an immediate irritation to me, and I'll probably > fix it as a result :).
While I agree with what Jeff says, it is fair to add that there are also dozens of valuable patches in Gerrit where contributors haven't bothered to respond to review comments with even a second patch set. In most cases that'll not be the reviewers' fault. Gerrit makes it quite easy to supply new revisions, compared to Linux mailing lists. In some other cases a bit more constructive review feedback might have helped guide contributors to an acceptable patch. It's much more helpful to be told how to do things than how not to do them. In Jeff's case, part of the reason for those 14+ revisions has been that all new NOR flash drivers collide due to being added to the bottom of the variable list and of the array (psoc4, jtagspi, ...). Is there any particular need to maintain this historical order, or would maintainers accept a patch reordering the nor drivers alphabetically? Then xmc4000 would no longer collide with niiet and samv, for example. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ------------------------------------------------------------------------------ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
