Talk:Requests for comment/Overthrow Bugzilla
"A proper solution would be an inhouse bug tracker (preferrably one written in PHP, as that's what MediaWiki itself is written in). Sadly this requires a lot of researching, programmers and their time" That's okay, that's what the MediaWiki Foundation is for. Leucosticte (talk) 09:41, 28 October 2012 (UTC)
- Or search for another bugtracker? Mantis for example (and it's properly translated into multiple languages!). --Ciencia Al Poder (talk) 20:54, 19 January 2013 (UTC)
- Migration would be a major issue with either approach, though, and potentially more so changing from one preexisting platform to another. Not that it necessarily rules out Mantis or what have you, but it's something that needs to be considered. -— Isarra ༆ 21:24, 19 January 2013 (UTC)
- Why would migration be a major issue? Is it that hard to write a script to convert the data into the proper format ("format" encompassing markup, database schema, etc.)? Leucosticte (talk) 12:41, 4 October 2013 (UTC)
- See http://www.ravenbrook.com/tool/bugzilla-schema/ to check out Bugzilla's database scheme yourself. --AKlapper (WMF) (talk) 13:19, 4 October 2013 (UTC)
- 62 tables. Nice, they've outdone us. Leucosticte (talk) 04:14, 25 February 2014 (UTC)
- See http://www.ravenbrook.com/tool/bugzilla-schema/ to check out Bugzilla's database scheme yourself. --AKlapper (WMF) (talk) 13:19, 4 October 2013 (UTC)
- Why would migration be a major issue? Is it that hard to write a script to convert the data into the proper format ("format" encompassing markup, database schema, etc.)? Leucosticte (talk) 12:41, 4 October 2013 (UTC)
- Migration would be a major issue with either approach, though, and potentially more so changing from one preexisting platform to another. Not that it necessarily rules out Mantis or what have you, but it's something that needs to be considered. -— Isarra ༆ 21:24, 19 January 2013 (UTC)
Exploring Redmine edit
Dan Andreescu set up a Redmine instance on Wikimedia Labs. We haven't configured much yet, but we'll be exploring it as an alternative to some of the existing tools. Superm401 - Talk 02:39, 29 January 2013 (UTC)
Extension edit
What about Extension:IssueTracker; does that look promising at all? I favor using a special page extension. It seems to me that there might be a lot of demand for such a tool in the wikisphere, since wikis are often used side-by-side with issue trackers in code development. It seems to me that we may as well integrate it into the wiki software completely. (I also favor having a Git-compatible code review extension replace Gerrit.)
If we were going to create a new issue tracker from scratch, another question would be, how to store the data? Should be there be a namespace for issues, much as LQT has a namespace for threads? I thought that might be useful for searching or other purposes. Would we want to use LQT for the bug discussions? Leucosticte (talk) 12:41, 4 October 2013 (UTC)
- Refering to Extension:IssueTracker: Where can I get its code? And LQT is dead and unmaintained - Extension:Flow, if at all. --AKlapper (WMF) (talk) 13:22, 4 October 2013 (UTC)
- Some possibly useful/interesting links:
- Leucosticte (talk) 13:43, 4 October 2013 (UTC)
- Thanks, but my question was where to find its code. --AKlapper (WMF) (talk) 07:31, 5 October 2013 (UTC)
- Looking at http://www.youtube.com/watch?v=9MfwsrxDDbM it's very basic. Search is only possible for words, no chance to define any priorities or have some meta information/dependencies between reports. --AKlapper (WMF) (talk) 07:36, 5 October 2013 (UTC)
- It's not at http://code.google.com/p/mediawiki-issue-tracker/source/checkout and accessible via
svn checkout http://mediawiki-issue-tracker.googlecode.com/svn/trunk/ mediawiki-issue-tracker-read-only? (I'm at my non-svn-equipped computer at the moment) So, do you get the impression that it would be better to start from scratch with a brand-new issue tracking extension, or should we adapt IssueTracker to our purposes? Leucosticte (talk) 23:26, 5 October 2013 (UTC)- I get the impression that I'd neither start writing yet another tool from scratch nor adapt IssueTracker, because I don't believe that MediaWiki can be a base for a useful bugtracker implementation. I am happy to be proven wrong though. --AKlapper (WMF) (talk) 10:12, 6 October 2013 (UTC)
- What makes MediaWiki unsuitable for that? I thought pretty much anything could be accomplished using special pages. Whether it's a cost-effective approach is another matter. Leucosticte (talk) 13:50, 6 October 2013 (UTC)
- It's only my belief, so as I wrote I'd love to be proven wrong. :) I just don't see a sufficient number of people willing to also maintain and update the extension code, or (for some basic initial planning) an attempt to create a list of functionality that is a must-have (I don't need feature parity with Bugzilla, but as I wrote above, we currently do use dependencies, the priority field, keywords, or Target Milestone in Bugzilla, to just name a few things). --AKlapper (WMF) (talk) 16:08, 6 October 2013 (UTC)
- Perhaps we can gauge the level of interest by seeing how many people express interest here or offer ideas for the extension. Thus far, it's not too promising, but maybe it hasn't been sufficiently advertised. Leucosticte (talk) 17:07, 6 October 2013 (UTC)
- I hope I'm just pessimistic here, seeing how many Mediawiki extensions do not receive much maintenance. But way more important than interest would be: Who would write the code? --AKlapper (WMF) (talk) 19:09, 6 October 2013 (UTC)
- Perhaps we can gauge the level of interest by seeing how many people express interest here or offer ideas for the extension. Thus far, it's not too promising, but maybe it hasn't been sufficiently advertised. Leucosticte (talk) 17:07, 6 October 2013 (UTC)
- It's only my belief, so as I wrote I'd love to be proven wrong. :) I just don't see a sufficient number of people willing to also maintain and update the extension code, or (for some basic initial planning) an attempt to create a list of functionality that is a must-have (I don't need feature parity with Bugzilla, but as I wrote above, we currently do use dependencies, the priority field, keywords, or Target Milestone in Bugzilla, to just name a few things). --AKlapper (WMF) (talk) 16:08, 6 October 2013 (UTC)
- What makes MediaWiki unsuitable for that? I thought pretty much anything could be accomplished using special pages. Whether it's a cost-effective approach is another matter. Leucosticte (talk) 13:50, 6 October 2013 (UTC)
- I get the impression that I'd neither start writing yet another tool from scratch nor adapt IssueTracker, because I don't believe that MediaWiki can be a base for a useful bugtracker implementation. I am happy to be proven wrong though. --AKlapper (WMF) (talk) 10:12, 6 October 2013 (UTC)
- It's not at http://code.google.com/p/mediawiki-issue-tracker/source/checkout and accessible via
- Looking at http://www.youtube.com/watch?v=9MfwsrxDDbM it's very basic. Search is only possible for words, no chance to define any priorities or have some meta information/dependencies between reports. --AKlapper (WMF) (talk) 07:36, 5 October 2013 (UTC)
- Thanks, but my question was where to find its code. --AKlapper (WMF) (talk) 07:31, 5 October 2013 (UTC)
I could write it, if there are people willing to do code review, sort of like what we did here. I think PureWikiDeletion was the second extension I ever wrote, so my level of coding ability is higher than it was then. However, I haven't done much with special page extensions, so there will be a learning curve.
I took a look at the IssueTracker. It seems like it has potential, with some enhancements. See bugzilla:56079. Leucosticte (talk) 22:48, 6 October 2013 (UTC)
- I think it needs a significant overhaul, mainly to use ContentHandler rather than a custom table. I'd also be willing to put some time into working on it. Legoktm (talk) 18:35, 24 October 2013 (UTC)
- ContentHandler isn't a cure-all. Sometimes a custom table is still better, as it avoids being locked into the page/title model (see AbuseFilter, etc... and also the issues with LQT iirc). Even now that ContentHandler exists my idea for an abstract revision system outside of title/page hasn't gone away. Daniel Friesen (Dantman) (talk) 20:35, 24 October 2013 (UTC)
- It isn't a cure-all, but in this case I think it would be useful. It doesn't work for AF since filters need to be private, and it was implemented way after LQT was designed. Is there a specific reason you think it won't work in this case? Legoktm (talk) 20:54, 24 October 2013 (UTC)
- By LQT I was talking about the strange use of titles for threads, etc... Working is irrelevant. If something doesn't use titles and pages to identify it's entries then it shouldn't use ContentHandler which is based around title-locked pages. And IssueTracker doesn't work by titles, it uses bug ids. Oh, and bugs do need privacy too. We have private security bugs sitting in bugzilla which are private to stop security vulnerabilities from leaking before we release the fix for them. Daniel Friesen (Dantman) (talk) 21:58, 24 October 2013 (UTC)
- Wikibase/Wikidata uses numerical ids for page titles just fine. I forgot about private bugs, I didn't consider that before. Not sure what to do about that... Legoktm (talk) 00:59, 25 October 2013 (UTC)
- Whether it works or not is irrelevant. Representing an AUTO_INCREMENT bug id as a textual page title stored in the page table is the wrong way to do this.
- Also I can think of better urls than
/wiki/Bug:1;) like/bug/1/documentation-is-out-of-date-incomplete-tracking/or something similar. Not sure which of /1/.../ or /1-.../ is better and whether it should be /bug/1-.../ or something more like /bugtracker/bug-1-.../ (to support /bugtracker/search/, /bugtracker/report-1-.../, /bugtracker/list/, /bugtracker/component-mediawiki/, ...) - Daniel Friesen (Dantman) (talk) 01:34, 25 October 2013 (UTC)
- I don't get the idea of putting text into the URL. No matter what text it is, it might change over time I wouldn't like to keep summaries like "Cannt sent mail, plz help!!!!" (in case such a report is actually valid). --AKlapper (WMF) (talk) 14:41, 8 November 2013 (UTC)
- It's a technique used in other systems. The text is actually unused. You could literally change
/bug/1/documentation-is-out-of-date-incomplete-tracking/to/bug/1/lorem-ipsum/and still land on the bug page. The bug id is what is used to identify the bug. The text (who's value in links is determined by the current summary and changes) conveys extra information within the url. It ends up being very useful for various contexts such as C&Ped URLs on mailing lists. Daniel Friesen (Dantman) (talk) 20:05, 8 November 2013 (UTC)
- It's a technique used in other systems. The text is actually unused. You could literally change
- I don't get the idea of putting text into the URL. No matter what text it is, it might change over time I wouldn't like to keep summaries like "Cannt sent mail, plz help!!!!" (in case such a report is actually valid). --AKlapper (WMF) (talk) 14:41, 8 November 2013 (UTC)
- Wikibase/Wikidata uses numerical ids for page titles just fine. I forgot about private bugs, I didn't consider that before. Not sure what to do about that... Legoktm (talk) 00:59, 25 October 2013 (UTC)
- By LQT I was talking about the strange use of titles for threads, etc... Working is irrelevant. If something doesn't use titles and pages to identify it's entries then it shouldn't use ContentHandler which is based around title-locked pages. And IssueTracker doesn't work by titles, it uses bug ids. Oh, and bugs do need privacy too. We have private security bugs sitting in bugzilla which are private to stop security vulnerabilities from leaking before we release the fix for them. Daniel Friesen (Dantman) (talk) 21:58, 24 October 2013 (UTC)
- It isn't a cure-all, but in this case I think it would be useful. It doesn't work for AF since filters need to be private, and it was implemented way after LQT was designed. Is there a specific reason you think it won't work in this case? Legoktm (talk) 20:54, 24 October 2013 (UTC)
- ContentHandler isn't a cure-all. Sometimes a custom table is still better, as it avoids being locked into the page/title model (see AbuseFilter, etc... and also the issues with LQT iirc). Even now that ContentHandler exists my idea for an abstract revision system outside of title/page hasn't gone away. Daniel Friesen (Dantman) (talk) 20:35, 24 October 2013 (UTC)
For the private bugs, maybe use some tool like Extension:NamespaceReadRestrict to keep people from viewing the namespace with the private data? Leucosticte (talk) 02:23, 25 October 2013 (UTC)
- That extension is trivially bypassed. The most well known/mature extension in this area is Extension:Lockdown. However even that isn't completely guaranteed, see Security issues with authorization extensions. We don't guarantee that partially view protected page contents will be completely private as MW is not designed for it. Relying on the page system to keep the contents of security bugs private would be unacceptable. Daniel Friesen (Dantman) (talk) 04:54, 25 October 2013 (UTC)
Search edit
Doing some searching in bugzilla I had a thought... BZ's search is terrible, absolutely horrible. Ignoring the advanced search I think it relies too much on strong text matches, supporting multiple fields simply by testing strings in multiple ones. I have a feeling that any custom bugtracker we could implement could easily have a much more useful search functionality if we used the ElasticSearch engine WMF is going to be switching to for it's wiki search. Daniel Friesen (Dantman) (talk) 14:49, 19 November 2013 (UTC)
bugs.php.net in "See Also" edit
Apparently, Bugzilla has support for bugs.php.net links since 4.4 (cf. https://bugzilla.mozilla.org/show_bug.cgi?id=735196), so this issue should resolve itself once we upgrade and enable extension MoreBugUrl (if it is not enabled by default). --Tim Landscheidt 15:43, 4 February 2014 (UTC)
- True, but we depend on it to be added in core on a new version (which is subject to long delays, an approval process, etc), we're not autonomous on adding more see also domains in case we need to add another domains. Would the MoreBugUrl extension solve this issue? --Ciencia Al Poder (talk) 10:36, 5 February 2014 (UTC)
- Yes, that's what MoreBugUrl is for, and patches are welcome once we run 4.4. :) --AKlapper (WMF) (talk) 11:00, 5 February 2014 (UTC)
Superseded? edit
Chad mentioned that Requests for comment/Phabricator may supersede the Overthrow Bugzilla RfC. Mind if we fold this into that one? Sharihareswara (WMF) (talk) 21:51, 23 April 2014 (UTC)
- I'd highly support that. --AKlapper (WMF) (talk) 06:50, 24 April 2014 (UTC)