On Tue, Dec 29, 2009 at 06:40:31PM +0100, Aurelien Jarno wrote: > On Tue, Dec 29, 2009 at 07:23:28PM +0200, Michael S. Tsirkin wrote: > > On Sun, Dec 27, 2009 at 05:01:38PM -0600, Anthony Liguori wrote: > > > Likewise, if you see a patch go in that you think would have benefited > > > from being on the list, point it out. > > > > How *would* I see it? I guess I could write scripts that correlated git > > logs (or qemu commit list if it is ever resurrected) with mailing list > > archive. If patch is not there, look in mailing list around the time > > for a hint: could have explanation in the discussion. Or maybe it is > > part of a series someone pushed ... you get the point. > > > > All those commit have a single Signed-of-by: line. That decreases the > number of patches to take. > > Anyway I still don't really understand you are trying to achieve here, > and without pointing to real problems, I am not sure we are going to > understand.
What would you call real problems? - You listed complains 3 times as an issue for committers. Is this a problem worth solving? I think my suggestions will help solve it. - Even codewise: it's not uncommon for commit X to revert commit Y by another person, at least partially. I can point them out privately, prefer not to do it publically. This hurts git bisect and generally makes following history harder. Unavoidable but seems less common with reviewed patches. > The life of committers is not really easy, and the patch submitters do > not really help to improve it: > - a lot of patches are only reviewed by the committers, not so many > persons send Acked-by: mails. > - you have to deal with code you don't understand > - you have to track continuously respined series (with patches moving > from one to another, being merged or changing title) > - you get complains when you review a patch > - you get complains when you don't review a patch fast enough > - you get complains after you applied a patch > - etc... Most complaints are result of somewhat opaque nature of the commit process. For example, people would complain "where's my patch" often to be said: it is applied, not yet pushed. Sending mail "applied thanks" would solve this. I am suggesting making it more transparent and reduce number of complaints. Thus life of committers will become easier :). > This is not always fun. If you want to add more strict rules to the > committers without reasons, you will just get the contrary effect and > slow down the development process. Yes we do not want a "process", but what I am suggesting is not a process, is it? Just being open about what's going on. -- MST
