Code Hosting, Development Tools and Open Source

[Tim Flink]

On Wed, 09 Oct 2013 14:25:46 +1000
Nick Coghlan <ncoghlan at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/09/2013 02:53 AM, Tim Flink wrote:
> > If we're OK with non-open tools, Jira [4] is another option. They
> > offer free hosted and self-hosted versions of their tools to open
> > source projects [5]. Atlassian has been offering this for a long
> > time and their tools are used by other open source projects like
> > the apache project and jboss. I've not spent much time with Jira
> > but have heard more good things than bad things about it.
> > 
> > [4] https://www.atlassian.com/software/jira [5]
> > https://www.atlassian.com/software/views/open-source-license-request
> >
> >  So after a long novel-disguised-as-an-email, I have two main
> > questions:
> > 
> > Where do we want to host code for Taskbot and future QA
> > development projects? - fedorahosted? github? bitbucket? I don't
> > have a huge preference on the location as long as we're talking
> > about git repos, to be honest.
> > 
> > What do we want to use for issue tracking? - This is the bigger
> > issue, is there enough interest in phabricator to justify getting
> > it working with fas-openid and doing a larger trial? - Do we want
> > to explore using JIRA?
> > 
> > Anyhow, thoughts on all this would be very much appreciated.
> 
> Given the long and painful process attempting to get GitLab deployed
> into Fedora infrastructure, I don't believe it makes sense to consider
> a *different* self-hosted option that is neither Trac nor GitLab. You
> want to spend your time working on Taskbot, not maintaining Taskbot's
> VCS and issue tracking infrastructure.

+1 million on the not spending any more time maintaining a VCS and/or
issue tracking system if we don't have to. It's overhead and headaches
that would be great to avoid.

I don't think of it so much as "avoid doing any tool work" as
"making sure that the efficiency gains we get from a tool are greater
than the time we spend maintaining it". Either way, it's the same
sentiment of being in the getting-stuff-done business not the
farting-around-with-fancy-tools business.

I'm aware of the GitLab initiative but I didn't realize that it was
anywhere close to being ready or a sure thing. My understanding was
that the main problems were that it is a big ball of ruby (mostly
packaged at this point), that it doesn't yet support anonymous
viewing (but I think that's on their roadmap for the next year or so)
and that it's support for pull requests wasn't quite up to github
standards yet. I suppose I should ping infra about all of this to
make sure I'm not missing something.

What I want is:
 - easy/workable code review
 - good issue tracking
   * one issue tracker for the entire project preferred
   * be able to track things like infra and investigation tasks
 - almost everything use the same auth (prefer FAS, github/bitbucket
   would be an option)
 - not need to have someone always working on maintaining stuff

Ideally all of it would be open source but I'm not sure I want to push
for anything to be added as a fedorahosted option - that's a lot more
work than I really want to be taking on right now. We have enough on
our plate as it is.

> In terms of your hosted options, it may be worth looking at RhodeCode
> Hosted, since that's a lot closer to normal open source than JIRA.
> However, that would have the same doesn't-integrate-with-FAS problem
> as other hosted alternatives.

I tried out RhodeCode a few months ago before they had the enterprise
support like they do now. I had so many problems with it that I
switched over to gitolite+cgit which has fewer features but
supports ssh keys and didn't crash on a daily basis.

It may be worth looking at again, though since we're likely to need
some VCS management at some point for the task repos. I had been
planning to use some variation of the fedorahosted setup (either repos
in fedorahosted or a clone - haven't talked to infra about this yet)

> One of the nice things about the RhodeCode hosted option though, in
> that where GitHub and BitBucket give you repos within a single large
> shared system, RhodeCode gives you your own self-contained server.
> This means a bit more work to get it set up, but also gives you more
> flexibility in terms of issue management.

Yeah, one of the classic choices: flexibility or
lack-of-required-effort :)

You all are using gerrit, right? Have you been happy with it WRT
features, maintenance etc? I've been getting the impression that there
are a lot of people who aren't thrilled with it but I've not actually
tried to use it myself.

Thanks so much for your input, I really appreciate it.

Tim

> Cheers,
> Nick.
> 
> - -- 
> Nick Coghlan
> Red Hat Infrastructure Engineering & Development, Brisbane
> 
> Testing Solutions Team Lead
> Beaker Development Lead (http://beaker-project.org/)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJSVNrKAAoJEHEkJo9fMO/LfwIH/A8Q32oK++JBZRSNUR/4MICw
> /A7mjeZHwSYYgG+/2qJt6PzfRxY1UiW8bXus00wEcI56kuqQgP66Tk+INH2+5uVN
> N9g1BQVW18bWjR6U0tanceNQO2gp2hfUByPIeaSjVPwI5JlKoRUzmCBp/agZo3lT
> V7AJYWMXXDTinD4NXr4kbtA9YiKyvKbzWqPuzS2IPsSiyVY6fXHy8eU71/25z/k+
> EX1k0WA585zCSb+VKlmp1SRcMnFXwt6irDfy9U6XFCJGqiHE/Dg2Rl0bk8GHHxL8
> 3QWQT4H/crp3grri4YxYNMHyJSuGYZd/c+7jMUGJN2q11KNGLvTYTVlU+08WgdM=
> =Lt3K
> -----END PGP SIGNATURE-----
> _______________________________________________
> qa-devel mailing list
> qa-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/qa-devel

-------------- 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/20131009/58453509/attachment.sig>