Community Ticket Access now available

After many requests, we are happy to announce we have opened our bug tracker to the community. The HDF Group has used Jira to record bugs, issues, and feature requests for many years, giving ticket numbers (usually HDFFV-#####) out, with no self-service way for users to follow-up on those tickets.

You can now login to our Jira instance and view these tickets. Issues reported via the forum can be found in the public tickets, and we’ll be adding more to the list as we sort through older issues.

Steps to access:

  1. Use your hdfgroup.org login (used to access this forum or download binaries on our website). If you don’t have a login, please register on our site.
  2. Visit jira.hdfgroup.org and login.

Once logged in, you can search and browse issues and vote on issues to let us know what’s important to you. If you’re not familiar with Jira, you might find the system dashboard an interesting place to start. Elena Pourmal (@epourmal) is working on adding more tickets to the public queue and identifying community developers for a higher level of access. If you’re interested in contributing as a developer, please email Elena.

We’re also very close to opening up a browser-based Service Desk for reporting issues, both for our community users as well as our priority and Enterprise Support customers. Stay tuned for that announcement!

Thank you to the community for your patience!

The HDF Group

If you prefer video instructions, this short video will walk you through the steps of registering, logging on in JIRA, and how to start browsing tickets.

Hi HDF Group!

14.11.2018 21:28, The HDF Group пишет:

After many requests, we are happy to announce we have opened our bug
tracker to the community. The HDF Group has used Jira to record bugs,
issues, and feature requests for many years, giving ticket numbers
(usually HDFFV-#####) out, with no self-service way for users to
follow-up on those tickets.

You can now login to our Jira instance and view these tickets. Issues
reported via the forum can be found in the public tickets, and we’ll be
adding more to the list as we sort through older issues.

This was a long-awaited event indeed; thank you for this great contribution!

While looking at some of my previously-reported issues, I noticed that
not all of assigned HDFFV IDs are accessible. For one example,
https://jira.hdfgroup.org/browse/HDFFV-10465
says:

Hi Andrey,

Fixed.

Thank you for reporting!

Elena

I can’t seem to file an issue, nor comment on an existing one. How am I supposed to collaborate/help out with an issue if all I can do is observe it?

Elvis,

We are in the process of opening our Bitbucket and JIRA to the developers who have been collaborating with us for some time and who provided patches in the past. We plan to add the functionality you are looking for in the future.

If you are interested in working with us and have a JIRA issue in mind with which you could help, please let me know. We would gladly accept your help!

Thank you!

Elena

Well I recently found an issue and thought I’d use the newly opened JIRA to file it, but instead had to make it a forum post (see Bug: Library compatibility version differs between CMake and autotools build on macOS).

I consider filing issues and providing information about them part of collaboration just as much as submitting code patches. I was just surprised that the JIRA was essentially read only since the vast majority of open source projects have open issue trackers. See for example Qt, which has a process I think works very well.

As always, thank you for the feedback.

the vast majority of open source projects have open issue trackers. See for example Qt,
which has a process I think works very well.

Can you elaborate a bit more on this example? Specifically, we want to ensure the quality of the information entered into the issue tracker, e.g. no incorrectly reported issues, no issues without a unit test that reproduces the behavior, etc. How do other communities and projects tackle this “intake” process?

Thanks,

  • dave

They tackle the issue with some triage and some basic docs that state the minimum required information for the HDFGroup to investigate a bug. Having even the basic barrier that I have to sign up and get invited just to report a bug isn’t the industry norm for open-source projects. The issue tracker should be public and anybody with an account (GitHub would be the best as that is what the industry has settled on) can put in a bug.

There will always be the bug reports that basically say “It broke when I compiled. Can you fix it”. Not much you can do about those bug reports except have a boilerplate reply asking for the proper amount of information to reproduce the bug. I think the vast majority of hdf5 users are technical enough that they understand what needs to go into a bug report as most of us are developers.

Also, with an understanding of the new HDF5 Group’s business plan, would it be possible to mirror the HDF5 repository (at least the one with the community fixes) up to GitHub? Hiding the sources behind a login isn’t a great idea and does not foster that “open” part of open-source. I see that someone is already mirroring the bitbucket repo (branches, tags and all).

https://github.com/live-clones/hdf5

Also, where is the HDF5 Dashboard located for nightly builds?

I think Mike explained it pretty well in his answer.

What you describe (“no incorrectly reported issues”, “no issues without a unit test”) is a utopia. Fine if you want to put fingers in your ears and pretend these reports don’t exist, but the reality is you’re just going to get those reports through the forum instead, without a proper/systematic way of tracking them.

Like Mike mentioned, there are processes such as bug report templates, written policies, closing with NEEDSINFO etc. to deal with incomplete reports.

Regarding Qt, I just brought it up as a good example of a large open source project which just like HDF5 has a central commercial actor, The Qt Company (KDAB are also big), but also a large community of volunteers, where all help out with development and bug triaging.

A negative effect of a closed bug tracker is that volunteers can’t help you out in triaging bugs, or provide additional information, or even help you out with pinging reporters to fix up their reports.

When I first heard that you were planning to open up the issue tracker some year or two ago, I thought finally (!). That it would just be a read-only page, which is of very limited use, was not even in my imagination. I can’t think of another open source project with this practice.

Taking a cue from Apache’s JIRA issue tracker, their policy seems to be:

  • Anyone is free to find issues
  • Registration and login required to create, comment, vote, or watch issues
  • Only developers can edit, prioritize, schedule and resolve issues

Is this similar to what you guys are suggesting?

– dave

Yep, that would be great.

Yes. In addition using the standard Pull Request or Merge Request workflow the patches are much easier to submit, watch, edit and validate for both the volunteer creating the patch and the HDFGroup developer assigned to the bug.

So when is this going to happen?

Adding flexibility and more self-service to our JIRA and Bitbucket deployment was already on the roadmap for early 2019, but given the interest here, we met this past week to discuss what we need to do to – both in terms of process and infrastructure – to make this happen soon.

In the interim, we are already elevating privileges for selected folks in the community who want to start contributing this way. If you’re interested, please email Elena at elena.pourmal@hdfgroup.org.

Stay tuned, and thanks for all the feedback.

In the meantime it would be great if someone with bugtracker access could have a look at the Bug: Library compatibility version differs between CMake and autotools build on macOS I linked and either confirm it as a bug and open a ticket, or explain if this is intended behavior. Was almost a month since I made that report after all :stuck_out_tongue: