[And once more with 'reply to all' instead. Wouldn't it be nice if gmail had an 'auto-reply-to-all' feature...] On Sat, May 17, 2008 at 2:02 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > A cursory browsing is enough only when you trust the contributor well. > For example, I read patches from Nico to code around the pack generation > only once or at most twice before I apply them, and the same thing can be > said about git-svn patches from or acked-by Eric. These come mostly from > the fact that (1) I know they know the area a lot better than myself do, > and more importantly that (2) I know they care deeply about the subsystem > they are modifying, and they have good taste. This makes sense, patches only get a 'cursory browsing' when they come from a trusted author, which is defined mostly by how active and how 'good' they are in the area they modify. > Project maintainers and old timers become familiar with habits, strengths > and weaknesses of known contributors over time, and that is the source of > such trust. This could only partially be done by an algorithm, while git excels in the 'over time' part, the definition of 'habits, strengths and weaknesses' is harder to make. > A clever enough automated way may be able to identify links between the > contributors and the areas they are familiar with, and using such a > mechanism people might be able to decide that a patch falls into category > (1) above. I am not sure if any automated way could ever decide if a > patch falls into category (2) above, though. Yes, your solution in determining patches from (1) is in the same direction of what I have been thinking on myself. I don't think it is possible to determine (2) without having access to the review system (in git's case, the mailing list). When the review system would become part of the analysis it could provide information on what improvements had to be made to a commit before it was accepted. If 'style improvements' would be marked in such a system then people with 'good taste' are people whose commits do not often need 'style improvements'. Alas, implementing something like that would be beyond the scope of 1 GSoC. Ah well, 't is a nice dream about to implement at a later time perhaps. (Although such would be more suited in a team collaboration suite than in a [D]VCS). -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
