Opened 9 years ago

Closed 9 years ago

Last modified 6 years ago

#555 closed Feature Wish (worksforme)

Using GitHub integrated issue tracking

Reported by: crane Owned by:
Priority: major Milestone:
Component: Documentation Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: bugtracking github contributing



I would prefer to fill in bug report on github than on this site.

Pros (imho) would be:

  • most developers / people who fill a bug report have already an account on github
  • searching for bugs is more trivial
  • referencing to commits and other issues
  • closing issues by using git commit1

I just wanted to fill in a bug report for OpenVPN and now I have another account where I have to pay attention for.


Change History (7)

comment:1 Changed 9 years ago by David Sommerseth

These arguments does not convince me much. If you you provide a valid e-mail address, you will get e-mails whenever the trac ticket changes.

Also when we use our own hosting we have far better control of the contents than on an outsourced solution. But of course, both approaches have advantages and disadvantages. For the record, we actually got far better control of bug tickets when moving into Trac from the hosted tracker - also because we enforce users to sign-up and provide an e-mail address. In the previous tracker we had just too many tickets where we never got any responses when we needed that. Thus, enforcing a sign-up usually means people want to help resolving these issues.

We also have a considerable amount of tickets which would need to be transferred. Given the limited resources this project have (the majority of the community are volunteers), I prefer we spend time fixing those issues we have open than spend time on migrating tickets to yet another place. Those open issues does not get fixed quicker if we move to another tracker.

Last edited 9 years ago by David Sommerseth (previous) (diff)

comment:2 Changed 9 years ago by Gert Döring

Resolution: worksforme
Status: newclosed

What dazo said.

In other words: this site is our main focus point - wiki and bug tracker.

Adding extra issue trackers here and there (github this month, who knows what is cool in 6 weeks from now) is not making life easier for those people actually trying to keep track of the bugs and fix them - and since this is what is our most valuable resource right now (developer time), we're keeping it all here.

comment:3 Changed 9 years ago by Eric Crist

What dazo and cron2 said. We specifically moved away from hosted solutions. We may not use git or github in the future, but we can roll whatever we end up using into our own site much easier. This is not saying we are going to actually move away from either, but it could happen at some time.

comment:4 Changed 6 years ago by ssbarnea

Nothing is set in stone and even if people got burned twice with opensource hosting approaches (sourceforge and later google code), this does not mean that all hosted solutions are a bad bet.

I personally hope things will change in the future as there are some very important benefits on using hosted solutions: it gives the maintainer more time to focus on improving the product instead of managing the infrastructure around it. I am still amazed too see that almost everyone is understating the amount of effort needed.

Also the second aspect is critical mass and ease of getting new contributions, that's why GitHub? and GerritHub?.io are so successful.

comment:5 Changed 6 years ago by Gert Döring

While this might not be set in stone, the way we organize things (like, pushing to sf, github and gitlab) has so far turned out to be useful. Whenever any of these sites is down, people still can get to the git repo in one of the other sites.

Consequently, this is all we are going to use from either of these services.

(Since half of the openvpn community have a day job related to sysadminning, maintaining a local bug tracker, patchwork instance and buildbot is not much extra effort)

comment:6 Changed 6 years ago by David Sommerseth

Just echoing what Gert says. The workload related to the infrastructure maintenance is surprisingly low. Yes there times when there are more work on it, but the overall average workload is pretty low. Okay, I can agree it doesn't look as fancy and cool as the other kids in the street, but that's beside the point for us. What we have now serves the need we have and provides the features we need. Whenever each of us core developers have time to work on the OpenVPN community, we are fully capable for focusing on the task itself and not how to use the tools. What we have works very well.

And we do believe our distributed way of working thus makes most sense, considering we are providing a security product.

We use mailing lists primarily, because it is distributed. If one mailing list provider decides to shut the service down, the mails are still being available via other mailing list archives on the net - keeping the integrity of our patch discussions available. And it is easy enough to replicate the mailing list and put it on another server or service.

We do use GitHub? for hosting our git repository, but we also push the same branches and tags to GitLab? and SourceForge?.net. This ensures the integrity of the git repository should one of these sites be compromised or deciding to shut down. And it is easy enough to replicate the git repository and put it on another server or service and provide solid public evidence the git repository has not been altered in the move.

We use Trac for ticket tracking now, because that is harder to distribute. But since it is under our own control, our references to tickets in git our history will be valid as long as we decide to keep this service running - or a read-only archive of these tickets.

And we use Trac for wiki, mostly because it's part of Trac which we already use. So there's no additional "cost" to use that feature. And as it is under our own umbrella, we don't need to worry about the what-ifs related to if a service provider decides to shutdown the service or a feature in the service.

Yes, there is a barrier to join a mailing list to contribute patches. Yes, there is a barrier to register another account to file bug reports. But if a person is not willing to do that, perhaps the issue or patch isn't that much interesting or needed?

I would even go as far to say that the "fork on GitHub?" feature is also a poor feature. There are currently 1070 forks of the OpenVPN repository on GitHub?. I strongly doubt we would have had even close to 100 or even 50 new contributors if we fully embraced the GitHub? model. It is even so many forks that GitHub? gives up providing a fork-tree to give an impression of how it has branched out. And it wouldn't even surprise me that the vast majority of forks are even lingering way far (more than 3-4 months at least) behind the our current master branch. And this situation with out-dated forks isn't even unique to OpenVPN; this is something easily spotted in most GitHub? hosted projects.

So our decisions still stands firm. Not saying things won't change in the future, but based on what is available today: Keeping things as they are keeps holding our maintenance burden low enough and keeps us developers focused on the submitted patches.

Last edited 6 years ago by David Sommerseth (previous) (diff)

comment:7 Changed 6 years ago by Eric Crist

Just to add in, as one that maintains the infrastructure around here, "me too". There isn't too much effort required to maintain our systems and this works for the development team.

Note: See TracTickets for help on using tickets.