contributing pain points (was: Re: New REST API - motivation)

[Mark Côté]

On 2014-12-05 11:07 PM, Damien wrote:
> On Fri, Dec 5, 2014 at 5:01 PM, Mark Côté <mcote at bugzilla.org> wrote:
> 
>> On 2014-12-05 3:36 PM, Damien wrote:
>>> however the current "contribution" workflow is a pain for folks that
>>> actually want to contribute.
>>
>> I would love to hear more on this.  One of my goals as Assistant Project
>> Lead is to increase the number of contributors, which in turn requires
>> that contributing be relatively painless.
> 
> I have had much better user experience with bitbucket and github service.
> One thing github got right is how continuous integration systems
> (travis-ci, jenkins and others) can test pull requests and tell you if your
> changes would pass or break the tests. obsoleting patches is easy as well
> (updating the pull-request branch).
> 
> You can also look at gerrit which many communities use.
> https://www.mediawiki.org/wiki/Gerrit/Tutorial
> I personally don't like the user interface, but the tooling is nice.

I would prefer to discuss specifically where the current process is
lacking rather than focussing on other tools; that said, I know our
process is a bit dated.

Regarding GitHub, we actually have a mirror there
(https://github.com/bugzilla/bugzilla) which is hooked up to Travis CI
(https://travis-ci.org/bugzilla/bugzilla).  There are admittedly some
intermittent failures that we need to look into, but the framework is
there.  It would be easy to test your own fork again Travis in the same way.

At the moment we don't accept pull requests because they are hard to
integrate with Bugzilla, which is the source of truth for Bugzilla
development.  But I can see a strong argument for encouraging pull
requests just to get the tests run automatically, even if we then move
to Bugzilla for the review.  I've been thinking about writing a tool to
convert a pull request to a Bugzilla patch automatically.  Should be
pretty easy, although I admit that the review system in Bugzilla is not
as nice as GitHub's.

Regardless, running the tests should be pretty easy now, and I'll update
the contributing pages on the wiki, which I realize I neglected to do
after we switched to Travis.

Mozilla is slowly migrating to a solution based on Review Board but more
powerful, a repository-centric system not entirely unlike GitHub. I hope
that, some day, Bugzilla can use this system as well.

Mark

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla