Hi folks,
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
Long version: One feature of our old code review system that was a tagging system that made it quick and easy to assign a keyword to a revision at any time. There were a number of uses we had for the system, which are documented here: http://www.mediawiki.org/wiki/Subversion/Code_review/tags
Examples of tags that we miss: scaptrap - this change requires special care at deploy time. It may be that it requires two components to be in sync that aren't generally deployed in sync, or it requires a configuration change, or something else. fixme - this change introduces a bug (weirdly, not in our old documentation - go figure). In Gerrit, this would be a -1 or -2 if the code hasn't been merged yet, but post-merge, there's no uniform way to attach that metadata. backcompat - backwards compatibility breakers.
This has been a frequently requested feature of the upstream Gerrit developers. However, they've been reluctant to implement such a feature until after some unscheduled major architectural work is completed, so we shouldn't hold our breath waiting for that.
With that in mind, we have bug 38239, assigned to Chad: https://bugzilla.wikimedia.org/38239
Chad worked up a hacky version of tagging as a MediaWiki extension earlier this week, which would have kept the tags in MediaWiki instead of Gerrit. That's only one half of what might be an acceptable solution, since the other half would need to be some Javascript in the Gerrit user interface to allow for insertion into the MediaWiki tag database. I discouraged Chad from continuing on this because it seemed to me that it would have been a little *too* hacky. I preferred that if we were going to have our own hacky solution, it should at least be implemented as a Gerrit plugin, so that it would at least stand a chance of becoming a well-integrated solution.
The problem with tagging generally, though, is that it ended up being this weird parallel workflow to other systems. "fixme" was frequently used as a substitute for filing a bug report. "scaptrap" was a substitute for proper deployment notes, and "backcompat" was a solution for proper developer notes. That said, it was lightweight, which meant that it actually got used, as opposed to many "proper" solutions, which are frequently enough work that it's difficult to expect uniform followthrough.
The solution that Chad and I discussed is an addition to the Bugzilla-Gerrit plugin that Christian is already working on. The idea would be that, for any given revision, there would be a "file bug about this revision" link. Following that link would throw to the standard Bugzilla bug filing page, with as many fields prepopulated based on Gerrit context as could sensibly be filled (including, at the very minimum, a link back to the Gerrit rev, but probably also with the assignee set to the developer who introduced the issue, the component set based on the repo).
A Bugzilla-based solution would be an ideal replacement for "fixme", since fixmes are basically bugs anyway. It would work reasonably well for "scaptrap", since they generally imply something that needs to be done prior to deployment. It would be an awkward replacement for "backcompat" and others.
Still, the nice thing about this is that a Bugzilla-based solution is that it's general purpose enough that it may very well find use outside of Wikimedia-land. The BZ-Gerrit work is actually being done as part of a larger issue tracker plugin that the GerritForge folks have written to support Jira. Filing issues based on revisions is likely a common request for people integrating Gerrit with their issue tracking system.
Is a Bugzilla-based solution worthwhile enough for our purposes for a modest (but probably not insignificant) investment in this area, or should we prioritize other Gerrit work higher (say, for example, a native Gerrit tagging plugin)? Assuming we move forward with development, anything we need to consider?
I've put the bulk of this email on mediawiki.org here: http://www.mediawiki.org/wiki/Git/Tagging
We should evolve that page into a spec for the work that Chad and Christian will be doing.
Rob
On 10 March 2013 03:11, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
Interesting idea. I can imagine Bugzilla integration working fine for filing fixmes - not so sure if people would fix them this way either.
I am wondering if it would be an overkill for tags like i18ndeploy or backport - at least there should be easy way to query a list of those kind of bugs.
As far as I understand, the filed bugs would not be displayed in Gerrit side nor could you search with a tag in Gerrit, so there is discoverability problem.
-Niklas
On Sat, 2013-03-09 at 17:11 -0800, Rob Lanphier wrote:
The solution that Chad and I discussed is an addition to the Bugzilla-Gerrit plugin that Christian is already working on. The idea would be that, for any given revision, there would be a "file bug about this revision" link. Following that link would throw to the standard Bugzilla bug filing page, with as many fields prepopulated based on Gerrit context as could sensibly be filled (including, at the very minimum, a link back to the Gerrit rev, but probably also with the assignee set to the developer who introduced the issue, the component set based on the repo).
Are there some thoughts already how to make a match between a project in Gerrit and its related Bugzilla product/component? [Disclaimer: I'm a fan of DOAP metadata files, if used properly.]
Plus I expect many people to not use the same email addresses in Gerrit and Bugzilla (→ setting assignee).
andre
Hi Andre,
On Mon, Mar 11, 2013 at 12:43:44AM +0100, Andre Klapper wrote:
Are there some thoughts already how to make a match between a project in Gerrit and its related Bugzilla product/component? [Disclaimer: I'm a fan of DOAP metadata files, if used properly.]
While DOAP looks great, is there a standard tag to specify component etc for a bug tracker?
I could only find the bug-database tag. But in the examples that I found, bug-database is typically just the url to the project's bug tracker, as for example
<bug-database rdf:resource="http://bugzilla.gnome.org/" />
That looks like being too generic to be useful for us.
However, gerrit already comes with a meta/config ref that already stores the project configuration as plain git configuration. And its publicly visible for our gerrit, so any script can use that. We could just put something like
[bugzilla] product = ComponentA component = ComponentA
in there and pick it up from gerrit's hooks-bugzilla plugin.
Best regards, Christian
On Mon, 2013-03-11 at 17:09 +0100, Christian Aistleitner wrote:
On Mon, Mar 11, 2013 at 12:43:44AM +0100, Andre Klapper wrote:
Are there some thoughts already how to make a match between a project in Gerrit and its related Bugzilla product/component? [Disclaimer: I'm a fan of DOAP metadata files, if used properly.]
While DOAP looks great, is there a standard tag to specify component etc for a bug tracker?
There are no rules how values should look like; guidelines and checks are required. (That's what I meant with "if used properly".) http://bugzilla.wikimedia.org/enter_bug.cgi?product=PRODUCT&component=CO... might work. Plus you could define custom parameters if wanted.
That looks like being too generic to be useful for us.
Yes, it would require strict rules for the URI values, etc. Generic URIs are as unhelpful as empty values.
However, gerrit already comes with a meta/config ref that already stores the project configuration as plain git configuration. And its publicly visible for our gerrit, so any script can use that. We could just put something like
[bugzilla] product = ComponentA component = ComponentA
in there and pick it up from gerrit's hooks-bugzilla plugin.
Wasn't aware of that. Are there projects in Gerrit that don't use bugzilla.wikimedia.org? A lot of MediaWiki extensions, I assume? In that case we're back to the problem that you need a URI value for the bugtracker.
Rest is offtopic and about DOAP only: There are a few things I like about DOAP. One thing is that Apache's DOAP files also include the programming language of a project, so it's easier to redirect new contributors according to their skills. Or to store who is the maintainer of a project (in theory). Or where to find its mailing list, homepage, tarball releases, ... I like that when I want to find out how active a project is or how large its community is, apart from code repository activity only.
andre
On Tue, Mar 12, 2013 at 6:45 AM, Andre Klapper aklapper@wikimedia.org wrote:
Wasn't aware of that. Are there projects in Gerrit that don't use bugzilla.wikimedia.org? A lot of MediaWiki extensions, I assume? In that case we're back to the problem that you need a URI value for the bugtracker.
I'd say the opposite is true--the vast majority of extensions in Gerrit *do use* bugzilla.wm.o. Granted, some may not, so having a tracker uri would also be nice (if not the default).
-Chad
Hi,
On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
I preferred that if we were going to have our own hacky solution, it should at least be implemented as a Gerrit plugin, so that it would at least stand a chance of becoming a well-integrated solution.
A Bugzilla-based solution would be an ideal replacement for "fixme", since fixmes are basically bugs anyway. It would work reasonably well for "scaptrap", since they generally imply something that needs to be done prior to deployment. It would be an awkward replacement for "backcompat" and others.
Thank you for this detailed e-mail. One thing I think I'm missing is why the bugzilla-based solution is better than the gerrit plugin one.
It seems to me that if the tagging functionality was developed as a gerrit plugin, it would have all the advantages of the bugzilla-based solution (good integration, etc.) without its drawbacks (awkwardness for non-bugs tags, e-mail addresses mismatches, dependency on bugzilla).
Admittedly, I'm not a primary user of gerrit, but I've been pondering the idea of using tags in order to surface noteworthy changes, so they can be easily listed and communicated about to our users. This would make it much easier to identify the "most important changes" on pages like https://www.mediawiki.org/wiki/MediaWiki_1.21/wmf7 , and could also perhaps be used for release notes summaries.
A bugzilla-based tagging system seems too restrictive for this kind of use, but perhaps I'm just not seeing how it would work. It's difficult to predict the kinds of tags people will come up with in the future, and I feel it would be a pity to develop a tagging solution that restricts the type of tags you can use with it.
Just my $0.02 data point.
Hello!
<quote name="Guillaume Paumier" date="2013-03-12" time="15:03:04 +0100">
Hi,
On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
I preferred that if we were going to have our own hacky solution, it should at least be implemented as a Gerrit plugin, so that it would at least stand a chance of becoming a well-integrated solution.
A Bugzilla-based solution would be an ideal replacement for "fixme", since fixmes are basically bugs anyway. It would work reasonably well for "scaptrap", since they generally imply something that needs to be done prior to deployment. It would be an awkward replacement for "backcompat" and others.
Thank you for this detailed e-mail. One thing I think I'm missing is why the bugzilla-based solution is better than the gerrit plugin one.
I've been wavering back and forth on this myself, honestly.
It seems to me that if the tagging functionality was developed as a gerrit plugin, it would have all the advantages of the bugzilla-based solution (good integration, etc.) without its drawbacks (awkwardness for non-bugs tags, e-mail addresses mismatches, dependency on bugzilla).
Admittedly, I'm not a primary user of gerrit, but I've been pondering the idea of using tags in order to surface noteworthy changes, so they can be easily listed and communicated about to our users. This would make it much easier to identify the "most important changes" on pages like https://www.mediawiki.org/wiki/MediaWiki_1.21/wmf7 , and could also perhaps be used for release notes summaries.
So, a few things that are related to the above in no specific order:
1) Major changes/issues aren't always associated with just one merge. In this case a bug in BZ would be nice as it is more topical as opposed to tied to a specific merge.
2) Tracking the "most important changes" quality is something I think we need to do better, but I honestly haven't thought of The One Right Way (TM) yet. :) I experimented with keeping track of merges that I thought were interesting via 'starring' them in Gerrit, but the limit there is those stars are tied to my account, not a shared thing (ie: you can't add one to the list without having me do it).
Manually adding them to a wiki page is about as productive as something really unproductive. ;) (I tried that for a bit, too.)
Maybe clicking on a "file bug about this merge" and making that bug block a Release Notes tracking bug is useful? That also seems less efficient than a Gerrit "ReleaseNotes/Scaptrap" tag.
3) I have a personal preference for building light-weight tools first to see if that addresses the need then building more detailed/complex ones later as needed.
4) A Gerrit-based tagging plugin would need some engineering that might not be apparent at first blush, for example: who can set tags and remove them? Does that vary by tag? How could I, for example, keep track of all scaptrap-type things and be sure I don't miss something because someone mistakenly removed the scaptrap tag from a merge and I didn't notice/remember (ie: can I *trust* the tag, both what is there and what isn't, so I don't have to remember everything/double check every week?).
Just my $0.04 (penny per item).
On Wed, Mar 13, 2013 at 2:43 AM, Greg Grossmeier greg@wikimedia.org wrote:
- A Gerrit-based tagging plugin would need some engineering that might
not be apparent at first blush, for example: who can set tags and remove them? Does that vary by tag? How could I, for example, keep track of all scaptrap-type things and be sure I don't miss something because someone mistakenly removed the scaptrap tag from a merge and I didn't notice/remember (ie: can I *trust* the tag, both what is there and what isn't, so I don't have to remember everything/double check every week?).
I don't think we need to be that granular with the tagging permissions, In CR we used to just have it so you needed the Coder right, And i'm not aware of many instances where tagging was abused. You just need to have some sort of "version" of whom added/removed the tags.
Although there were instances where people forgot to tag changes, But that is unavoidable no matter what level(/s) of permissions you have.
On Tue, Mar 12, 2013 at 10:14 AM, K. Peachey p858snake@gmail.com wrote:
On Wed, Mar 13, 2013 at 2:43 AM, Greg Grossmeier greg@wikimedia.org wrote:
- A Gerrit-based tagging plugin would need some engineering that might
not be apparent at first blush, for example: who can set tags and remove them? Does that vary by tag? How could I, for example, keep track of all scaptrap-type things and be sure I don't miss something because someone mistakenly removed the scaptrap tag from a merge and I didn't notice/remember (ie: can I *trust* the tag, both what is there and what isn't, so I don't have to remember everything/double check every week?).
I don't think we need to be that granular with the tagging permissions, In CR we used to just have it so you needed the Coder right, And i'm not aware of many instances where tagging was abused. You just need to have some sort of "version" of whom added/removed the tags.
Although there were instances where people forgot to tag changes, But that is unavoidable no matter what level(/s) of permissions you have.
While I agree that we can model our permissions after what we did with the old SVN/MediaWiki code review system, I'll note that there were some other features that made this more complicated under the hood, such as keeping a history of who tagged what. It's all stuff we've done before in MediaWiki, which is likely part of the reason Chad was tempted to do it there, but doing it in Gerrit may end up being more complicated.
Rob
Doing the tags in Gerrit is the right thing. Who can change them is not a problem, just make a changetags log. (BTW, you would have the same problem in bugzilla with people removing that superimportant tag)
Hi Guillaume,
Good point. Comments below...
On Tue, Mar 12, 2013 at 7:03 AM, Guillaume Paumier gpaumier@wikimedia.org wrote:
On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier robla@wikimedia.org wrote:
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
I preferred that if we were going to have our own hacky solution, it should at least be implemented as a Gerrit plugin, so that it would at least stand a chance of becoming a well-integrated solution.
A Bugzilla-based solution would be an ideal replacement for "fixme", since fixmes are basically bugs anyway. It would work reasonably well for "scaptrap", since they generally imply something that needs to be done prior to deployment. It would be an awkward replacement for "backcompat" and others.
Thank you for this detailed e-mail. One thing I think I'm missing is why the bugzilla-based solution is better than the gerrit plugin one.
The Bugzilla-based solution has some of the advantages of the MediaWiki-based solution. We may be able to implement it more quickly than something native to Gerrit because we're already working on Bugzilla integration, and we get features like queries for free, as well as the minor convenience of not having to have a new database table or two to manage. It may be useful for Chad and/or Christian to weigh in on this point.
Workflow advantages: * We're already managing Bugzilla (Andre is full-time on it), so managing "tags" is straightforward. * We get all sorts of extra management functions, such as assignee with BZ, whereas "fixme"s, for example, only have an implicit, unchangeable assignee (the committer)
It seems to me that if the tagging functionality was developed as a gerrit plugin, it would have all the advantages of the bugzilla-based solution (good integration, etc.) without its drawbacks (awkwardness for non-bugs tags, e-mail addresses mismatches, dependency on bugzilla).
True. They may not be mutually exclusive, but a question of ordering and priority. A BZ-based solution can potentially be our short-term solution, while we still continue to prod upstream on a better long-term solution. We may also still decide that both features are useful enough to implement them both ourselves.
The nice thing about a BZ-based solution is that we will probably still want to keep using it for some things after there's a proper upstream solution. Perhaps we'll also grow attached to a homegrown tagging solution for Gerrit, but it seems less likely we'll want to keep it unless the Gerrit devs never get around to implementing tagging in core.
Admittedly, I'm not a primary user of gerrit, but I've been pondering the idea of using tags in order to surface noteworthy changes, so they can be easily listed and communicated about to our users. This would make it much easier to identify the "most important changes" on pages like https://www.mediawiki.org/wiki/MediaWiki_1.21/wmf7 , and could also perhaps be used for release notes summaries.
A bugzilla-based tagging system seems too restrictive for this kind of use, but perhaps I'm just not seeing how it would work. It's difficult to predict the kinds of tags people will come up with in the future, and I feel it would be a pity to develop a tagging solution that restricts the type of tags you can use with it.
I think we probably just need to be accommodating for more uses of Bugzilla than narrowly using it for bugs only. I think these would be perfectly fine to track in Bugzilla.
If the problem is with the rigidity of keywords, one thing I should note is that, in addition to tagging, there's also the "whiteboard" in Bugzilla, which I believe you can use for free form stuff to query. I believe Andre only enabled that in recent months, so it may be that it wasn't available the last time you went looking, and is a feature we don't yet use for much (or anything?)
Part of why I sent my proposal to the list is because I'm not too wedded to a Bugzilla-based solution. The main things I wanted to check were: 1. Should we tackle Gerrit->Bugzilla bug filing as a higher priority than a Gerrit tagging system? (My original assumption is "yes", but this is the point I'm most malleable on) 2. Is a MediaWiki-based solution with some JS integration to Gerrit acceptable alternative to building a Gerrit-only plugin? (My assumption is "no")
Rob
On Tue, 2013-03-12 at 20:28 -0700, Rob Lanphier wrote:
If the problem is with the rigidity of keywords, one thing I should note is that, in addition to tagging, there's also the "whiteboard" in Bugzilla, which I believe you can use for free form stuff to query. I believe Andre only enabled that in recent months, so it may be that it wasn't available the last time you went looking, and is a feature we don't yet use for much (or anything?)
IIRC the Whiteboard has always been available, just nobody used it. :)
It's free-text format, so if you want to make sure to only find your own entries again I highly recommend using some namespace for your entries.
I use the whiteboard to add "aklapper-moreinfo" entries whenever I would set a "this report needs more info" flag or status in other Bugzillas.
andre
Hi,
On Tue, Mar 12, 2013 at 08:28:25PM -0700, Rob Lanphier wrote:
The Bugzilla-based solution has some of the advantages of the MediaWiki-based solution. We may be able to implement it more quickly than something native to Gerrit because we're already working on Bugzilla integration, and we get features like queries for free, as well as the minor convenience of not having to have a new database table or two to manage.
The problem at this point is that the gerrit-plugin interface is rather new, and that shows at various ends: * It's not possible to add GUI elements from a plugin. * Plugins cannot add their own database tables through gerrit. [...]
So whatever we could possibly get into upstream gerrit, we should really try to get into upstream and not put into the plugin.
But thinking about whether gerrit or bugzilla would be the correct place to store those tags ... It seems to me that the tags are not really tied to issues or changes, but rather to commits... Wouldn't "git notes" be a good match [1]?
They're basically annotations attached to commits. You can add/remove them to any commit without changing the actual commit. And support comes directly with git, as for example in
git log --show-notes
Queries are just a grep away, and setting them can be done through git as well, until we integrate that into gerrit.
Best regards, Christian
P.S.: We already use "git notes". They contain links to code review. But we could add lines like Tag: fixme and have them automatically show when reading the logs.
Can git notes be changed after merge?
Do they show in Gerrit diffs, so we don't accidentally lose them if someone else pushed an amend without the tags?
Can they be removed after merge?
Can one query for commits having a certain tag within a repo/branch/author? (eg. "fixme" commits by me in mw core)
If not on displayed in Gerrit, then from git-cli via a web tool (how does that grep perform, is it fast enough?)
Ofcourse, changing would still go from cli (not w/ the web tool).
-- Krinkle
On 14 mrt. 2013, at 00:07, Christian Aistleitner christian@quelltextlich.at wrote:
Hi,
On Tue, Mar 12, 2013 at 08:28:25PM -0700, Rob Lanphier wrote:
The Bugzilla-based solution has some of the advantages of the MediaWiki-based solution. We may be able to implement it more quickly than something native to Gerrit because we're already working on Bugzilla integration, and we get features like queries for free, as well as the minor convenience of not having to have a new database table or two to manage.
The problem at this point is that the gerrit-plugin interface is rather new, and that shows at various ends:
- It's not possible to add GUI elements from a plugin.
- Plugins cannot add their own database tables through gerrit.
[...]
So whatever we could possibly get into upstream gerrit, we should really try to get into upstream and not put into the plugin.
But thinking about whether gerrit or bugzilla would be the correct place to store those tags ... It seems to me that the tags are not really tied to issues or changes, but rather to commits... Wouldn't "git notes" be a good match [1]?
They're basically annotations attached to commits. You can add/remove them to any commit without changing the actual commit. And support comes directly with git, as for example in
git log --show-notes
Queries are just a grep away, and setting them can be done through git as well, until we integrate that into gerrit.
Best regards, Christian
P.S.: We already use "git notes". They contain links to code review. But we could add lines like Tag: fixme and have them automatically show when reading the logs.
-- ---- quelltextlich e.U. ---- \ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
On Thu, Mar 14, 2013 at 12:27:06AM +0100, Krinkle wrote:
Can git notes be changed after merge?
Yes.
Do they show in Gerrit diffs, so we don't accidentally lose them if someone else pushed an amend without the tags?
No. At least not yet :-)
Can they be removed after merge?
Yes. And they are under revision control themselves. So you can have a look at when a note was added by whom etc.
Can one query for commits having a certain tag within a repo/branch/author? (eg. "fixme" commits by me in mw core)
As there is no native support in gerrit yet to query such objects, querying relies mostly on command line tools. Notes are plain text files stored along the main repository.
As we currently have no fixme tags set in core, but only links to CodeReview, let me rephrase your demo query "fixme" commits by me in mw core to commits by me in mw core linking to CodeReview with a seven in its number .
Given you have fetched core's existing commit notes [1], you could query for that like git log --show-notes --author='Christian Aistleitner' --grep 'Special:Code.*7' . And you'll get [2] as result. Those are my commits to core when it was still on CodeReview and CodeReview number contains a 7.
So how could queries for tags look like when using git notes? Your original query might look like
git log --show-notes --author='Christian Aistleitner' --grep '^ Tag: fixme$'
. Since notes is free-form text, we would probably want to add some '[[:space:]]*', ignore case, etc. But it's up to us to decide upon the rules and decide, how a "correct" tag has to be represented. And we have aliasing in git to save us from typing the same things over and over again.
One caveat (for now) is that we would also catch commits, where the commit message itself (instead of a git note) contains the tag. But that might actually turn out to be a benefit instead of a caveat.
If we want to avoid matching also on the commit message and limit to notes only, we can always checkout refs/notes/commits to have the plain git notes in the file system and do our querying directly on the notes files.
If not on displayed in Gerrit, then from git-cli via a web tool (how does that grep perform, is it fast enough?)
time git log --notes --author='Christian Aistleitner' --grep 'Special:Code.*7' >/dev/null
real 0m0.683s user 0m0.670s sys 0m0.011s
So that's <1s for a plain spinning disk (no SSD) with cold caches grepping the whole history of core. That'd be good enough for me :-)
Although the above timings do not reflect a good real-world sample, as our current git notes in core stem from a single commit. Nevertheless, git has to go through the whole core history, as grep does not limit to notes. So, querying through git history is typically fast. Even for core. And querying through notes is basically doing the same thing.
Best regards, Christian
[1] You can do so by issueing git fetch origin refs/notes/commits:refs/notes/commits . Just like "git clone" it's slow for the first fetch. Follow-up fetches are much, much quicker.
[2] -----8<-----Begin-----8<----- commit b23761744f237c5d9b4b1cabee4f5e76fc819213 Author: Christian Aistleitner qchris@users.mediawiki.org Date: Tue Mar 20 12:00:18 2012 +0000
Follow-up to r114256: Removing final assert
Notes: http://mediawiki.org/wiki/Special:Code/MediaWiki/114257
commit 42c88dc137752e49143627416c585436721f0226 Author: Christian Aistleitner qchris@users.mediawiki.org Date: Mon Mar 19 23:36:48 2012 +0000
Follow up to r114126: Being more conservative for HipHop compiler
Notes: http://mediawiki.org/wiki/Special:Code/MediaWiki/114217 -----8<-----End-----8<-----
On Thu, Mar 14, 2013 at 12:07 AM, Christian Aistleitner christian@quelltextlich.at wrote:
Hi,
On Tue, Mar 12, 2013 at 08:28:25PM -0700, Rob Lanphier wrote:
The Bugzilla-based solution has some of the advantages of the MediaWiki-based solution. We may be able to implement it more quickly than something native to Gerrit because we're already working on Bugzilla integration, and we get features like queries for free, as well as the minor convenience of not having to have a new database table or two to manage.
The problem at this point is that the gerrit-plugin interface is rather new, and that shows at various ends:
- It's not possible to add GUI elements from a plugin.
- Plugins cannot add their own database tables through gerrit.
[...]
So whatever we could possibly get into upstream gerrit, we should really try to get into upstream and not put into the plugin.
But thinking about whether gerrit or bugzilla would be the correct place to store those tags ... It seems to me that the tags are not really tied to issues or changes, but rather to commits... Wouldn't "git notes" be a good match [1]?
+1
rupert
On 14 March 2013 01:07, Christian Aistleitner christian@quelltextlich.at wrote:
Wouldn't "git notes" be a good match [1]?
They're basically annotations attached to commits. You can add/remove them to any commit without changing the actual commit. And support comes directly with git, as for example in
git log --show-notes
Queries are just a grep away, and setting them can be done through git as well, until we integrate that into gerrit.
Except that you need to have the repository cloned locally first.
And often you need to query multiple repositories.
You can work around both of the above... but then we are again on the "more than non-significant effort needed" path.
-Niklas
Hi Niklas,
On Thu, Mar 14, 2013 at 10:54:05AM +0200, Niklas Laxström wrote:
On 14 March 2013 01:07, Christian Aistleitner christian@quelltextlich.at wrote:
Queries are just a grep away, and setting them can be done through git as well, until we integrate that into gerrit.
Except that you need to have the repository cloned locally first.
That's only valid until we integrate git notes somewhere.
And given that other solutions cannot be used /at all/ until we integrate them somewhere, I take your comment as discussion of "how big the 'git notes' benefit is today" instead of whether git notes would be useful :-)
In addition to that, consider that git comes with git notes support for free. No need to code REST apis for scripts to give them access to the information.
No need to fiddle in logging who added/removed which tags, and when this happened. It all comes automatically with git. And we can use our plain git tools like gitk to browse through history of the tags.
Finally, we already export part of the gerrit meta-data through git notes. For example the review meta-data is avalable via refs/notes/review.
So after doing
git fetch origin refs/notes/review:refs/notes/review
in a core checkout,
git log --show-notes=review
shows you who gave what review for which commits, and links to the commits discussion in gerrit.
So why not building further on what we are using already instead of reinventing the wheel once again?
And often you need to query multiple repositories.
Yes, without proper integration in some tool, multi-project queries need something like a three-line script when done straight from git.
But at least we can use it even without integration in some other tool. Other solutions cannot be used at all without integration :-)
Best regards, Christian
Hi,
On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier robla@wikimedia.org wrote:
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
I was wondering: has a decision been made regarding this? I'm resuming work on (notably) identifying/marking "noteworthy" changes, and I'm interested to know if the tagging system is something that we could possibly take advantage of for this (and if so, what a rough timeline would be :).
-- Guillaume Paumier
On 06/05/13 18:12, Guillaume Paumier wrote:
Hi,
On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier robla@wikimedia.org wrote:
Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags.
I was wondering: has a decision been made regarding this? I'm resuming work on (notably) identifying/marking "noteworthy" changes, and I'm interested to know if the tagging system is something that we could possibly take advantage of for this (and if so, what a rough timeline would be :).
-- Guillaume Paumier
IMHO we should go the git notes route, and at the same time pushing that format upstream, so that when it does get integrated into gerrit, it saves the data in the same way (they are also trying to move to store as many things as possible in git, so it's just a matter of agreeing in the notes format).
wikitech-l@lists.wikimedia.org