Two GCC stories

Posted Jul 5, 2010 13:11 UTC (Mon) by shlomif (guest, #11299)
Parent article: Two GCC stories

One thing I don't understand is: why do the GCC developers have a need to implement a patch review system, when many such FOSS solutions exist. Bugzilla and other bug-trackers can be effectively used to track patches and make sure they are not lost and the KDE people have a similar system for patch tracking in place over at http://reviewboard.kde.org/ (in addition to bugzilla). Why do they find these systems inadequate?

to post comments

Two GCC stories

Posted Jul 5, 2010 14:23 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

Well, GNU encourages all sorts of strange and harmful coding practices. My favorite, which I've written about before: the requirement to omit any sort of useful information from commit messages. http://fuhm.livejournal.com/5850.html

Now, if they had a useful patch review system, that might make it too easy to figure out what a given change did, so, clearly, they can't have that. I mean, you might even be able to easily go backwards from the worthless commit message to an email sent to gcc-patches (which usually *does* include an explanation), and thus divine why the change was made. That would be so clearly a bad idea, I'm not sure why anyone's even thinking about it!

Two GCC stories

Posted Jul 5, 2010 15:23 UTC (Mon) by nye (subscriber, #51576) [Link]

The best/worst part of that is the confusingly incoherent explanations for why some people apparently still think that's a good idea.

It seems to boil down to the following: some people don't want to use a revision control system, so they want the log that it could automatically generate to be manually created by a human. The idea of branching and merging is alien so that fact that this necessitates manual changelog merges is irrelevant. They don't want the actual VCS commit log to have any extra information than could be automatically generated because then the log that they don't want or plan to look at would be different to the manually generated log, which might confuse somebody.

Two GCC stories

Posted Jul 6, 2010 19:29 UTC (Tue) by mlopezibanez (guest, #66088) [Link]

http://gcc.gnu.org/wiki/GCC_Patch_Tracking

Bugzilla is useless to track patches: 1) Submitters would need to manually add patches to bugzilla, this won't accepted by most GCC developers, who submit patches via email, or by infrequent contributors, who do not want to create a bugzilla account 2) Reviewers will not check bugzilla for patches to review, in fact, patches in bugzilla but not sent to gcc-patches are often ignored forever 3) There is not easy/simple way to list unreviewed patches 4) Bugzilla cannot track approved/rejected status by email. Perhaps one could make bugzilla overcome the above limitations, but nobody has done it, so proposals of what GCC devs could do without offering to do it are a bit useless.

GCC developers may be willing to add a keyword to an email to say that a patch is accepted, rejected or committed, but they will not login to a website. Most GCC reviewers will not even look at the website. So reviewboard (and all patch trackers I know about) is out.

The patch tracker developed by Daniel Berlin was the closest thing to this, and even in that case was fairly underused because it was only useful for listing unreviewed patches by non-persistent contributors, and most reviewers won't look to a website for patches to review. They already have a lot of patches to review, so patches from people that don't have enough interest to follow-up their own submissions are not a critical concern.

I think the GCC project could benefit enormously from a patch tracker that could be operated from mail, IRC and web, that allowed grouping patches by maintenance area and status, that kept a history of past patches, that build and tested patches automatically and reported failures to the original submitter, that could generate automatic pings for unreviewed patches (every 15 days or more), that tracked email conversations about a patch (patchwork does this already), that enabled to submit patches via web, that checked the existence of categories markers, correct Changelog, correct GNU style formatting, ...

Of course, this is a dream that no one has made true so far.

Right now, the only solution is to encourage submitters to ping patches from time to time, and ensure that their approved patches have also been committed.

Two GCC stories

Posted Jul 8, 2010 13:00 UTC (Thu) by ariveira (guest, #57833) [Link] (1 responses)

Or https://patchwork.kernel.org/ used by some linux mantainers.

Two GCC stories

Posted Jul 13, 2010 1:58 UTC (Tue) by mlopezibanez (guest, #66088) [Link]

There is

http://patchwork.ozlabs.org/project/gcc/list/

but it is still useless because of the reasons mentioned above, specially, it requires login to work with the patch tracker and it cannot track approved/committed patches (automatically or by email keywords). So no one is using it as far as I know. It will probably grow up indefinitely until the owner of the site decides to just take it down.