MariaDB recently announced the migration of the JIRA bug tracking system from the current Atlassian-hosted instance to a self-hosted installation to be found at jira.mariadb.org. This likely isn’t a big deal to the community, and MariaDB is being very proactive in coordinating this change in the community – but it’s an opportunity for me to ask a few questions regarding MariaDB’s JIRA usage to which I can’t find answers. I certainly welcome answers, feedback or clarification from MariaDB staff.
Before getting started, I should say that I appreciate MariaDB – the product, the company, the staff and the foundation. MariaDB/SkySQL/Monty Programs serve a unique and useful purpose for community, users and staff who prefer not to deal with Oracle. I don’t view myself as a critic of MariaDB, and I consider a good number of MariaDB staff my friends. Getting a better understanding of how MariaDB operates the bug system is of interest to me, and perhaps the larger community as well.
Why are some bug reports private?
As of this writing, the Atlassian-hosted MariaDB JIRA instance has 9606 issues in the MDEV project. A small number of these – forty – are not publicly-accessible, and users trying to access them are redirected to the Atlassian Cloud login (UPDATE: Seven of the forty issues originally listed actually redirect to a public issue in a different project, not the login page). Below is a list of these private bug reports (try for yourself):
- MDEV-43
- MDEV-44
- MDEV-66
- MDEV-79
- MDEV-199
- MDEV-426
- MDEV-751
- MDEV-3865
- MDEV-3916
- MDEV-3919
- MDEV-3920
- MDEV-3972
- MDEV-3973
- MDEV-3974
- MDEV-3975
- MDEV-3976
- MDEV-3977
- MDEV-3980
- MDEV-3981
- MDEV-4327
- MDEV-4388
- MDEV-4392
MDEV-4433MDEV-4625MDEV-4828- MDEV-4910
- MDEV-5044
- MDEV-5183
MDEV-5902MDEV-6078MDEV-6267MDEV-6670- MDEV-6692
- MDEV-7573
- MDEV-8037
- MDEV-8465
- MDEV-8467
- MDEV-8711
- MDEV-8802
- MDEV-9210
Forty bugs out of 9600+ bug reports is not a large percentage – less than 0.5% of all bug reports seem to be restricted from public viewing. My initial thought was that these may be security defects, but with some bug reports dating back to 2012, that seems unlikely. It would be nice to understand why some bug reports are restricted, and who has access to them.
Why are some projects private?
This is a much more interesting question for me. I originally understood that all MariaDB development work was tracked in public forums, and with the few exceptions listed above, that seems to be true – at least for the MDEV project. However, it seems that there are at least two other projects that contain many issues which are entirely private. I don’t find any documentation on these queues or their purpose; knowledge of their existence results only from a couple of comments in other forums.
In this email discussion, Jan cites the creation of an issue in the “TODO” project, which is later copied over to the MDEV project to “make it totally public.” The original TODO issue – TODO-776 – requires login to access, as does the entire project. The issue identifier suggests there are at least 775 other issues in this private project (as of January 2016).
The comments and history of MDEV-7595 reveal another private project (“ME”):
| Field | Original Value | New Value |
|---|---|---|
| Key | ME-133 | MDEV-7595 |
| Project | MariaDB Entreprise & Cluster [ 10500 ] | MariaDB Server [ 10000 ] |
This at least clarifies that the ME project supports MariaDB Enterprise & Cluster, and there were 132 issues in that project a year ago when this was first filed.
Unlike the MDEV project, the TODO and ME project issues cannot be browsed without a login.
How many projects/issues are private?
The projects/issues cited above reveal about 1000 private issues / bug reports – a number that’s over 10% of all public bug reports in the MDEV project. Because the only information on these projects comes from accidental disclosure, it’s unclear whether additional private projects may exist, or what the current issue counts are. Are there other projects beyond the TODO and ME projects listed above which are inaccessible to the public?
Who owns MariaDB’s JIRA instance(s)?
I don’t exactly know whether the MariaDB JIRA instance is maintained by the MariaDB Corporation or the MariaDB Foundation. The URL for the new JIRA installation (jira.mariadb.org) suggests this is a Foundation property, but the announcement of the change comes from Rasmus Johansson, who serves the dual roles of Foundation Chairman and VP of Engineering for MariaDB Corporation. The “MariaDB Entreprise & Cluster” project name suggests MariaDB Corporation usage – is that moving to jira.mariadb.org as well?
This question is intertwined with the earlier questions. For example, why should the MariaDB Foundation have access to private bugs or development plans for the MariaDB Corporation? And if it’s the Foundation’s bug reports or development plans which are private, why should MariaDB Corporation staff have special access to such issues? The distinction between the MariaDB Corporation and MariaDB Foundation is important, and the current state of the bugs system causes confusion. If the migration plans will help clarify the distinction in the bugs system, it would be good to articulate this.
Final comments
As I noted earlier, I’m interested in learning more about how MariaDB operates the JIRA instance, particularly as this moves to a self-hosted instance. I welcome any MariaDB policy clarification as it relates to public vs. private issues and JIRA projects and ownership of the JIRA system.
About TODO-776: I made mistake when I created this task, I did not realize that these TODO tasks might not be totally open by default. I do not know why that is true, but issue is now fixed. Contents of the TODO did not change when it was moved as MDEV-9394.
Hi Jan,
Thanks for doing that! In case I wasn’t clear, I appreciate your investment in making the issue public – it just happened to also bring to light the existence of the TODO project which community members such as myself were previously unaware of.
First, did the way you checked these links really work? I’m trying in a browser that’s not logged in, and a lot of listed MDEVs are actually redirects to publicly visible connector issues:
MDEV-6670 redirects to https://mariadb.atlassian.net/browse/CONJ-110
MDEV-6267 redirects to https://mariadb.atlassian.net/browse/CONC-146
MDEV-6078 redirects to https://mariadb.atlassian.net/browse/CONJ-91
MDEV-5902 redirects to https://mariadb.atlassian.net/browse/CONC-147
MDEV-4828 redirects to https://mariadb.atlassian.net/browse/CONJ-59
MDEV-4625 redirects to https://mariadb.atlassian.net/browse/CONJ-43
MDEV-4433 redirects to https://mariadb.atlassian.net/browse/CONC-24
Speaking of MDEVs that are genuinely private: I am responsible for MDEV-6692 which is private because it has links to customer data. The public part of MDEV-6692 is filed as MDEV-6713 in case you’re interested.
I’d leave the coverage of other private issues to their owners.
Thanks for the explanation and correction. I will update my list above to reflect those JIRA issues which redirect to other projects. I first came across issues which redirected to the login page, and wrote a quick Python script to check HTTP header status. I spot-checked the results, where were based on those issues which returned HTTP 302, but as you note, a portion of these 40 issues appears to be redirects to other public issues, rather than redirects to the login page.
Good questions, thanks, Todd!
1. Bug reports are not private. Technically, as far as I remember, Jira supports private bug reports, but we have not enabled this feature. What you see are issues that were mistakenly reported in the MDEV project and later moved to, say, TODO or ME project. Jira keeps old MDEV url to redirect to the new TODO or ME issue, and they, indeed, require a proper log in. All MDEV issues are public.
2. TODO project is about our internal IT stuff. Install that linux on that box, upgrade these packages on that VM, and so on. ME project is about MariaDB Enterprise — customer names might be there, Customer Portal issues, and so on. If a MariaDB Server issue is reported in the wrong project, it is moved to MDEV, as you have seen.
3. There are no private issues in the MDEV project. There are five public projects — MariaDB Server (MDEV), MariaDB Connector/C (CONC), MariaDB Connector/J (CONJ), MariaDB Connector ODBC/(ODBC), MaxScale (MXS). And three private — Internal IT (TODO), MariaDB Enterprise (ME), and another one, also for customer issues.
4. They share it. MariaDB Foundation owns the MDEV (MariaDB Server) project. MariaDB Corporation — other, projects, both public and private ones. As the MDEV project is fully public, MariaDB Corporation can host it in the future, it won’t have any “special access to private MDEV issues” (because there are none). Although — you are right — mixing private and public projects in one Jira instance is confusing and we’re currently discussing that private projects should be moved out of it.
Thanks for the detailed reply, Sergei!
As a practical matter, would MariaDB consider adopting a policy that existing MDEV issues should not be moved to private projects, and instead a child issue in the private project be opened? That would allow community to see what’s going on, and leave no questions or gaps in the public bug records.
Does every single ME issue which triggers a change in MariaDB Server have a corresponding, cleansed MDEV bug report? I’ve not seen ME-### references in change logs. I’m somewhat familiar with the complexities of managing multiple bug systems, and trying to ensure that one public instance gets needed information from private queues, while retaining the firewall protecting against customer information disclosure. It’s great that Kolbe and Jan noticed the issues filed in the private queues and took action to get them into the public system – is there a more systematic process in use at MariaDB to ensure such mistakes are consistently caught? I only stumbled across those two examples.
Thanks also for clarifying joint ownership of the bugs system. I’m glad to hear there are discussions to break apart the Foundation and Corporate JIRA projects. As I understood Monty’s original argument for a Foundation, it serves to protect the interests of the community. That’s hard to do when it shares control of important community resources like the bugs system with a corporate entity. There’s already been public discussion on other key resources which remain under control of the MariaDB Corporation. This includes the trademark, docs, release notes, etc.
No, we cannot fully adopt this policy. Jira is very good at logging all changes to issues, so if some confidential data was entered into a public project issue by mistake — there is no way to remove that, it’ll stay in the issue history. The only two options are — move the issue to a private project, or delete the issue. This policy can be used, though, if the issue is not confidential, but simply irrelevant to the current project. That we can keep public, of course, if irrelevant issues are less confusing than non-sequential MDEV numbers 🙂
Yes, every task that causes server changes, even if it was originated from an ME issue, should have a corresponding MDEV issue. But it’s not something that can be automatically enforced, so mistakes are possible. There is no really a “process” to catch them, but every developer knows the rule, and eventually every issue will be assigned to a developer. So these mistakes are caught.
As for the ownership. I suspect it might be more confusing to have MariaDB Server issues in one Jira instance and Connectors issues in another. Having one shared Jira for all MariaDB Open Source projects would be more useful. Who will run it — is an open question. And private projects do not belong there, I tend to agree with that.