Chris Hoess wrote:
> To veer off-course a bit, while improving the ease of code contribution is
> a Good Thing, I'd like to see some additional assurance put in place to
> help make sure contributed code gets reviewed. I've seen a lot of code
> rotting in Bugzilla
Please post bug numbers. Generalities don't get us anywhere. I don't
know many people that spend more time in Bugzilla than I do and I don't
see "a lot of code rotting in Bugzilla".
because the author didn't know about the review
> process, or couldn't get r= when he solicited and gave up, etc., and I'm
> worried that soliciting new contributions may result in a lot of code
> going the same way.
The, soon to be a part of Bugzilla, Request Tracker (partner to the
Patch Manager) will make this more obvious. I suggest, however, that
there are not a lot of patches "rotting in Bugzilla". Feel free to prove
me wrong with a buglist and I'll try to do something about it.
IMO, we should have some sort of periodic sweep
> (like BugDay perhaps, but monthly), wherein people hunt through bugs with
> the "patch" keyword (and attach the keyword, if they hit a bug with an
> attached patch) and ascertain the status of the patch, try to get review
> moving on it, &etc.
I do this regularly. I don't find patches rotting. Perhaps before we
mobilize a gang of people all doing the same Bugzilla queries you can
run a query and post a buglist that points to these problems. It
probably won't take a group of people to get traction on any languishing
patches and I'll be glad to do that task if you can point me to a
buglist. My query skillz are decent but I may have missed one or two,
there certainly aren't more than a few. When people start using Patch
Manager to obsolete old patches and flag patch review statu this query
will become a lot easier.
Mine looks something like this. The "attachment is patch" equal to "1"
gives a lot of false positives so for now you need to do queries like
"attachment data" contains regular espressions like "@@" and "+++" and
whatnot. That gets a pretty good list of bugs with patches but many of
those patches are obsolete or are already getting r= and sr= so you need
to run a second query for bugs where "commment" contains regex
"[Rr]=[a-zA-Z]" or contains regexp "[Ss][Rr]=[a-zA-Z]" or something like
that and then subtract those results from the query that gave you the
list of bugs with patches. You can't just include this as a "not" in the
original query because "comment" does not contain "<string>" actually
looks for bugs where any one of the many comments doesn't contain that
string. This gives most bugs in the database. So you get the list of
bugs with r= and sr= and dump it back into the query page's "exclude"
bugs numbered "<list of bugs>" then put in the parameters for your bug
has a patch query. This gives you a list of bugs with patches and no r=
or sr= comments. Then you can look at bugs in this list which don't have
recent activity and you've got a deceny list of potentially rotting
patches. When you look at this list of potentially rotting patches most
of them are obsolete or were rejected by reviewers. I do a query like
this about once a month, mostly looking for bugs with no r= or with r=
but no sr= and I just don't see very many problems.
--Asa
>
>
