We still have a few miscellaneous things hosted in:
https://git.fedorahosted.org/cgit/fedora-qa.git
since fedorahosted is dying next February, what should we do with them? Is this the point where we should finally decide whether to use Phabricator's built-in repository support or Pagure for this stuff and the stuff we currently host on bitbucket?
We also still use the fedorahosted *trac* for non-code-related activity tracking, but I guess that's better followed up on test@.
On Fri, Sep 09, 2016 at 05:51:55PM -0700, Adam Williamson wrote:
We still have a few miscellaneous things hosted in:
https://git.fedorahosted.org/cgit/fedora-qa.git
since fedorahosted is dying next February, what should we do with them? Is this the point where we should finally decide whether to use Phabricator's built-in repository support or Pagure for this stuff and the stuff we currently host on bitbucket?
We also still use the fedorahosted *trac* for non-code-related activity tracking, but I guess that's better followed up on test@.
I'm +1 to Pagure.
John.
We still have a few miscellaneous things hosted in:
https://git.fedorahosted.org/cgit/fedora-qa.git
since fedorahosted is dying next February, what should we do with them?
Move to Pagure. I can do it right away if nobody objects, I've already set up a group: https://pagure.io/group/fedora-qa
Is this the point where we should finally decide whether to use Phabricator's built-in repository support or Pagure for this stuff and the stuff we currently host on bitbucket?
Phabricator works well with remote repos, and I don't think there's any strong advantage in using local Phab repos. On Pagure we will get more visibility for the projects, easy forking, etc. Also certain simple repos (like the one above) can be completely fine with Pagure issue tracker and thus don't need to be configured in Phab (the UI is more difficult there for filing new bugs). I'd go with Pagure, for all our projects.
A slightly off topic, Adam, would you happen to know why Fedora doesn't self-host Pagure under say https://apps.fedoraproject.org/pagure , which would allow e.g. FAS group integration (unlike now, when we need to mirror our FAS groups inside pagure.io)?
On Tue, 2016-09-27 at 09:34 -0400, Kamil Paral wrote:
A slightly off topic, Adam, would you happen to know why Fedora doesn't self-host Pagure under say https://apps.fedoraproject.org/pag ure , which would allow e.g. FAS group integration (unlike now, when we need to mirror our FAS groups inside pagure.io)?
Nope, I have no idea. I suspect the #fedora-admin folks would know, though, and/or pingou of course.
If I had to guess I'd guess it was a case of wanting not to tie the platform too tightly to Fedora in the hopes of making it attractive to non-Fedora projects, but I really don't know, that's just a guess.
On Tue, 27 Sep 2016 11:33:32 -0700 Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2016-09-27 at 09:34 -0400, Kamil Paral wrote:
A slightly off topic, Adam, would you happen to know why Fedora doesn't self-host Pagure under say https://apps.fedoraproject.org/pag ure , which would allow e.g. FAS group integration (unlike now, when we need to mirror our FAS groups inside pagure.io)?
Nope, I have no idea. I suspect the #fedora-admin folks would know, though, and/or pingou of course.
If I had to guess I'd guess it was a case of wanting not to tie the platform too tightly to Fedora in the hopes of making it attractive to non-Fedora projects, but I really don't know, that's just a guess.
Actually Patrick and I were just talking about this. ;)
I think you are correct and that pingou wanted things to be more stand alone, but he's out this week so I am not sure.
When he gets back we can revisit this and see what we want to do.
kevin
On Tue, 2016-09-27 at 09:34 -0400, Kamil Paral wrote:
Move to Pagure. I can do it right away if nobody objects, I've already set up a group: https://pagure.io/group/fedora-qa
Only note I'd have is it'd be best to just check in with sumantro and a2batic first, since they're working on the plan for transitioning the non-code stuff in trac. But I expect it'll be fine to use that group.
Is this the point where we should finally decide whether to use Phabricator's built-in repository support or Pagure for this stuff and the stuff we currently host on bitbucket?
Phabricator works well with remote repos, and I don't think there's any strong advantage in using local Phab repos. On Pagure we will get more visibility for the projects, easy forking, etc. Also certain simple repos (like the one above) can be completely fine with Pagure issue tracker and thus don't need to be configured in Phab (the UI is more difficult there for filing new bugs). I'd go with Pagure, for all our projects.
In general I agree, I'd be happy for us to move pretty much everything into pagure. The only potential issues I see are:
1) What about issue tracking for the projects where we currently use Phab? For e.g., if we want to keep tracking issues/tasks in Phab exclusively, can we disable Pagure issue tracking (and make sure people can easily find their way to Phab issue tracking from Pagure?)
2) Similarly for pull requests - do we want to have parallel workflows, accepting both Pagure pull requests and Phab diffs? Or if we don't, can we disable Pagure PRs while providing sufficient breadcrumbs to get people into the Phab workflow?
Phabricator works well with remote repos, and I don't think there's any strong advantage in using local Phab repos. On Pagure we will get more visibility for the projects, easy forking, etc. Also certain simple repos (like the one above) can be completely fine with Pagure issue tracker and thus don't need to be configured in Phab (the UI is more difficult there for filing new bugs). I'd go with Pagure, for all our projects.
In general I agree, I'd be happy for us to move pretty much everything into pagure. The only potential issues I see are:
- What about issue tracking for the projects where we currently use
Phab? For e.g., if we want to keep tracking issues/tasks in Phab exclusively, can we disable Pagure issue tracking (and make sure people can easily find their way to Phab issue tracking from Pagure?)
You can disable issues in project settings. I don't think you can add a note to redirect people elsewhere, we can post a RFE or we can simply make that information visible in project README (which is shown by default).
The question whether we want to actually disable issues for certain projects or have several places to file them (pagure and phab) is a different matter. I guess we'll decide that on case-by-case basis.
- Similarly for pull requests - do we want to have parallel workflows,
accepting both Pagure pull requests and Phab diffs? Or if we don't, can we disable Pagure PRs while providing sufficient breadcrumbs to get people into the Phab workflow?
Yes, PRs can be disabled in settings as well. Again, I think this might be different for each of our projects and we'll probably decide individually.
qa-devel@lists.fedoraproject.org
-
Adam Williamson -
John Dulaney -
Kamil Paral -
Kevin Fenzi