[logic] why ? about infrastructure HOT 1 CLOSED

Hi @cybernet -

Ultimately, we're still figuring out what works best, what we need, and where we can simplify. That being said, the decision regarding bugzilla came down to the following:

• GitLab (or GitHub) can host source code in the future (it doesn't right now) and issues will be for the code
  • Think of Fedora pagure for their source code issues and they use bugzilla.redhat to deal with distribution issues.
• Bugzilla will be the distribution tracker.
  • It did not make sense to have a distribution bug tracker in Git. The organization does not allow for that and we also don't want to open groups/projects just to field issues with the distribution. The git contributor agreement does explain this.

In summary, there should be a logical separation between source code issues (which is very little) and actual distribution issues (which will likely be higher for a long while). But, this brings up some other things:

• We don't like the idea of having disorganization on github issues or consolidating things into a single unorganized bucket
  • Git(hub|lab) issues are great, but not for something that is complex, like a distribution and its infrastructure requirements.
• Creating projects/groups for things that won't have code to host issues did not make logical sense
• Release Engineering tools already hook into bugzilla and git and use them for their specific use cases.

Hopefully that gives some clarity on the use of bugzilla - where everything will "live" long term remains to be seen. We've only been at it for a few months.

If you have any follow up questions, I'd be happy to try and answer them!

from infrastructure.