Git repos location

[Tim Flink]

On Wed, 22 Jan 2014 14:03:17 +0200
Alexander Todorov <atodorov at redhat.com> wrote:

> На 22.01.2014 10:42, Kamil Paral написа:
> >> Phabricator is capable of hosting repositories but it would require
> >> some reconfiguration and testing. The feature is a newer addition
> >> and I'd want to test it a bit in staging before moving all of our
> >> code there.
> >>
> >> Any thoughts on how soon we might want to explore this? If we go
> >> this route, folks will have to upload their ssh pubkeys to
> >> phabricator because I strongly suspect there's no clean way of
> >> getting that data from FAS (if it's even possible at all).
> >
> > I'd like to have a single location for our projects. If we consider
> > abandoning bitbucket, let's do it ASAP, while we're not followed
> > there yet by many people.
> >
> > I see you've set up an example repo (in mirror mode) already:
> > https://phab.qadevel.cloud.fedoraproject.org/diffusion/LTRN/
> >
> > I don't use git web interface much, apart for community
> > fork-me/follow features we don't have there anyway, so I'm not very
> > demanding. The interface looks usable. But what's up with those
> > commit hashes - "rLTRNda6fd348cdf3". Why does it have the rLTRN
> > prefix? What is the Callsign?
> 
> Hi guys,
> a side note on the subject of migrating git repos:
> 
> BitBucket and GitHub are nice systems because of their fork/pull
> interface. This makes it very easy for collaborators to join, even if
> not very well experienced with git. GitHub here IMO has a leading
> edge because more people use it and is simply more popular. I myself
> prefer it.

Yeah, that seems to be the popular method for doing things lately.
github/bitbucket is a preference, though and I personally prefer
bitbucket but the two are pretty much a wash. Either josef or I started
putting stuff on bitbucket and we didn't see a really compelling reason
to change at the time, so that's persisted.

> I've also seen some projects use Gerrit for code review which for me
> as an experienced contributor always seems difficult to get. I always
> have to go back to the README b/c I forget how to push my changes for
> review - which is more or less the same as a pull request.

I've not used gerrit, but I've heard similar things about it. That and
it's hosting requirements weren't quite what I wanted to deal with
since it doesn't allow as much flexibility in repo hosting.

> For some projects we also have fedorahosted.org which AFAIK is only
> command line based.

This (all fedorahosted) was dismissed as an option pretty early on from
our experiences with the blocker tracking app. Trac + reviewboard +
cgit does work, but it's a bit on the painful side and not something
that I'm keen on duplicating.

> The above mentioned Phabricator doesn't seem to offer much in terms
> of easy contributor onboarding. At least I didn't see it.

Well, we are lacking on "getting started" docs at the moment. It's on
my todo list but I'm balancing that with a bunch of other priorities
like getting code more coherent so that existing participants aren't
completely starting from scratch when writing new functionality.

> I know these systems are designed to fit different teams and use
> cases and can't be compared so easily. My point is, when migrating
> look for a system with a clean and easy to use interface (preferably
> web as well) which will enable more contributors and less experienced
> contributors.

I'm not saying that phabricator is perfect - it certainly has it's
imperfections and warts. However, I don't know of anything that fits
our needs better and it is improving at a pretty rapid pace.

As a side note, I'm far more interested in creating and supporting a
good development community around qa tools than I am in making driveby
patches easier. If the prospect of emailing a patch is too much work
for someone ... I'm not all that saddened by the loss.

> Can we look for a GitHub similar open source interface which can be
> hosted on Fedora infrastructure if we don't want to have our code
> base hosted on external providers ?

I'm a pretty solid 'no' on this or at the very least, 'not now'. I did
look into other options before going forward with phabricator and we
did have discussion on list as that process went along. All other
options that I know of (github and bitbucket included) have severe
shortcomings that, in my opinion, make them worse choices for us than
phabricator.

The issue I have with github (and bitbucket, but for brevity's sake
I'll just say github here) is not so much the proprietary nature of
the platform but the issue tracker. If we had just one repo, it
wouldn't be a huge issue but there are no good ways to aggregate issues
from multiple repos and you end up with a situation where you either
have issues in one repo and no great way to differentiate between the
issues or you have issues spread across multiple trackers and no good
way to search for them.

The open source github clones all have issues as well. Gitorous is a
beast to maintain from a sysadmin perspective, is designed for a
_much_ larger scale than we need and AFAIK doesn't have any issue
tracking. Gitlab didn't support public repos last I looked and has the
same issue tracker problem that github does. Rhodecode had stability
issues when I tried it and was crashing on a daily basis when it ran
out of file pointers. It's also pretty difficult to find the sources
now that it's being sold as a product and I'd rather avoid it.

Another option would be to integrate standalone tools like
reviewboard/gerrit, roundup/bugzilla and cgit/someotherhost. However,
in order to be any less painful to use than the cgit+trac+reviewboard
chain I mentioned above, a lot of glue code and setup would be
required and I suspect that it would all lead to a rather fragile
system and a timesink for maintenance.

As I mentioned above (and had a conversation with another phabricator
admin who said pretty much the same thing), it's not perfect but I
really don't know of another solution that would be better overall
unless I started writing my own. Any toolchain we use is going to have
issues and cause us pain in one way or another - my goal is to minimize
those issues and pain points.

That all being said, I'm not against a better overall solution if it
exists. I just haven't heard a suggestion of what that better solution
is and the person-hours for the sysadmin and devel work to make it
happen.

At this point, we're on a pretty tight schedule and have a limited
window in which to deliver a new automation system. I'm completely
unwilling to put us in the situation where we're saying "we're not done
because we spent too much time on our support tools - they're really
awesome, though". If we do decide to change things up, it's going to
have to be done this week or it'll have to wait until f21 at the
earliest.

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/6239ef5a/attachment.sig>