Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Serious alternatives to Gerrit

 

 

First page Previous page 1 2 3 4 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


robla at wikimedia

Jul 17, 2012, 5:41 PM

Post #1 of 77 (5393 views)
Permalink
Serious alternatives to Gerrit

Hi everyone,

It appears as though the discussion has continued apace for the Gerrit
evaluation process:
http://www.mediawiki.org/wiki/Git/Gerrit_evaluation

Thank you everyone for chipping in so far. The current format is a
mix of talk page and structured discussion, which seems ok for now.

It would appear from reading this page that the only alternative to
Gerrit that has a serious following is GitHub. Is that the case?
Personally, it seems like Phabricator or Barkeep has the best chance
of dislodging Gerrit, but those won't probably get serious
consideration without a champion pushing them.

Rob

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


saper at saper

Jul 18, 2012, 12:53 AM

Post #2 of 77 (5300 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

>> Rob Lanphier <robla [at] wikimedia> wrote:
> It would appear from reading this page that the only alternative to
> Gerrit that has a serious following is GitHub. Is that the case?
> Personally, it seems like Phabricator or Barkeep has the best chance
> of dislodging Gerrit, but those won't probably get serious
> consideration without a champion pushing them.

Maybe this is because of the discussion format which was framed
as "for and against" Gerrit.

Is it possible to setup a copy of Phabricator in labs? What
is needed to help with this?

//Saper


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


p858snake at gmail

Jul 18, 2012, 1:49 AM

Post #3 of 77 (5306 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, Jul 18, 2012 at 5:53 PM, Marcin Cieslak <saper [at] saper> wrote:
> Maybe this is because of the discussion format which was framed
> as "for and against" Gerrit.
>
> Is it possible to setup a copy of Phabricator in labs? What
> is needed to help with this?
>
> //Saper

John had one running just as we were implementing gerrit and it has
some "flaws" so I know at least one staffer that deals with Git
doesn't want it.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


hashar+wmf at free

Jul 18, 2012, 1:51 AM

Post #4 of 77 (5330 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

Le 18/07/12 02:41, Rob Lanphier a écrit :
> It would appear from reading this page that the only alternative to
> Gerrit that has a serious following is GitHub. Is that the case?
> Personally, it seems like Phabricator or Barkeep has the best chance
> of dislodging Gerrit, but those won't probably get serious
> consideration without a champion pushing them.

We could also consider Gitlab (already listed on the wiki).

Site: http://gitlabhq.com/
License: https://github.com/gitlabhq/gitlabhq/blob/master/LICENSE

Which would let us self host something very similar to GitHub.


Anyway, I would love us to start writing an evaluation matrix of all the
solutions. Would need to establish a set of weighted criteria (which
must be based on facts evaluation not on feeling) and then rate each
criteria for all solutions. End result will give us either a short list
which we could evaluate again or a clear "winner".

I am still wondering if we will eventually find out a solution that
would fit all our needs :-/

--
Antoine "hashar" Musso




_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

Jul 18, 2012, 8:28 AM

Post #5 of 77 (5285 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On 18/07/12 02:41, Rob Lanphier wrote:
> Hi everyone,
>
> It appears as though the discussion has continued apace for the Gerrit
> evaluation process:
> http://www.mediawiki.org/wiki/Git/Gerrit_evaluation
>
> Thank you everyone for chipping in so far. The current format is a
> mix of talk page and structured discussion, which seems ok for now.
>
> It would appear from reading this page that the only alternative to
> Gerrit that has a serious following is GitHub. Is that the case?
> Personally, it seems like Phabricator or Barkeep has the best chance
> of dislodging Gerrit, but those won't probably get serious
> consideration without a champion pushing them.
>
> Rob

The evaluation is intended to determine if we want to continue with
gerrit or change. If we decide to change, we should then see what we
want to change to.
Maybe we would finally decide that all the alternatives are worse and
end up not changing. Or keeping an eye to anything new which gets
published. Or perhaps contributing a LDAP module to some otherwise-fine
tool.

Regards


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


agarrett at wikimedia

Jul 18, 2012, 9:33 AM

Post #6 of 77 (5290 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, Jul 18, 2012 at 11:28 AM, Platonides <Platonides [at] gmail> wrote:
>
> The evaluation is intended to determine if we want to continue with
> gerrit or change. If we decide to change, we should then see what we
> want to change to.
> Maybe we would finally decide that all the alternatives are worse and
> end up not changing. Or keeping an eye to anything new which gets
> published. Or perhaps contributing a LDAP module to some otherwise-fine
> tool.
>

I don't think you can decide to change away from gerrit without having an
idea of what we want to use instead. As I understand it, we're on gerrit
because it's the least-bad option. To show that it's no longer the least
bad option, you need to find a product that is less bad.

--
Andrew Garrett
Wikimedia Foundation
agarrett [at] wikimedia
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


datzrott at alizeepathology

Jul 18, 2012, 9:44 AM

Post #7 of 77 (5308 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

>I don't think you can decide to change away from gerrit
>without having an idea of what we want to use instead.
>As I understand it, we're on gerrit because it's the least-
>bad option. To show that it's no longer the least bad
>option, you need to find a product that is less bad.

Agreed. Otherwise we end up in a position where we really want to switch
and everyone is excited to switch, but there is nothing to switch to.
People get disappointed, eventually everyone moves on and goes back to using
gerrit like nothing happened. All in all, discussing switching without any
suitable options to switch to leads to disappointment and wasted time.
Neither of which are helpful for us.

Thank you,
Derric Atzrott


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Jul 18, 2012, 10:18 AM

Post #8 of 77 (5331 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

What about changing gerrit to our needs? It's open source, I suppose.

On Wed, Jul 18, 2012 at 6:44 PM, Derric Atzrott
<datzrott [at] alizeepathology> wrote:
>>I don't think you can decide to change away from gerrit
>>without having an idea of what we want to use instead.
>>As I understand it, we're on gerrit because it's the least-
>>bad option. To show that it's no longer the least bad
>>option, you need to find a product that is less bad.
>
> Agreed. Otherwise we end up in a position where we really want to switch
> and everyone is excited to switch, but there is nothing to switch to.
> People get disappointed, eventually everyone moves on and goes back to using
> gerrit like nothing happened. All in all, discussing switching without any
> suitable options to switch to leads to disappointment and wasted time.
> Neither of which are helpful for us.
>
> Thank you,
> Derric Atzrott
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rlane32 at gmail

Jul 18, 2012, 11:41 AM

Post #9 of 77 (5296 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, Jul 18, 2012 at 1:18 PM, Petr Bena <benapetr [at] gmail> wrote:
> What about changing gerrit to our needs? It's open source, I suppose.
>

That's of course the route we're going right now. The biggest hurdle
to doing so is that it's written in Java, and Prolog. Neither of those
languages are amazingly difficult, though, so I don't really see that
as a complete blocker.

- Ryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


robla at wikimedia

Jul 18, 2012, 11:45 AM

Post #10 of 77 (5331 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, Jul 18, 2012 at 9:33 AM, Andrew Garrett <agarrett [at] wikimedia> wrote:
> I don't think you can decide to change away from gerrit without having an
> idea of what we want to use instead. As I understand it, we're on gerrit
> because it's the least-bad option. To show that it's no longer the least
> bad option, you need to find a product that is less bad.

Precisely. Since my stated bias is to stay on Gerrit, I'm not the
best person to propose the alternative, but suffice it to say, we're
going to have to have a much more buttoned-down case for the
alternative if yet another migration is in the cards.

If we stay on Gerrit, we plan to make investments in those areas that
we've identified as deficient. However, we shouldn't make the
decision to stay on Gerrit based on vaporware - we should evaluate
Gerrit as it is today, and assume that any changes we propose are
harder than they appear on the surface. That also means evaluating
the *other* tools as they are today, as well, and assuming that any
changes we need to *those* tools are harder than they appear on the
surface.

Rob

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Jul 18, 2012, 3:17 PM

Post #11 of 77 (5303 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, 18 Jul 2012 11:41:06 -0700, Ryan Lane <rlane32 [at] gmail> wrote:

> On Wed, Jul 18, 2012 at 1:18 PM, Petr Bena <benapetr [at] gmail> wrote:
>> What about changing gerrit to our needs? It's open source, I suppose.
>>
>
> That's of course the route we're going right now. The biggest hurdle
> to doing so is that it's written in Java, and Prolog. Neither of those
> languages are amazingly difficult, though, so I don't really see that
> as a complete blocker.
>
> - Ryan

The blocker for me was not the language, but the codebase. I wanted to
make a small tweak to Gerrit so I started looking through the code. And I
had absolutely no clue where to find what I was looking for. I couldn't
make sense of what most of what I found was even supposed to do. And
people have pointed out a number of issues with Gerrit like the way it
handles output and css which feel much more like fundamental (ie:
unfixable without practically rewriting) issues with Gerrit.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Jul 18, 2012, 3:48 PM

Post #12 of 77 (5289 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, Jul 18, 2012 at 6:17 PM, Daniel Friesen
<lists [at] nadir-seen-fire> wrote:
> On Wed, 18 Jul 2012 11:41:06 -0700, Ryan Lane <rlane32 [at] gmail> wrote:
>
>> On Wed, Jul 18, 2012 at 1:18 PM, Petr Bena <benapetr [at] gmail> wrote:
>>>
>>> What about changing gerrit to our needs? It's open source, I suppose.
>>>
>>
>> That's of course the route we're going right now. The biggest hurdle
>> to doing so is that it's written in Java, and Prolog. Neither of those
>> languages are amazingly difficult, though, so I don't really see that
>> as a complete blocker.
>>
>> - Ryan
>
>
> The blocker for me was not the language, but the codebase. I wanted to make
> a small tweak to Gerrit so I started looking through the code. And I had
> absolutely no clue where to find what I was looking for. I couldn't make
> sense of what most of what I found was even supposed to do. And people have
> pointed out a number of issues with Gerrit like the way it handles output
> and css which feel much more like fundamental (ie: unfixable without
> practically rewriting) issues with Gerrit.
>

Diving into a large mature codebase that you've never touched is not usually
something people can pick up in an afternoon. I imagine most people try to
find something they do understand, grep around, and then slowly expand the
areas of code they know their way around.

It's just very enterprise-y Java. It's not really all that hard if
you're interested
in actually diving into it.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


saper at saper

Jul 18, 2012, 3:48 PM

Post #13 of 77 (5296 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

>> Daniel Friesen <lists [at] nadir-seen-fire> wrote:
> On Wed, 18 Jul 2012 11:41:06 -0700, Ryan Lane <rlane32 [at] gmail> wrote:
>
>> On Wed, Jul 18, 2012 at 1:18 PM, Petr Bena <benapetr [at] gmail> wrote:
>>> What about changing gerrit to our needs? It's open source, I suppose.
>>>
>>
>> That's of course the route we're going right now. The biggest hurdle
>> to doing so is that it's written in Java, and Prolog. Neither of those
>> languages are amazingly difficult, though, so I don't really see that
>> as a complete blocker.
>>
>> - Ryan
>
> The blocker for me was not the language, but the codebase. I wanted to
> make a small tweak to Gerrit so I started looking through the code. And I
> had absolutely no clue where to find what I was looking for. I couldn't
> make sense of what most of what I found was even supposed to do. And
> people have pointed out a number of issues with Gerrit like the way it
> handles output and css which feel much more like fundamental (ie:
> unfixable without practically rewriting) issues with Gerrit.

I got used to it. It's completely different Java if one is used
to old-skool Java programming. Components are decoupled with the
use of Guice (for "dependency injection" - http://c2.com/cgi/wiki?DependencyInjection)
framework plus there is Google Web Toolkit programming, again a very
special beast.

Another component is the ORM mapper, gwtorm.

Other than that it's pretty fine, with the usual Java problem
that I need to cut through gazillion of classes and interfaces
before I get to the core of things.

For example, to fix https://bugzilla.wikimedia.org/show_bug.cgi?id=38114
few lines need to be added before line 296 of

https://gerrit.googlesource.com/gerrit/+/05d942c324d7a17285873a468f3605cbc190b8d5/gerrit-gwtui/src/main/java/com/google/gerrit/client/changes/ChangeTable2.java

(not sure it's a good idea but here it is)

I have attached Jython interpreter to Gerrit to
play a bit with the code:

https://gerrit-review.googlesource.com/#/c/34670/

You can play live with the ORM mapper for example
and retrieve Java objects from the database (not just
rows).

//Saper


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

Jul 18, 2012, 4:27 PM

Post #14 of 77 (5288 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On 19/07/12 00:48, Marcin Cieslak wrote:
> You can play live with the ORM mapper for example
> and retrieve Java objects from the database (not just
> rows).
>
> //Saper

I'm not really convinced into playing with the database when not even
the database structure is easily readable (it is derived from several
classes automatically). :P



_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


z at mzmcbride

Jul 18, 2012, 8:53 PM

Post #15 of 77 (5296 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

Rob Lanphier wrote:
> It appears as though the discussion has continued apace for the Gerrit
> evaluation process:
> http://www.mediawiki.org/wiki/Git/Gerrit_evaluation

Really ought to get default to HTTPS working...

> Thank you everyone for chipping in so far. The current format is a
> mix of talk page and structured discussion, which seems ok for now.

Meatball-ish. :-)

> It would appear from reading this page that the only alternative to
> Gerrit that has a serious following is GitHub. Is that the case?
> Personally, it seems like Phabricator or Barkeep has the best chance
> of dislodging Gerrit, but those won't probably get serious
> consideration without a champion pushing them.

I don't use Gerrit much. I occasionally try to use it in the same way that I
once used the CodeReview MediaWiki extension. I laid out some of the
problems I had here: <https://www.mediawiki.org/wiki/Talk:Gerrit/Problems>.

Gerrit's UI seems to be just about as awful as it can be without it being
outright rejected as a feasible option for code review. It's the Microsoft
approach to UI, where everything is possible, it just takes ten times as
long as it should because it's hidden behind obscure, inaccurate, or
meaningless link terminology or it's collapsed behind some awful menu (that
you don't even realize is a menu for a few months).

If Gerrit's UI can be improved to not be so awful, it would go a long way
toward making it acceptable. The big advantage I see to GitHub is that its
UI actually has sense and decency behind it. It really shouldn't be so
difficult to fix Gerrit's styling. As Daniel said in a previous post, the
fact that it is suggests more fundamental issues with the codebase and its
architecture. I deeply worry about software that can't handle something
basic like CSS in a sane manner (again, the Microsoft approach, heh).

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


ssastry at wikimedia

Jul 18, 2012, 9:30 PM

Post #16 of 77 (5330 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

While Gerrit's UI is not the best, I can work around that for the most part.

What bugs me the most about Gerrit are two things:

(a) A single commit is always the unit of review: While that is
reasonable in many cases, in other cases, what ought to be a unit of
review is a topic branch. So, the committer has to have an option of
submitting a series of commits for review rather than a single commit.
This is useful for example when you are working on a series of dependent
changes which go together. This also gets around the baffling use of
commit amends as a way to fix problems. Other reasonable ways of
making changes are by adding commits that fix the problems highlighted
on a review. This could be supported when a topic branch is a unit of
review. Then the appropriate action on a review is to submit fixes. In
fact, I would think that a reasonable design of a review tool would
automatically branch a commit when a reviewer suggests a fix. If the
reviewer finds the commit acceptable, the commit goes through without a
branch.

(b) Commit amends hide evolution of an idea and the tradeoffs and
considerations that went into development of something -- the reviews
are all separate from git commit history. All that is seen is the
final amended commit -- the discussion and the arguments even that
inform the commit are lost. Instead, if as in (a), a topic branch was
explicitly (or automatically created when a reviewer rejects a commit),
and fixes are additional commits, then, review documentation could be
part of the commit history of git and shows the considerations that went
into developing something and the evolution of an idea.

There was an email recently on wikitext-l where Mark Bergsma was asked
to squash his commits
(http://osdir.com/ml/general/2012-07/msg20847.html) -- I personally
think it is a bad idea that is a result of the gerrit review model. In
a different review model, a suggestion like this would not be made.

More than the UI, it is (a) and (b) which bother me more. I am not
sure if any existing review tool out there supports such a review
process, but if there is, I would support one.

Subbu.
> Hi everyone,
>
> It appears as though the discussion has continued apace for the Gerrit
> evaluation process:
> http://www.mediawiki.org/wiki/Git/Gerrit_evaluation
>
> Thank you everyone for chipping in so far. The current format is a
> mix of talk page and structured discussion, which seems ok for now.
>
> It would appear from reading this page that the only alternative to
> Gerrit that has a serious following is GitHub. Is that the case?
> Personally, it seems like Phabricator or Barkeep has the best chance
> of dislodging Gerrit, but those won't probably get serious
> consideration without a champion pushing them.
>
> Rob
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


roan.kattouw at gmail

Jul 18, 2012, 9:35 PM

Post #17 of 77 (5286 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, Jul 18, 2012 at 9:30 PM, Subramanya Sastry
<ssastry [at] wikimedia> wrote:
> (b) Commit amends hide evolution of an idea and the tradeoffs and
> considerations that went into development of something -- the reviews are
> all separate from git commit history. All that is seen is the final
> amended commit -- the discussion and the arguments even that inform the
> commit are lost. Instead, if as in (a), a topic branch was explicitly (or
> automatically created when a reviewer rejects a commit), and fixes are
> additional commits, then, review documentation could be part of the commit
> history of git and shows the considerations that went into developing
> something and the evolution of an idea.
>
> There was an email recently on wikitext-l where Mark Bergsma was asked to
> squash his commits (http://osdir.com/ml/general/2012-07/msg20847.html) -- I
> personally think it is a bad idea that is a result of the gerrit review
> model. In a different review model, a suggestion like this would not be
> made.
>
Although squashing and amending has downsides, there is also an
advantage: now that Jenkins is set up properly for mediawiki/core.git
, we will never put commits in master that don't pass the tests. With
the fixup commit model, intermediate commits often won't pass the
tests or even lint, which leads to false positives in git bisect and
makes things like rolling back deployments harder.

Roan

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


ssastry at wikimedia

Jul 18, 2012, 10:35 PM

Post #18 of 77 (5331 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On 07/18/2012 11:35 PM, Roan Kattouw wrote:
> On Wed, Jul 18, 2012 at 9:30 PM, Subramanya Sastry
> <ssastry [at] wikimedia> wrote:
>> (b) Commit amends hide evolution of an idea and the tradeoffs and
>> considerations that went into development of something -- the reviews are
>> all separate from git commit history. All that is seen is the final
>> amended commit -- the discussion and the arguments even that inform the
>> commit are lost. Instead, if as in (a), a topic branch was explicitly (or
>> automatically created when a reviewer rejects a commit), and fixes are
>> additional commits, then, review documentation could be part of the commit
>> history of git and shows the considerations that went into developing
>> something and the evolution of an idea.
>>
>> There was an email recently on wikitext-l where Mark Bergsma was asked to
>> squash his commits (http://osdir.com/ml/general/2012-07/msg20847.html) -- I
>> personally think it is a bad idea that is a result of the gerrit review
>> model. In a different review model, a suggestion like this would not be
>> made.
>>
> Although squashing and amending has downsides, there is also an
> advantage: now that Jenkins is set up properly for mediawiki/core.git
> , we will never put commits in master that don't pass the tests. With
> the fixup commit model, intermediate commits often won't pass the
> tests or even lint, which leads to false positives in git bisect and
> makes things like rolling back deployments harder.

Agree somewhat. But, two things to consider:

(a) Not all commits that are reviewed break tests. I am not arguing
that amends and squashing via rebase dont have a place. I am arguing
that amends are overused right now. Where commits break an existing
test suite, part of the review requirement could be that the previous
commit be amended so it passes tests. But, applying this logic in all
cases doesn't seem right to me.

(b) What happens if I submit a new test that breaks HEAD? Are we
arguing that the test cannot be committed till HEAD passes all tests?
Will my test be held in abeyance till someone gets around to fixing HEAD?

I think there is an argument to be made for a non-straitjacketed
approach to review: always pre-commit review, commit is always a single
unit of review, always amend commits, always squash multiple commits --
this is the gerrit model which I am chafing against.

I am new here and I also have limited exposure to review tools and
processes, so I dont want to overstate my case. I also understand that
this is not a simple problem, and maybe this is the best we have -- but
I at least want to express my annoyance with what we have, and that we
should reduce this to being entirely an UI issue (which is important in
and of itself).

Also, my gratitude to all of you who have previously spent the time
instituting processes and tools -- it is better than nothing, and it can
be a thankless job with people like me griping :) but my intention here
is to only help this forward where I can. Can I work with what we
have? Yes, I can. Will I be happier with a different process / tool?
Yes, I will be :).

Subbu.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Jul 18, 2012, 10:37 PM

Post #19 of 77 (5283 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, 18 Jul 2012 21:35:00 -0700, Roan Kattouw <roan.kattouw [at] gmail>
wrote:

> On Wed, Jul 18, 2012 at 9:30 PM, Subramanya Sastry
> <ssastry [at] wikimedia> wrote:
>> (b) Commit amends hide evolution of an idea and the tradeoffs and
>> considerations that went into development of something -- the reviews
>> are
>> all separate from git commit history. All that is seen is the final
>> amended commit -- the discussion and the arguments even that inform the
>> commit are lost. Instead, if as in (a), a topic branch was explicitly
>> (or
>> automatically created when a reviewer rejects a commit), and fixes are
>> additional commits, then, review documentation could be part of the
>> commit
>> history of git and shows the considerations that went into developing
>> something and the evolution of an idea.
>>
>> There was an email recently on wikitext-l where Mark Bergsma was asked
>> to
>> squash his commits (http://osdir.com/ml/general/2012-07/msg20847.html)
>> -- I
>> personally think it is a bad idea that is a result of the gerrit review
>> model. In a different review model, a suggestion like this would not be
>> made.
>>
> Although squashing and amending has downsides, there is also an
> advantage: now that Jenkins is set up properly for mediawiki/core.git
> , we will never put commits in master that don't pass the tests. With
> the fixup commit model, intermediate commits often won't pass the
> tests or even lint, which leads to false positives in git bisect and
> makes things like rolling back deployments harder.
>
> Roan

I don't see this as a case against not-squashing commits.
The fact that previous commits are broken is not a bug. It's a fact of
development and history that MUST be accepted rather than covered up.
Making sure that every single commit inside the repo passes test does NOT
matter. The only thing that matters is that final commits that we merge
into the master branch pass tests. In other words only the actual commits
(ie: merge commits) directly committed to the master branch should be
required to pass tests, not the potentially broken commits they are based
on.
If you are bisecting and trying to track down an issue you should NOT be
randomly going down every topic branch and testing it. If you test the
commit from which the topic branch was merged into master and it comes
back OK then you should ignore the topic branch since those were never
directly part of master and are not the source of your bug. You should
continue down master until you hit the topic/merge commit that introduced
the bug directly into master.

Frankly while it may look odd my recommendation is to make use of --no-ff
to ensure that the commit that actually goes into master is not the HEAD
of the topic branch but a merge commit. Even if there is no rebasing or
merging needed. This helps keep a clean line where you can trust that
everything inside master was explicitly committed there. And instead of
having random cases where either a commit is directly put into master or
you get some commit saying something like "merged from" just because of
some conflicts. You instead end up with your merge commits becoming a
proofread and edited version that's gone through the final review,
testing, and been approved by everyone.

One of the ideas I had for Gareth was to let a commit message be
web-editable on the review page. The commit message would be based on the
original commit's commit message. Afterwards anyone could contribute to
the commit message in the web view and make tweaks to it. Instead of
forcing someone to amend a commit to change the commit message you would
just make a tweak to the commit message displayed on the review page. You
could easily re-word it a bit, add some items not included in the original
(eg: you added a new feature in a follow up commit), and fix any typos the
original committer made. When the review/topic branch is okayed and
accepted into master Gareth would use --no-ff to force Git to create a
brand new commit for the merge and it would use the commit message that
everyone made edits to as the commit message for that merge commit instead
of some "merged from" message.
Then master would become a clean vetted linear history. And when you
wanted to learn the history of an individual addition to the codebase you
would follow the parents of that commit into the review branch that was
merged into master.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Jul 18, 2012, 11:27 PM

Post #20 of 77 (5338 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Wed, 18 Jul 2012 22:37:56 -0700, Daniel Friesen
<lists [at] nadir-seen-fire> wrote:

> On Wed, 18 Jul 2012 21:35:00 -0700, Roan Kattouw
> <roan.kattouw [at] gmail> wrote:
>
>> On Wed, Jul 18, 2012 at 9:30 PM, Subramanya Sastry
>> <ssastry [at] wikimedia> wrote:
>>> (b) Commit amends hide evolution of an idea and the tradeoffs and
>>> considerations that went into development of something -- the reviews
>>> are
>>> all separate from git commit history. All that is seen is the final
>>> amended commit -- the discussion and the arguments even that inform the
>>> commit are lost. Instead, if as in (a), a topic branch was explicitly
>>> (or
>>> automatically created when a reviewer rejects a commit), and fixes are
>>> additional commits, then, review documentation could be part of the
>>> commit
>>> history of git and shows the considerations that went into developing
>>> something and the evolution of an idea.
>>>
>>> There was an email recently on wikitext-l where Mark Bergsma was asked
>>> to
>>> squash his commits (http://osdir.com/ml/general/2012-07/msg20847.html)
>>> -- I
>>> personally think it is a bad idea that is a result of the gerrit review
>>> model. In a different review model, a suggestion like this would not
>>> be
>>> made.
>>>
>> Although squashing and amending has downsides, there is also an
>> advantage: now that Jenkins is set up properly for mediawiki/core.git
>> , we will never put commits in master that don't pass the tests. With
>> the fixup commit model, intermediate commits often won't pass the
>> tests or even lint, which leads to false positives in git bisect and
>> makes things like rolling back deployments harder.
>>
>> Roan
>
> I don't see this as a case against not-squashing commits.
> The fact that previous commits are broken is not a bug. It's a fact of
> development and history that MUST be accepted rather than covered up.
> Making sure that every single commit inside the repo passes test does
> NOT matter. The only thing that matters is that final commits that we
> merge into the master branch pass tests. In other words only the actual
> commits (ie: merge commits) directly committed to the master branch
> should be required to pass tests, not the potentially broken commits
> they are based on.
> If you are bisecting and trying to track down an issue you should NOT be
> randomly going down every topic branch and testing it. If you test the
> commit from which the topic branch was merged into master and it comes
> back OK then you should ignore the topic branch since those were never
> directly part of master and are not the source of your bug. You should
> continue down master until you hit the topic/merge commit that
> introduced the bug directly into master.
>
> Frankly while it may look odd my recommendation is to make use of
> --no-ff to ensure that the commit that actually goes into master is not
> the HEAD of the topic branch but a merge commit. Even if there is no
> rebasing or merging needed. This helps keep a clean line where you can
> trust that everything inside master was explicitly committed there. And
> instead of having random cases where either a commit is directly put
> into master or you get some commit saying something like "merged from"
> just because of some conflicts. You instead end up with your merge
> commits becoming a proofread and edited version that's gone through the
> final review, testing, and been approved by everyone.
>
> One of the ideas I had for Gareth was to let a commit message be
> web-editable on the review page. The commit message would be based on
> the original commit's commit message. Afterwards anyone could contribute
> to the commit message in the web view and make tweaks to it. Instead of
> forcing someone to amend a commit to change the commit message you would
> just make a tweak to the commit message displayed on the review page.
> You could easily re-word it a bit, add some items not included in the
> original (eg: you added a new feature in a follow up commit), and fix
> any typos the original committer made. When the review/topic branch is
> okayed and accepted into master Gareth would use --no-ff to force Git to
> create a brand new commit for the merge and it would use the commit
> message that everyone made edits to as the commit message for that merge
> commit instead of some "merged from" message.
> Then master would become a clean vetted linear history. And when you
> wanted to learn the history of an individual addition to the codebase
> you would follow the parents of that commit into the review branch that
> was merged into master.
>

Here's an example of the flow I mean:
https://www.mediawiki.org/wiki/User:Dantman/Git/FastForward-vs-no-ff

On the left is the normal project flow. You make changes to the topic
branch and at the end merge it into the master branch. When you do so
because there are no conflicts all the commits in the topic branch become
part of master. Not necessarily what you want.

On the right is the flow I consider ideal for large projects like
MediaWiki. The pattern follows the exact same pattern as the left. You
make changes into the topic branch and then at the end merge it into
master. But this time when you do the merge (or rather the review system
does) you use --no-ff and add a customized message with an overview of all
the changes in the topic branch that got merged into master (This
essentially becomes your proofread and edited final commit that everyone
sees).
As a result of --no-ff:
- None of the individual changes which weren't guaranteed to have passed
tests made their way into master.
- You have a very clean overview of the branch as the actual commit in
master leading to a tidy history that everyone can understand.
- The entire history of the project is contained, including the small
tweaks that everyone has made. And no-one ends up overriding a commiter's
name with their own because they fixed a typo.
- Anyone trying to bisect can simply ignore the individual irrelevant
commits inside of a topic branch and just test master itself. (In fact at
this level you can probably find some way to use a test-suite to
auto-bisect a codebase using a simple test case and running it over the
history of the repo)

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


mail at tgries

Jul 18, 2012, 11:42 PM

Post #21 of 77 (5283 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

Perhaps its is possible and much simplier to write a kind of
"gateway/interface" framework
between the old svn codereview tool, which gives comitters and reviewers
the

/_look and feel of the old cr tools_/

but accesses the present repo on GitHub.
Attachments: signature.asc (0.48 KB)


krinklemail at gmail

Jul 19, 2012, 11:21 AM

Post #22 of 77 (5329 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Jul 18, 2012, at 9:35 PM, Roan Kattouw wrote:

> On Wed, Jul 18, 2012 at 9:30 PM, Subramanya Sastry
> <ssastry [at] wikimedia> wrote:
>> (b) Commit amends hide evolution of an idea and the tradeoffs and
>> considerations that went into development of something -- the reviews are
>> all separate from git commit history. All that is seen is the final
>> amended commit -- the discussion and the arguments even that inform the
>> commit are lost. Instead, if as in (a), a topic branch was explicitly (or
>> automatically created when a reviewer rejects a commit), and fixes are
>> additional commits, then, review documentation could be part of the commit
>> history of git and shows the considerations that went into developing
>> something and the evolution of an idea.
>>
>> There was an email recently on wikitext-l where Mark Bergsma was asked to
>> squash his commits (http://osdir.com/ml/general/2012-07/msg20847.html) -- I
>> personally think it is a bad idea that is a result of the gerrit review
>> model. In a different review model, a suggestion like this would not be
>> made.
>>
>
> Although squashing and amending has downsides, there is also an
> advantage: now that Jenkins is set up properly for mediawiki/core.git
> , we will never put commits in master that don't pass the tests. With
> the fixup commit model, intermediate commits often won't pass the
> tests or even lint, which leads to false positives in git bisect and
> makes things like rolling back deployments harder.
>
> Roan
>

I disagree. Contrary to what many think, every single patch set and amendment
goes into the mediawiki/core.git repository, whether reviewed and passing, or
a fresh mistake. This is easily verified by the fact that every patch set
revision has its own gitweb link, and the fact that git-review downloads the
merge request from a remote branch, inside the core.git repo (or whatever the
repo may be).

git-bisect is not an issue now and won't be an issue in the branch-review
model[1], because git-bisect only affects the HEAD's tree (naturally). The way to
merge a branch would be to squash the branch into one commit when merging
(e.g. the "merge" commit). This is also how jQuery lands branches most of the
time, and iirc GitHub (as in, the internal repo github.com/github/github) also
works this way with long-lived branches (based on a presentation they gave;
"How GitHub uses GitHub to build GitHub"[2]).

And, of course, we will stick to the model of only allowing merges when tests
pass. So the HEAD's history will remain free of commits that don't pass
tests.

One could argue that then the branches' history will not be included in the
master's history, but that's not the case now either. Because only the last
amendment will be in the master's history (which is just as much a squash,
except that that squash is the result if re-ammending over and over again,
instead of subsequent commits being squashed afterwards).

-- Krinkle


[1] "branch-review model", as in, a model where a review is about a
topic-branch, whether it contains 1 commit, or many. Or even a branch from a
fork. In other words the pull-request model from GitHub. And yes, on GitHub
one can also create a pull-request from one branch to another, within the same
repository (e.g. mediawiki-core/feature-x -> mediawiki-core/master or
mediawiki-core/feature-x-y-z -> mediawiki-core/feature-x) .

[2] http://zachholman.com/talk/how-github-uses-github-to-build-github

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


ssastry at wikimedia

Jul 19, 2012, 11:53 AM

Post #23 of 77 (5284 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

> [1] "branch-review model", as in, a model where a review is about a
> topic-branch, whether it contains 1 commit, or many. Or even a branch from a
> fork. In other words the pull-request model from GitHub. And yes, on GitHub
> one can also create a pull-request from one branch to another, within the same
> repository (e.g. mediawiki-core/feature-x -> mediawiki-core/master or
> mediawiki-core/feature-x-y-z -> mediawiki-core/feature-x) .
>
> [2] http://zachholman.com/talk/how-github-uses-github-to-build-github

Oh, I didn't know that pull requests could be used without forks. So,
yes pull requests provide branch reviews and the added benefit is that
non-coders can get involved in the discussion as well and keeps
everything in one place, if you are looking at UI design, for ex.

Subbu.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


erik at wikimedia

Jul 19, 2012, 11:58 AM

Post #24 of 77 (5331 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

On Tue, Jul 17, 2012 at 5:41 PM, Rob Lanphier <robla [at] wikimedia> wrote:
> It would appear from reading this page that the only alternative to
> Gerrit that has a serious following is GitHub. Is that the case?
> Personally, it seems like Phabricator or Barkeep has the best chance
> of dislodging Gerrit, but those won't probably get serious
> consideration without a champion pushing them.

What are people's experiences with Gitorious? Does it seem
sufficiently hackable to perhaps meet our needs, or does it have too
many architectural flaws to be worthwhile?

Here are a few things I've been able to find out from poking at it:

* Unlike GitHub, it's fully open source (AGPL).
* It's a Ruby on Rails codebase with lots of gem dependencies and a
reputation for being hard to install (haven't tried it).
* Like GitHub/Gerrit, it's not just a code review tool, but also
manages repositories.
* Like GitHub, it makes it easy to clone/fork entire repos and send a
merge request for a series of commits, encouraging true decentralized
development.
* It supports both individual clones and team clones.
* Like most tools, it supports inline comments in code review:
http://blog.gitorious.org/2009/11/06/awesome-code-review/
* Unlike Gerrit, it conveniently shows all diffs for a commit on a
single page, e.g.:
https://gitorious.org/gitorious/mainline/merge_requests/208
* Unlike GitHub/Gerrit, it has no easy way to integrate merge requests
-- developers have to do so manually using git commands (see the "how
to apply this merge request" box in the page above). The process seems
particularly cumbersome for small patchsets, of which we get a lot.
* It appears to have limited private repo support:
http://blog.gitorious.org/2012/02/29/private-repositories-2/
* It has a semi-active upstream: https://gitorious.org/gitorious/mainline
* Its UI appears less clunky and vomit-inducing than Gerrit's, but it
doesn't exactly feel like the most responsive & efficient design
either. There are some niceties, like breadcrumb navigation, avatars,
etc.

From what I can tell, we have essentially three choices:

* Continue to work with the heavily centralized and clunky Gerrit
workflow, and try to beat it into shape to not cause us too much pain,
while seeing people increasingly move into GitHub for doing
experimental projects. Hope for Gerrit's large developer base to
ultimately join a rewrite effort, or to incrementally make it better.
Build Gerrit/GitHub bridges if possible.

* Drink the kool-aid and join the wonderful semi-open world of GitHub,
with all the risks and benefits it entails.

* Help build a realistic alternative to GitHub, probably by building
on the open source toolset that's the closest right now in terms of
its overall architectural approach and existing functionality. (My
impression: Gitorious is closer in functionality but at a lower
overall quality, Phabricator/Barkeep are much more limited in
functionality right now and therefore would take a long time to be
usable with our current workflow assumptions.)

Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


marktraceur at riseup

Jul 19, 2012, 12:10 PM

Post #25 of 77 (5330 views)
Permalink
Re: Serious alternatives to Gerrit [In reply to]

> * It's a Ruby on Rails codebase with lots of gem dependencies and a
> reputation for being hard to install (haven't tried it).

I can vouch for this in a limited fashion, I spent around an hour one
day trying to get it working, and gave up. This has been my experience
with 90% of Ruby projects, however, so I wouldn't judge Gitorious for
this. I had similar trouble with Barkeep. I was only barely able to get
Diaspora running.

> * Like GitHub/Gerrit, it's not just a code review tool, but also
> manages repositories.

The advantage over Gerrit is that Gitorious also has project wikis
(however useful that is over mw.org), and the disadvantage behind GitHub
is that it doesn't have an issue tracker (though bz.wm.org should
suffice as always).

> * Unlike GitHub/Gerrit, it has no easy way to integrate merge requests
> -- developers have to do so manually using git commands (see the "how
> to apply this merge request" box in the page above). The process seems
> particularly cumbersome for small patchsets, of which we get a lot.

This is possibly the most troublesome thing about it all--it would
require manual rebase/merge before being able to accept a patch. That
would certainly be a blocker, I'd say, but it might be possible to port
the auto-merge and the revered "rebase button" from Gerrit over to
Gitorious. Maybe a bit of effort, but it could be worth it.

> [We could d]rink the kool-aid and join the wonderful semi-open world of GitHub,
> with all the risks and benefits it entails.

This is quite a nasty flavor of Kool-Aid, I'd say--but having more
contributors, accomplished by whatever means, might be worth it. If
there is a free alternative, and we are able to live with it (be it
Gerrit, Barkeep, Phabricator, or whatever else), that seems like the
better option to me right now.

Just a couple of pennies,

--
Mark Holmquist
Contractor, Wikimedia Foundation
mtraceur [at] member
http://marktraceur.info

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

First page Previous page 1 2 3 4 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.