Ticket #1553 (closed defect: fixed)

dscho, please associated with some feature ticket

There is currently a very nasty problem with the Trac: certain functions that are supposed to send emails silently do not do so.

Specifically, password requests are never sent (but the Trac reports no errors). Similarly, I attempted to enable new user account registration, but it also never sends the confirmation email necessary to greenlight a new account.

It is probably sendmail being finicky about something due to permissions or similar, but I am not sure which logs to check to diagnose this problem.

Also, ultimately, to close out this ticket, we need to set up  email2trac.

Another option would be to migrate our entire ticket infrastructure over to GitHub Issues. That would solve the openness problem completely, but at the expense of functionality: we would lose our hierarchical feature-based ticket classifications.

We would also be at the whim of the GitHub service which is in general quite good but not always.

Maybe as a compromise, we should encourage users to report problems on GitHub, but we still need to make it possible to respond to Trac tickets people are Cc:ed on.

Indeed, we could use GitHub for "user-facing" tickets and the Trac for "developer-facing" work. I am ambivalent, because it better targets the scope of each system. But the dichotomy could lead to duplicate or confusingly similar tickets. Ultimately I am leaning against it but more discussion would be good.

We should seriously consider a custom solution based on procmail and the Python API. Hopefully I will have time to look into that soon; we need the same for Fiji's BugZilla because people find it too hard to follow the link to respond to tickets, and simply reply.

More and more, I want to migrate everything to GitHub Issues. Yes, it sucks when GitHub is down. Yes, we need to back up the tickets from there. But it would be far less time than maintaining a custom solution in an ever-hackier Trac installation, which is relatively less and less popular over time. Using GitHub Issues integrates with our other GitHub usage, is familiar to more and more developers, integrates with an increasingly large number of dev tools (such as Eclipse's Mylyn). Lastly, creating a new GitHub issue is a snap. Super fast, super easy. Better for core developers, better for the extended community.

We are already using GitHub Issues with both ImgLib2 and SCIFIO now and it works well. The only thing I really miss from our Trac setup is hierarchical issues, but I am confident we can find an acceptable solution or substitute.

The only problem with GitHub issues we cannot really solve is that they require a user to be logged in to comment. And not everybody and her dog want to have a GitHub account...

Well, the Fiji wiki already requires people to create an account. Is that something you want to move away from? I.e., do you want to support anonymous bug reports? I don't know of any projects that support that, regardless of the bug tracker used.

Of course, people can send a mail to the mailing list, and one of the developers can file the bug. I think that's what works best for nearly every project.

Or are you saying you will miss the "CC" functionality of Trac and BugZilla where you can put an email address of someone who doesn't have an account? If we decide we really want that, we could support it via a custom script on one of our servers which reacts to GitHub Issue changes. And I believe it would still be less complicated than a "custom solution based on procmail and the Python API."

Also, I don't see the "require a user to be logged in to comment" issue as unique to GitHub Issues. The same problem exists for the IJ2 Trac and the Fiji BugZilla currently. You must have an account to comment. I am OK with that compromise, given the many other sacrifices we would need to make to pursue any alternative.

My idea was to auto-register BugZilla 'accounts' (which are really the email addresses, and hence automatically unique, in contrast to GitHub's) upon receiving a mail.

I see that dramatically more difficult with GitHub where you really have to go through their website to register an account, including the intimidation about source code control for non-programmers ;-)

I understand the concern, but it sounds like too much work/time for us to accommodate. One option would be to simply register a single account like "ImageJ community" with GitHub and then pipe all emails we receive through that. Implementing a feature like that would make me uncomfortable though, since it would be a hacky workaround to the limitations of GitHub Issues. Unfortunately I don't have a better idea, but I am very reluctant to abandon GitHub Issues since it has myriad other benefits for those willing to register an account.

I think that the hacky workaround would also have one very nasty side effect: it would not notify the reporters of bugs whenever there was an update to their ticket.

As to how much work it would take: I think I need to do this for  http://fiji.sc/bugzilla/ anyway, so let's assess how much additional work it would be for Trac after that. Or just decide that Fiji's BugZilla is supposed to serve the user-visible side of ImageJ2, too. Something to mull over in the back of our minds for now, I guess.

I agree that solving the issue tracker is not our top priority right now. However, I would like to address it by year's end. ImageJ2 has gone several years with a bug tracker that is not really usable for the community at large. That must end before we come out of beta.

Fiji's bug tracker is indeed much more usable. The idea of making the Fiji BugZilla also be the user-facing ImageJ2 bug tracker is intriguing. But we should first answer the question: "Do we need separate user-facing and developer-facing issue trackers?" My answer leans toward "no" right now -- most projects do not have such a separation, and the line between them becomes extremely blurry in many cases, making duplication (and hence disorganization) prevalent.

New ImageJ issues have been being filed on GitHub Issues for a while now. And now that the final ImageJ component structure is in place, which repository houses each sort of issue is quite clear.

So we will keep using GitHub Issues for all core SciJava software issue tracking. This makes it very simple for developers worldwide to respond to issues, either on the website or via email. GitHub takes care of all that for us.

I am in the process of migrating all existing ImageJ Trac tickets to GitHub Issues in the appropriate repositories.

just decide that Fiji's BugZilla is supposed to serve the user-visible side of ImageJ2, too.

Indeed, we could still generalize the Fiji BugZilla as a user-facing destination for all ImageJ bugs filed using the "Report a Bug" mechanism. Then from there we could link to relevant GitHub Issue(s). It's basically the difference between "user stories" and "developer tasks" which Agile methodologies emphasize.