Git repos location

[Tim Flink]

On Thu, 23 Jan 2014 05:48:00 -0500 (EST)
Kamil Paral <kparal at redhat.com> wrote:

> > https://phab.qadevel-stg.cloud.fedoraproject.org/
> > 
> > The hosting does work over ssh, but I'm noticing some quirks
> >  - the ssh urls are displayed incorrectly. This may be fixed in the
> >    latest upstream (the version we're using is several weeks old)
> > but I haven't checked yet. For the dummy repo I created:
> >    * shown:
> >       ssh://phab.qadevel-stg.cloud.fedoraproject.org/diffusion/PON/
> >    * actual thing to clone if you want it to succeed:
> >       git at phab.qadevel-stg.cloud.fedoraproject.org:diffusion/PON
> > 
> >  - http hosting doesn't work yet. I have some more tweaking to do in
> >    order to get that functional but it's do-able
> 
> Does this mean that phab repos can't be accessed publicly at this
> moment? What about public git:// access, is that supported/working?

There is no public access at the moment - just ssh based cloning. There
is no git:// access, just http(s) and ssh.

> Does the http hosting require fixing some bugs, or is it purely a
> configuration issue?

It's a configuration issue - phabricator can't find the git tool used
to html-ize repo interactions and I don't think it'll be a huge
problem to fix.

It would need to be fixed before deploying anything to production,
though. I'm not willing to lose anonymous access, even if we did have
mirrors on gh/bb

> >  - The repo names are ... weird. I understand why they end up like
> > they do, but I was hoping the uris would contain the repo name, not
> > the callsign.
> 
> That's a bit unfortunate. Does it mean that we need to differentiate
> all our repos by 4-letter access codes?

Yep, that's what it means.

> That would also mean that people cloning the repos need either
> provide a reasonable name to the git clone command, or they'll end up
> with cryptic directory names for our projects.

Yeah. I can see if that's what upstream's intention was - code hosting
is a relatively new feature and something may have changed but I doubt
it.

> > 
> > The setup is pretty straightforward and doesn't really mess with the
> > git hosting itself - just injects phabricator into the ssh auth
> > mechanism in a similar way to how gitolite works. If we did
> > decide to go this route for code hosting and something did go
> > horribly wrong, we have backups of the raw repos and it would be
> > pretty easy to resurrect them outside of phabricator.
> > 
> > Another feature that I haven't looked at much is mirroring - you can
> > configure repos to push commits to a remote repository. The
> > advantage here is that we could have the canonical upstream under
> > our control and have bitbucket/github mirrors that other folks
> > could use to create diffs from.
> 
> This might be a very good idea. We can use our system while the
> public can easily find and access our code, fork it, send a pull
> request.

I'm not sure how pull requests would work with reviews in phabricator
but that would be the general idea, yeah.

If we're thinking it's a good idea to host repos in phabricator, I'll
try to get the last config stuff done in the next day or so. I still
want to test everything thoroughly in stg first but assuming that we
don't hit any big problems, we can look at migrating next weekend.
 
> Or, if we find git hosting in Phab unsatisfactory, we can do it the
> other way round - host code on Github/Bitbucket and clone to Phab (if
> it helps something, for example reviews).

Yeah, the libtaskotron repo that's currently on production is a mirror
of bitbucket. Either way will work well enough for code reviews.

> When it comes to Github/Bitbucket choice, I played with them a bit
> and both seem pretty equal. They are closed-source, they support
> teams, and because we won't need issue tracking there's not many
> other differences. Only Github is more popular and more people have
> an account there, so I think that would be the only reason to pick
> Github over Bitbucket.

I agree that the two systems are pretty much equivalent for what we're
using. The one bit that's relevant to how we'd use either one is team
management. I really don't like how github does team/group management
and bitbucket's interface is easier to use.

I don't see how the benefit of switching to github outweighs the cost
of doing so. The last time I talked to infra, they hadn't really seen
an increase in contributions since they moved to github and I sincerely
doubt that we would either. Their workflow has improved with the switch
but almost all new contributors were already interested and involved in
fedora.

I'd really like to put this discussion to bed - it keeps coming up and
to be quite frank, we have more important things to do than talking
about which site we're using to host code when there's so little
difference between the two. I'm a big believer of choosing your battles
and I'm not going to fight a migration to github but I'm not going to
do the migration work, either. If there's enough support here and you
want to do the migration, update all the needed links etc. (including
the repos in phab) and find everyone's usernames on github for a
team/group, go for it.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20140123/7997519e/attachment.sig>