Jan Nieuwenhuizen <[email protected]> writes: > David Kastrup writes: > >> We would still need to _track_ patches. A mailing list is just an >> unorganized dumping ground. > > What exactly do you mean by that, and why can't we do it like linux > kernel does it? > > As I understand it, the submitter keeps reworking and re-posting > until they get a sign-off and someone puts it in.
More likely until they give up, given our current work force. > If the submitter loses interest in the patch, is that a problem? It is a problem if he can't get anybody else interested. > Nothing keeps us from creating an issue in the tracker, > adding a link to the mailing list with the latest patch. Sure, but if we do that, having a web interface specializing on the patch management, which is what we hope Gerrit to be capable of, will make things easier. > Of course, it would be nice if submitters got lots of positive > feeback, but I fail to see how a web tool helps with that. Mostly we at least keep track. > And, of course, you being the main developer right now, if you > like the current tools and procedures, that's cool [of course > you saw Graham's review results and take learning and discouragement > of git-cl/rietvelt etc into account]. Rietveld sucks because it is a mismatch to git workflows, not because it is a web interface. That's why taking a look at more git-focused review tools makes sense. Dropping the review tools altogether is not feasible: we have a whole crew working through it and keeping organized, Bug Squad, testers and Patchy operators, Patch meister and so on. Those provide important non-programmer infrastructure helping us to keep our programmers focused. "Patches floating on a list" won't do the same for us. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
