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

Mailing List Archive: Wikipedia: Wikitech

Criteria for "serious alternative"

 

 

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


robla at wikimedia

Jul 26, 2012, 11:27 AM

Post #1 of 36 (1350 views)
Permalink
Criteria for "serious alternative"

On Thursday, July 26, 2012, Faidon Liambotis wrote:

> This is not to you specifically but as a general remark: there are
> multiple other alternatives that have been mentioned besides Gerrit and
> GitHub with a potential of getting the best of both worlds. I think it's
> better to not polarize the discussion between the two most popular
> options at this point and talk about all options.


Nice segue into a topic that I've been meaning to get to. :) Right now,
the serious alternatives seem to be:
* Sticking with Gerrit (with GitHub integration)
* Moving fully to GitHub
* Moving to Phabricator (though the proposal is pretty thin right now)

Nothing else has been advocated with a degree of seriousness as to warrant
consideration at this point. That's not to say we're done with those
options; if someone wants to put together a serious proposal, there's still
a little time. However, in order to practically consider the alternatives,
we need to have the serious proposals enumerated, and a credible plan for
addressing any deficiencies.

I've gone through and modified the criteria, splitting up the MUSTs from
the SHOULDs:
http://www.mediawiki.org/wiki/Git/Gerrit_evaluation

Even the "sticking with Gerrit" section is currently thin on credibly
meeting the criteria, so we'll have to beef up our stated plan for getting
it up-to-snuff.

Here's the timeline I'd like to propose:
* July 30, noon PDT - reasonably complete draft sections need to be in
place
* August 1, 9am PDT - complete proposals due

A few of us are planning to meet Monday afternoon to figure out exactly
what the rest of the process looks like, so that first deadline is going to
be very important for understanding how many options we're truly
considering.

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


faidon at wikimedia

Jul 26, 2012, 12:49 PM

Post #2 of 36 (1329 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Thu, Jul 26, 2012 at 11:27:44AM -0700, Rob Lanphier wrote:
> Nothing else has been advocated with a degree of seriousness as to warrant
> consideration at this point. That's not to say we're done with those
> options; if someone wants to put together a serious proposal, there's still
> a little time. However, in order to practically consider the alternatives,
> we need to have the serious proposals enumerated, and a credible plan for
> addressing any deficiencies.

I don't understand. I thought we were collecting problems and *ideas* on
how to solve them, not solid plans for a migration.

You're basically comparing two options that have little or no work
involved (not changing Gerrit, moving to an externally-maintained
service that most of us know how it works) vs. plans that need *time* to
install, play with and evaluate.

Has anyone been allocated to that task? I don't like either of the two
options but don't think I can just stop what I'm doing and spend a week
evaluating e.g. Gitlab, Barkeep and Phabricator just to present my
argument (or counterargument) to the Wiki page.

My understanding of the process was that we would collect a broad set of
arguments/ideas/proposals and people would be later assigned to the task
of evaluating them and proposing a viable solution and a migration path
(or not, and propose that we stay with Gerrit).

The wiki page seems to also imply something like that by saying:
Brion Vibber will lead this evaluation, with help from Chad Horohoe
and David Schoonover.

If it's me that misunderstood that's fine and I'm sorry. I'll just feel
a bit silly for trying to argue for an impossible outcome :)

Regards,
Faidon

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


z at mzmcbride

Jul 26, 2012, 7:04 PM

Post #3 of 36 (1292 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

Rob Lanphier wrote:
> A few of us are planning to meet Monday afternoon to figure out exactly
> what the rest of the process looks like, so that first deadline is going to
> be very important for understanding how many options we're truly
> considering.

Well, at least you're being open about not being open.

It's somewhat ironic that you have a group of people who regularly champion
the virtues of open source software ("you can hack the code!") who have
picked a software solution that's (apparently) nearly impossible to modify.
Even eliminating Gerrit's vomit color scheme would be a vast improvement,
but as I understand it, even basic CSS changes are a no-go with Gerrit.

A few people on this list have gone so far as to say "but the next release
is always better!" I realize I was being a bit tongue-in-cheek by suggesting
earlier that Gerrit's UI was developed by Microsoft, but to have developers
now spouting corporate justifications for shitty software? I'm left to
wonder what the hell happened.

I'm lost as to how Gerrit was ever considered an option previously and how
it's still an option on the table today, given its apparent inflexibility.
Say what you will about MediaWiki's CodeReview extension, but on its worst
day, it never garnered as much resentment as Gerrit.

MZMcBride



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


innocentkiller at gmail

Jul 26, 2012, 7:10 PM

Post #4 of 36 (1324 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Thu, Jul 26, 2012 at 10:04 PM, MZMcBride <z [at] mzmcbride> wrote:
> Rob Lanphier wrote:
> It's somewhat ironic that you have a group of people who regularly champion
> the virtues of open source software ("you can hack the code!") who have
> picked a software solution that's (apparently) nearly impossible to modify.
> Even eliminating Gerrit's vomit color scheme would be a vast improvement,
> but as I understand it, even basic CSS changes are a no-go with Gerrit.
>

Can you please stop saying things about Gerrit that are just patently
untrue? I've taken many times to explain why these statements aren't
true.

Gerrit's source is not impregnable, I've found it very easy to begin
contributing upstream. Not to mention, most people don't bother to
contribute upstream anyway.

CSS is customizable and it's customizable now. Nobody's bothered
to do so, however. I welcome suggestions, but nobody's said anything
to me about things they'd like done.

-Chad

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


rlane32 at gmail

Jul 26, 2012, 9:38 PM

Post #5 of 36 (1319 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Thu, Jul 26, 2012 at 7:04 PM, MZMcBride <z [at] mzmcbride> wrote:
> Rob Lanphier wrote:
>> A few of us are planning to meet Monday afternoon to figure out exactly
>> what the rest of the process looks like, so that first deadline is going to
>> be very important for understanding how many options we're truly
>> considering.
>
> Well, at least you're being open about not being open.
>

Well, it's very likely the staff that will end up doing the work.
Also, we're meeting to figure out the rest of the process. We're not
making a decision. So far the entire process has been in the open, and
will continue to be so. Good to see you're assuming good faith, though
;).

You've already admitted that you don't use Gerrit, so do you have a
really large stake in this?

> It's somewhat ironic that you have a group of people who regularly champion
> the virtues of open source software ("you can hack the code!") who have
> picked a software solution that's (apparently) nearly impossible to modify.
> Even eliminating Gerrit's vomit color scheme would be a vast improvement,
> but as I understand it, even basic CSS changes are a no-go with Gerrit.
>
> A few people on this list have gone so far as to say "but the next release
> is always better!" I realize I was being a bit tongue-in-cheek by suggesting
> earlier that Gerrit's UI was developed by Microsoft, but to have developers
> now spouting corporate justifications for shitty software? I'm left to
> wonder what the hell happened.
>

Every release *has* been much better and the releases are often, and
that's a great thing. It's not a corporate justification, it's
reality. Having a really responsive and active upstream is awesome.

We have other pieces of infrastructure that are similar. Take bugzilla
for instance. We don't really modify it much, we don't think its
interface is great, but we're thankful when upstream changes help us.
Also, there's no really great alternative to bugzilla. We've had
numerous discussions about replacing bugzilla, and the discussion
always dies out because the alternatives are just as bad or worse. We
use what works and generally only change things when there's a really
strong justification for doing so.

> I'm lost as to how Gerrit was ever considered an option previously and how
> it's still an option on the table today, given its apparent inflexibility.
> Say what you will about MediaWiki's CodeReview extension, but on its worst
> day, it never garnered as much resentment as Gerrit.
>

It was considered because it worked and it was better than any
alternatives we found. It was easy to integrate into our toolsets with
minimal effort. Other solutions would have required extensive code
changes which we honestly don't have time to make.

I know people complain about Gerrit a lot, but I personally find it
much better than our previous toolset. We couldn't have reasonably
opened our ops infrastructure without some form of pre-merge review.
Also, we can much more easily give people accounts. In our previous
workflow SVN access required developers to have prior code examples,
and we have to approve them to ensure they wouldn't submit insecure
code. We can just give people accounts now, and we eventually allow
people to self-register as well. In fact, this is one of my top goals
after upgrading openstack and adding a new Labs zone in eqiad.

- Ryan

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


z at mzmcbride

Jul 26, 2012, 10:57 PM

Post #6 of 36 (1322 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

Ryan Lane wrote:
> You've already admitted that you don't use Gerrit, so do you have a
> really large stake in this?

Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most
people, I think I would use Gerrit more if it weren't so awful. Just tonight
I was trying to get an index of Gerrit contributors (owners, I guess the
term is). Something similar to this list from the SVN system:
<https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author>. Apparently
Gerrit doesn't have a feature to list authors like this. All I wanted to do
was find a particular user and look at his contributions. And, as usual, it
took twenty minutes instead of ten seconds because Gerrit sucks.

How does anyone use Gerrit?

> Every release *has* been much better and the releases are often, and
> that's a great thing. It's not a corporate justification, it's
> reality. Having a really responsive and active upstream is awesome.

You'll have to forgive me, but the only way I can read this is, "the car now
breaks down two minutes into the journey; it used to break down a minute
in!"

> I know people complain about Gerrit a lot, but I personally find it
> much better than our previous toolset.

I think a lot of people are frustrated by the fact that the types of
problems being encountered in Gerrit would typically be trivial to fix (CSS
precedence, for example). The fact that they're not runs against a lot of
core Wikimedia principles.

> We can just give people accounts now, and we eventually allow
> people to self-register as well. In fact, this is one of my top goals
> after upgrading openstack and adding a new Labs zone in eqiad.

Yes, self-registration would be fantastic. :-) I commented on this bug last
Saturday: <https://bugzilla.wikimedia.org/show_bug.cgi?id=37628> ("Creating
a Git/Gerrit/Labs account requires human intervention"). I realize that you
and the other ops folks are busy, but if someone could at least explain the
current process, it would give volunteer developers a fighting chance of
helping out. Not having the faintest idea how the current account creation
process works, I can't help or find anyone to help make it better.

MZMcBride



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


robla at wikimedia

Jul 26, 2012, 11:36 PM

Post #7 of 36 (1284 views)
Permalink
Criteria for "serious alternative" [In reply to]

On Thu, Jul 26, 2012 at 12:49 PM, Faidon Liambotis <faidon [at] wikimedia>wrote:

> My understanding of the process was that we would collect a broad set of
> arguments/ideas/proposals and people would be later assigned to the task
> of evaluating them and proposing a viable solution and a migration path
> (or not, and propose that we stay with Gerrit).
>

Hi Faidon,

Yes, we're seeking a broad range of proposals. However, "proposals" is the
key word. That means looking the requirements, reading the website and
matching against those requirements, and stitching together something that
at least looks good on paper. I'm not expecting anyone to set up a
prototype, but I am asking that, given how long we've been talking about
this, that we narrow down our options a bit to the things that we know are
worth looking at rather than (still, a year later) having the "have you
looked at this?" discussion again.

As far as "people being assigned to the the task of evaluating them", I
think you may be overestimating the number of people we have floating
around to do this work. "People" is basically Chad, who is pretty burnt
out on working on this, and is exasperated with this process, but without
drafting someone outside my group (like you?) :), I don't have many
options. Having Chad do this means taking one of our most experienced
MediaWiki developers, and having him not work on MediaWiki, but instead, do
more evaluation of code review tools.

Before doing that to Chad, I'm asking people who believe passionately that
we need to move off Gerrit to actually tell us what they'd like to move to
in a structured, constructive way. I don't think that's too much to ask.

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


rlane32 at gmail

Jul 26, 2012, 11:43 PM

Post #8 of 36 (1285 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride <z [at] mzmcbride> wrote:
> Ryan Lane wrote:
>> You've already admitted that you don't use Gerrit, so do you have a
>> really large stake in this?
>
> Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most
> people, I think I would use Gerrit more if it weren't so awful. Just tonight
> I was trying to get an index of Gerrit contributors (owners, I guess the
> term is). Something similar to this list from the SVN system:
> <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author>. Apparently
> Gerrit doesn't have a feature to list authors like this. All I wanted to do
> was find a particular user and look at his contributions. And, as usual, it
> took twenty minutes instead of ten seconds because Gerrit sucks.
>

So, you found something you'd like added to the software: a user list.
Have you entered a bug? The problem you are encountering is that you
are used to a piece of software, and the new software doesn't have the
exact same feature set. This happens, and will happen with any new
tool if we switch, too.

There's an open bug for this:

https://bugzilla.wikimedia.org/show_bug.cgi?id=35508

Note that the bug mentions a number of ways you can get a user list
outside of Gerrit. I think it would be nice to have Gerrit itself have
the user list interface. With extension support in Gerrit 2.5, we may
be able to implement it ourselves.

> How does anyone use Gerrit?
>

I use it successfully every single day. I review code, I add changes,
I get statistics on repos. It works well for me. Guess what? I find
the old code review system to be just as hard to use as Gerrit. Know
why? I didn't use the old code review system much.

>> Every release *has* been much better and the releases are often, and
>> that's a great thing. It's not a corporate justification, it's
>> reality. Having a really responsive and active upstream is awesome.
>
> You'll have to forgive me, but the only way I can read this is, "the car now
> breaks down two minutes into the journey; it used to break down a minute
> in!"
>

This is a fallacious argument. For most use cases Gerrit works
perfectly well. The fixes coming in each release are easing some of
the use cases that don't work so well.

Maybe as a non-developer Gerrit doesn't do what you want. As a
developer it does most of what I want. It doesn't do some things I
want, though. I want free-form tagging, for instance, which is on the
roadmap for a future release (and Chad has already started adding in
code that is required for this feature).

>> I know people complain about Gerrit a lot, but I personally find it
>> much better than our previous toolset.
>
> I think a lot of people are frustrated by the fact that the types of
> problems being encountered in Gerrit would typically be trivial to fix (CSS
> precedence, for example). The fact that they're not runs against a lot of
> core Wikimedia principles.
>

As mentioned at least twice already in these threads, this is simply
not true. It's possible to fix the CSS right now (and if you look at
OpenStack's Gerrit, you'd notice they've already done so).

>> We can just give people accounts now, and we eventually allow
>> people to self-register as well. In fact, this is one of my top goals
>> after upgrading openstack and adding a new Labs zone in eqiad.
>
> Yes, self-registration would be fantastic. :-) I commented on this bug last
> Saturday: <https://bugzilla.wikimedia.org/show_bug.cgi?id=37628> ("Creating
> a Git/Gerrit/Labs account requires human intervention"). I realize that you
> and the other ops folks are busy, but if someone could at least explain the
> current process, it would give volunteer developers a fighting chance of
> helping out. Not having the faintest idea how the current account creation
> process works, I can't help or find anyone to help make it better.
>

I could have sworn there was another bug open for this that documented
what needed to get done. I just spent a few minutes updating the bug.
It's likely a fairly small OpenStackManager change, and a labsconsole
configuration change. As mentioned it's on my list after Labs
upgrades. If someone else wants to tackle it first, I'd love that.

- Ryan

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


lists at nadir-seen-fire

Jul 27, 2012, 12:13 AM

Post #9 of 36 (1320 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Thu, 26 Jul 2012 23:43:51 -0700, Ryan Lane <rlane32 [at] gmail> wrote:

> On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride <z [at] mzmcbride> wrote:
>> Ryan Lane wrote:
>>> You've already admitted that you don't use Gerrit, so do you have a
>>> really large stake in this?
>>
>> Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like
>> most
>> people, I think I would use Gerrit more if it weren't so awful. Just
>> tonight
>> I was trying to get an index of Gerrit contributors (owners, I guess the
>> term is). Something similar to this list from the SVN system:
>> <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author>.
>> Apparently
>> Gerrit doesn't have a feature to list authors like this. All I wanted
>> to do
>> was find a particular user and look at his contributions. And, as
>> usual, it
>> took twenty minutes instead of ten seconds because Gerrit sucks.
>>
>
> So, you found something you'd like added to the software: a user list.
> Have you entered a bug? The problem you are encountering is that you
> are used to a piece of software, and the new software doesn't have the
> exact same feature set. This happens, and will happen with any new
> tool if we switch, too.
>
> There's an open bug for this:
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=35508
>
> Note that the bug mentions a number of ways you can get a user list
> outside of Gerrit. I think it would be nice to have Gerrit itself have
> the user list interface. With extension support in Gerrit 2.5, we may
> be able to implement it ourselves.
>
>> How does anyone use Gerrit?
>>
>
> I use it successfully every single day. I review code, I add changes,
> I get statistics on repos. It works well for me. Guess what? I find
> the old code review system to be just as hard to use as Gerrit. Know
> why? I didn't use the old code review system much.
>
>>> Every release *has* been much better and the releases are often, and
>>> that's a great thing. It's not a corporate justification, it's
>>> reality. Having a really responsive and active upstream is awesome.
>>
>> You'll have to forgive me, but the only way I can read this is, "the
>> car now
>> breaks down two minutes into the journey; it used to break down a minute
>> in!"
>>
>
> This is a fallacious argument. For most use cases Gerrit works
> perfectly well. The fixes coming in each release are easing some of
> the use cases that don't work so well.
>
> Maybe as a non-developer Gerrit doesn't do what you want. As a
> developer it does most of what I want. It doesn't do some things I
> want, though. I want free-form tagging, for instance, which is on the
> roadmap for a future release (and Chad has already started adding in
> code that is required for this feature).

I want whatever review system we use to support real review branches;
- Review sets are heads with multiple commits, not single commits.
- We don't amend commits, we make new ones to the head of the review
branch.
- -no-ff merge commits are used so that only the final commit code makes
it directly into master.

Scrap all the other complaints. This pattern of amending commits is by far
the worst thing about our current workflow.
Development history and minor contributions that never make it into the
repo. "Committer" going to the person who fixes a typo rather than the
person who writes the code. Confusion over whether someone has rebased or
let unrelated changes leak into their patchset. Huge development effort by
multiple people potentially turning into a single commit with a single
committer. ...

At this point I think the real question we have is this:
"Can we reasonably get Gerrit to support real review branches?"

If that answer to that question is no. Or "not without very significant
development". Then the only option we have is to track down the system
that we can get to support that with the most reasonable amount of
development effort.

>>> I know people complain about Gerrit a lot, but I personally find it
>>> much better than our previous toolset.
>>
>> I think a lot of people are frustrated by the fact that the types of
>> problems being encountered in Gerrit would typically be trivial to fix
>> (CSS
>> precedence, for example). The fact that they're not runs against a lot
>> of
>> core Wikimedia principles.
>>
>
> As mentioned at least twice already in these threads, this is simply
> not true. It's possible to fix the CSS right now (and if you look at
> OpenStack's Gerrit, you'd notice they've already done so).
>
>>> We can just give people accounts now, and we eventually allow
>>> people to self-register as well. In fact, this is one of my top goals
>>> after upgrading openstack and adding a new Labs zone in eqiad.
>>
>> Yes, self-registration would be fantastic. :-) I commented on this bug
>> last
>> Saturday: <https://bugzilla.wikimedia.org/show_bug.cgi?id=37628>
>> ("Creating
>> a Git/Gerrit/Labs account requires human intervention"). I realize that
>> you
>> and the other ops folks are busy, but if someone could at least explain
>> the
>> current process, it would give volunteer developers a fighting chance of
>> helping out. Not having the faintest idea how the current account
>> creation
>> process works, I can't help or find anyone to help make it better.
>>
>
> I could have sworn there was another bug open for this that documented
> what needed to get done. I just spent a few minutes updating the bug.
> It's likely a fairly small OpenStackManager change, and a labsconsole
> configuration change. As mentioned it's on my list after Labs
> upgrades. If someone else wants to tackle it first, I'd love that.
>
> - Ryan


--
~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


hashar+wmf at free

Jul 27, 2012, 12:46 AM

Post #10 of 36 (1283 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

Le 27/07/12 04:04, MZMcBride wrote:
<snip
> It's somewhat ironic that you have a group of people who regularly champion
> the virtues of open source software ("you can hack the code!") who have
> picked a software solution that's (apparently) nearly impossible to modify.
> Even eliminating Gerrit's vomit color scheme would be a vast improvement,
> but as I understand it, even basic CSS changes are a no-go with Gerrit.

You can change the CSS, even the head/footer html:

http://gerrit-documentation.googlecode.com/svn/Documentation/2.4.2/config-headerfooter.html

Openstack has a different style:
https://review.openstack.org/

Roan did a skin that even ship jQuery:
https://gerrit.wikimedia.org/r/#/c/3285/

So that is definitely doable. It is currently blocked because the
build-in CSS are loaded AFTER the user CSS which is totally dumb but is
definitely an easy fix.

> A few people on this list have gone so far as to say "but the next release
> is always better!" I realize I was being a bit tongue-in-cheek by suggesting
> earlier that Gerrit's UI was developed by Microsoft, but to have developers
> now spouting corporate justifications for shitty software? I'm left to
> wonder what the hell happened.

It goes better after each releases and they upstream release often. That
is definitely better than a company throwing a bone at the community
from time to time or not willing to merge community patches.

The UI could probably have used a designer. As for the Microsoft, I
remember from the 90's some design guidance for third parties such as
how to position buttons, the margin to let around them and so on. I urge
you to have a look at the Windows Phone 7 GUI which is definitely nicer,
cleaner and easier to use than the Android/iPhone interfaces.
http://www.microsoft.com/windowsphone/

> I'm lost as to how Gerrit was ever considered an option previously and how
> it's still an option on the table today, given its apparent inflexibility.

I did mention how Android used a homemade tool to do the reviews. It was
introduced to me by a friend who is doing Android development for mobile
phone companies. At first I was like: what about the existing google
code or github? Then he explained me their pre commit workflow and it
made me sure we wanted to use that.
I think Ryan met the OpenStack folks who are using Gerrit. That probably
convinced him it was the right tool for us too.

> Say what you will about MediaWiki's CodeReview extension, but on its worst
> day, it never garnered as much resentment as Gerrit.

Our CodeReview tool lacked a good set of features such as the inline
commenting (which I coded but was reverted when 1.19 came live). It made
it very difficult to keep track of the follow up and comment reply.
Overall I am not regretting our old tool and will never come back to it.

MZ, Do you even have a labs account? Your continuous rants are far from
being constructive and makes everyone lose their time.

--
Antoine "hashar" Musso


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


hashar+wmf at free

Jul 27, 2012, 1:10 AM

Post #11 of 36 (1321 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

Daniel Friesen write:
> I want whatever review system we use to support real review branches;
> - Review sets are heads with multiple commits, not single commits.
> - -no-ff merge commits are used so that only the final commit code makes
> it directly into master.

We have disallowed branch creation and merging for now, that can
definitely be opened up. Chad recently opened the sandbox reference and
we have a few of them:

remotes/gerrit/sandbox/apramana/gsoc
remotes/gerrit/sandbox/demon/foo-bar
remotes/gerrit/sandbox/devunt/oauth
remotes/gerrit/sandbox/ori/hacks

They are actual branch we can most definitely merge -no-ff back in master.
http://www.mediawiki.org/wiki/Gerrit/personal_sandbox

> - We don't amend commits, we make new ones to the head of the review
> branch.

You will be able to do that. I am afraid the end result is not going to
look nice history wise with ton of followups to fix previous commits.
That will definitely make finding the root cause of bug and its context
harder to find out. Think about a commit that introduce a bug for which
the commit message is:

Ahh typo in 3124a09 fix it

It is not going to be helpful :-D


> Scrap all the other complaints. This pattern of amending commits is by
> far the worst thing about our current workflow.

I firmly disagree with you there. It let someone send some code then
enhance it without cluttering everyone else code. That let you work in a
collaborative way, finding out what the other person has done patch
after patch. We eventually end up with a patchset that only got
published (merged) to everyone whenever it is close to perfect. That
makes our code history nicer and push the review stress to the
submitters (lot of people) instead of toward the reviewers (few people).

I do agree though that the system can be confusing and is poorly
toolized. git-review is a step to abstract the whole patchset system,
but I am sure we can make it a better/easier tool to use.

> Development history and minor contributions that never make it into the
> repo.

I think we do not care about the history of a change. The typo / comment
update / logic errors, I am sure we do not care about. If someone has a
change that requires to be split in several changes, that should easier
be a branch (see sandbox above) or a chain of changes made
interdependants (which is really just a local branch).

How would you do that? Well lets say I want to update our documentation
to several area. I would first create a local branch:

git checkout -b doc -t origin/master
<do my doc updates, commit as needed>

I then push that local branch to Gerrit (git push doc:refs/for/master),
that craft a change per commit. Whenever one of the commit need to be
amended I edit my local branch commits with git rebase --interactive.
Once happy I repush the whole branch and Gerrit magically update all the
patchsets.

The drawback is that editing just a commit out of several one will still
trigger a new patchset to all the child commits although there is no
code change per see (the parent got changed). That could be detected in
Gerrit I guess.
We might have Gerrit to automatically rebase children whenever a parent
is modified.
Gerrit could also use a feature to prevent the chain of commits to be
submitted until they have all been reviewed. Once the last change is
submitted, that will trigger a git merge --no-ff. We currently have to
handle that manually by submitting the first commit last.

> "Committer" going to the person who fixes a typo rather than the
> person who writes the code.

The Author field is kept around (unless someone amend it). See as an
example https://gerrit.wikimedia.org/r/#/c/5550/, I am the patch
author, Saper sent patchset 3 but I am still mentioned as the author.

git does not support multiple authors as far as I know, but one could
add himself in the commit message by adding a new field such as:

Co-authored-by: John Doh <johndoe [at] example>

> Confusion over whether someone has rebased or let unrelated changes
> leak into their patchset.

That is more a matter of educating our developers. Whenever I submit a
new patchset, I add a cover message in Gerrit to introduce what that
change did even if it is "just a rebase".

> Huge development effort by multiple people potentially turning into a
> single commit with a single committer. ...

As I said previously, huge effort involving multiple persons could be
made branch.


> At this point I think the real question we have is this:
> "Can we reasonably get Gerrit to support real review branches?"

The answer is most definitely yes. We would need to open up branches
creations to everyone.

> If that answer to that question is no. Or "not without very significant
> development". Then the only option we have is to track down the system
> that we can get to support that with the most reasonable amount of
> development effort.

I tend to agree on that :-)

--
Antoine "hashar" Musso


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


lists at nadir-seen-fire

Jul 27, 2012, 2:20 AM

Post #12 of 36 (1317 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Fri, 27 Jul 2012 01:10:52 -0700, Antoine Musso <hashar+wmf [at] free>
wrote:

> Daniel Friesen write:
>> I want whatever review system we use to support real review branches;
>> - Review sets are heads with multiple commits, not single commits.
>> - -no-ff merge commits are used so that only the final commit code makes
>> it directly into master.
>
> We have disallowed branch creation and merging for now, that can
> definitely be opened up. Chad recently opened the sandbox reference and
> we have a few of them:
>
> remotes/gerrit/sandbox/apramana/gsoc
> remotes/gerrit/sandbox/demon/foo-bar
> remotes/gerrit/sandbox/devunt/oauth
> remotes/gerrit/sandbox/ori/hacks
>
> They are actual branch we can most definitely merge -no-ff back in
> master.
> http://www.mediawiki.org/wiki/Gerrit/personal_sandbox
>
>> - We don't amend commits, we make new ones to the head of the review
>> branch.
>
> You will be able to do that. I am afraid the end result is not going to
> look nice history wise with ton of followups to fix previous commits.
> That will definitely make finding the root cause of bug and its context
> harder to find out. Think about a commit that introduce a bug for which
> the commit message is:
>
> Ahh typo in 3124a09 fix it
>
> It is not going to be helpful :-D
>
>
>> Scrap all the other complaints. This pattern of amending commits is by
>> far the worst thing about our current workflow.
>
> I firmly disagree with you there. It let someone send some code then
> enhance it without cluttering everyone else code. That let you work in a
> collaborative way, finding out what the other person has done patch
> after patch. We eventually end up with a patchset that only got
> published (merged) to everyone whenever it is close to perfect. That
> makes our code history nicer and push the review stress to the
> submitters (lot of people) instead of toward the reviewers (few people).
>
> I do agree though that the system can be confusing and is poorly
> toolized. git-review is a step to abstract the whole patchset system,
> but I am sure we can make it a better/easier tool to use.
>
>> Development history and minor contributions that never make it into the
>> repo.
>
> I think we do not care about the history of a change. The typo / comment
> update / logic errors, I am sure we do not care about. If someone has a
> change that requires to be split in several changes, that should easier
> be a branch (see sandbox above) or a chain of changes made
> interdependants (which is really just a local branch).
>
> How would you do that? Well lets say I want to update our documentation
> to several area. I would first create a local branch:
>
> git checkout -b doc -t origin/master
> <do my doc updates, commit as needed>
>
> I then push that local branch to Gerrit (git push doc:refs/for/master),
> that craft a change per commit. Whenever one of the commit need to be
> amended I edit my local branch commits with git rebase --interactive.
> Once happy I repush the whole branch and Gerrit magically update all the
> patchsets.
>
> The drawback is that editing just a commit out of several one will still
> trigger a new patchset to all the child commits although there is no
> code change per see (the parent got changed). That could be detected in
> Gerrit I guess.
> We might have Gerrit to automatically rebase children whenever a parent
> is modified.
> Gerrit could also use a feature to prevent the chain of commits to be
> submitted until they have all been reviewed. Once the last change is
> submitted, that will trigger a git merge --no-ff. We currently have to
> handle that manually by submitting the first commit last.
>
>> "Committer" going to the person who fixes a typo rather than the
>> person who writes the code.
>
> The Author field is kept around (unless someone amend it). See as an
> example https://gerrit.wikimedia.org/r/#/c/5550/, I am the patch
> author, Saper sent patchset 3 but I am still mentioned as the author.
>
> git does not support multiple authors as far as I know, but one could
> add himself in the commit message by adding a new field such as:
>
> Co-authored-by: John Doh <johndoe [at] example>
>
>> Confusion over whether someone has rebased or let unrelated changes
>> leak into their patchset.
>
> That is more a matter of educating our developers. Whenever I submit a
> new patchset, I add a cover message in Gerrit to introduce what that
> change did even if it is "just a rebase".
>
>> Huge development effort by multiple people potentially turning into a
>> single commit with a single committer. ...
>
> As I said previously, huge effort involving multiple persons could be
> made branch.
>
>
>> At this point I think the real question we have is this:
>> "Can we reasonably get Gerrit to support real review branches?"
>
> The answer is most definitely yes. We would need to open up branches
> creations to everyone.
>
>> If that answer to that question is no. Or "not without very significant
>> development". Then the only option we have is to track down the system
>> that we can get to support that with the most reasonable amount of
>> development effort.
>
> I tend to agree on that :-)
>

Most of your reply appears to be based on an assumption based around real
branches in Gerrit rather than the
ephemeral-branch-as-review/commit-as-patchset pattern discussed in the
list earlier.
Naturally the way you're suggesting to configure Gerrit is not the way I'm
suggesting it work.

Review pages for what we see now as individual commits would be an
ephemeral branch. Really just a moving head. When it gets accepted there
wouldn't really be any head left in refs/heads/ as a branch.
On the review pages the spot were we see "patchsets" be individual commits
in that faux branch. Instead of being completely separate commits these
would be actual commits building on each other.

Though rather than taking that Gerrit oriented description. Why not just
read the previous emails.
This one is my explanation of a --no-ff workflow:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/62461/focus=62489
Shortly after I posted that description Platonides independently ended up
describing basically the same thing I was suggesting:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/62461/focus=62505


You also seem to be making a false assumption about history based around
limitations in linear history like in svn that don't exist in a non-linear
--no-ff merge commit environment.

When you merge sets of changes into the master using --no-ff (Gerrit,
whatever would do this automatically) the individual commits never really
become part of master. They are there, they are in the history. But they
are on a side of the branch you don't use unless you really mean to.
When you are walking through the history of master (bisecting) you only
want to walk one side of master. There is no point in splitting in two
there as the commits that never got directly committed into master can
never be the source of a bug. Because these sides are separate commits
like "Ahh typo in 3124a09 fix it" will NEVER get in the way of fixing
something.
In fact, once you do find the commit that introduced a bug you can go into
the other side of the branch and drill down into the individual commits
and discover whether this bug introduced was something fundamental to the
addition to core or was a last minute mistake caused after someone told
the committer to fix something else and ended up creating a bug while
fixing one.


--
~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 27, 2012, 4:48 AM

Post #13 of 36 (1309 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Fri, Jul 27, 2012 at 2:36 AM, Rob Lanphier <robla [at] wikimedia> wrote:
> As far as "people being assigned to the the task of evaluating them", I
> think you may be overestimating the number of people we have floating
> around to do this work. "People" is basically Chad, who is pretty burnt
> out on working on this, and is exasperated with this process, but without
> drafting someone outside my group (like you?) :), I don't have many
> options. Having Chad do this means taking one of our most experienced
> MediaWiki developers, and having him not work on MediaWiki, but instead, do
> more evaluation of code review tools.
>
> Before doing that to Chad, I'm asking people who believe passionately that
> we need to move off Gerrit to actually tell us what they'd like to move to
> in a structured, constructive way. I don't think that's too much to ask.
>

I'd like to just clarify Rob's comments here, since they're about me :)

When Rob says "burnt out," I really am tired. This process has been
very draining, but necessary. It's very important that we get this right,
which is why I've been committed since day 1 to helping absolutely
everyone with absolutely everything relating to Git. Got a question?
Ask me. Need a new repo? Ask me. But being a one-man-army tires
you after awhile and that's where I'm at right now. But like I said, I'm
committed to seeing this through and making sure we're in the best
possible position going forward.

I feel like "exasperated" has a bit of a negative connotation to it.
Better way to describe it would be "would very much like for this to
find resolution so I can fade back into obscurity and work on cool
things again, like Config overhaul which I really really want to see
done so much." :)

Again, I'm here to support the community on this. Whatever the end
result is, I'll be behind it.

-Chad

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


innocentkiller at gmail

Jul 27, 2012, 5:01 AM

Post #14 of 36 (1272 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Fri, Jul 27, 2012 at 3:46 AM, Antoine Musso <hashar+wmf [at] free> wrote:
> So that is definitely doable. It is currently blocked because the
> build-in CSS are loaded AFTER the user CSS which is totally dumb but is
> definitely an easy fix.
>

It's not quite as easy as I had hoped, unfortunately. However, it can
be worked around (slap !important on everything), and I am still very
actively researching a fix for it. In fact, I spent the vast majority of
this week playing with upstream. Other than researching that bug, a
couple of other cool things I worked on were:

1) I reviewed some improvements made by another developer to the
plugin interface that will make it into 2.5.
2) I wrote my own plugin (in less than an hour and less than 100 LOC)
to solve a silly issue I've hit.
3) I contributed a lot of fixes to the "delete-project" plugin (which we
need, badly), and as a result it's now working and will be coming out
along with 2.5.
4) I also spent quite a bit of time diagnosing some of the "diff bugs"
that people have been hitting in Webkit-based browsers. I didn't get a
fix, but I did find out a lot and reported all that information upstream.

Also, if anyone tells me that upstream is not active enough, I ask you
to please look at a commit I made 2 days ago[0]. I know it wasn't earth-
shattering, or even really important. What was important, is that it was
reviewed and merged in *less than a minute* without any action on my
part. All upstream contributions receive quite a bit of feedback, and
things get merged into master every single day. I talk with the Gerrit
guys constantly, and they've been nothing but supportive and helpful
in both my questions and helping to resolve our issues.

-Chad

[0] https://gerrit-review.googlesource.com/#/c/36980/

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


z at mzmcbride

Jul 27, 2012, 6:42 AM

Post #15 of 36 (1309 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

Antoine Musso wrote:
> MZ, Do you even have a labs account? Your continuous rants are far from
> being constructive and makes everyone lose their time.

Nope. I looked at getting one once or twice, but the process seemed too
bureaucratic and I ended up walking away. I imagine I'll make one once
self-registration becomes possible.

I don't think it's fair to say that my posts have been unconstructive. I've
tried to present actual problems (such as the lack of an authors list) that
inhibit being able to effectively use Gerrit. I've also documented my
experiences with Gerrit's UI, which to me is completely unintuitive (for
example, finding the code inspection links beneath "tree" or "gitweb" took
me weeks). In May, I tried to create a page about Gerrit's problems:
<https://www.mediawiki.org/wiki/Gerrit/Problems>. I don't know Java or
Prolog, otherwise I might have offered to help improve Gerrit directly.

Instead, all I can do is share my experiences with the tool in a
conversation about it and alternatives. You sound frustrated in your post,
hashar, but I don't think you're frustrated with me. If I had to use Gerrit
every day (in its current form), I'd be frustrated as well. Though in its
defense, once you learn where the secret links and menus and buttons are,
most of the needed functionality is there.

Ryan Lane wrote:
> So, you found something you'd like added to the software: a user list.
> Have you entered a bug? The problem you are encountering is that you
> are used to a piece of software, and the new software doesn't have the
> exact same feature set. This happens, and will happen with any new
> tool if we switch, too.
>
> There's an open bug for this:
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=35508

Thank you for the bug link.

> Note that the bug mentions a number of ways you can get a user list
> outside of Gerrit. I think it would be nice to have Gerrit itself have
> the user list interface. With extension support in Gerrit 2.5, we may
> be able to implement it ourselves.

It feels a bit like buying a car that has no steering wheel. I didn't really
want to overrun our bug tracker with Gerrit bugs, but I can certainly file a
few against it.

I'm not trying to be an asshole, but I really don't understand how such a
basic feature is missing (which is what I meant by "how does anyone use
Gerrit?"). There's a dashboard feature that accepts user IDs to view a
particular user's contributions to Gerrit, but without an index (or some
other way to match IDs to usernames), I really have no idea how you're
supposed to be able to look at a particular user's contributions.

>> I think a lot of people are frustrated by the fact that the types of
>> problems being encountered in Gerrit would typically be trivial to fix (CSS
>> precedence, for example). The fact that they're not runs against a lot of
>> core Wikimedia principles.
>
> As mentioned at least twice already in these threads, this is simply
> not true. It's possible to fix the CSS right now (and if you look at
> OpenStack's Gerrit, you'd notice they've already done so).

I know about OpenStack's CSS customizations. With regard to Wikimedia's
Gerrit installation and CSS, I'll believe it when I see it. :-)

>> Yes, self-registration would be fantastic. :-) I commented on this bug last
>> Saturday: <https://bugzilla.wikimedia.org/show_bug.cgi?id=37628> ("Creating
>> a Git/Gerrit/Labs account requires human intervention"). I realize that you
>> and the other ops folks are busy, but if someone could at least explain the
>> current process, it would give volunteer developers a fighting chance of
>> helping out. Not having the faintest idea how the current account creation
>> process works, I can't help or find anyone to help make it better.
>
> I could have sworn there was another bug open for this that documented
> what needed to get done. I just spent a few minutes updating the bug.
> It's likely a fairly small OpenStackManager change, and a labsconsole
> configuration change. As mentioned it's on my list after Labs
> upgrades. If someone else wants to tackle it first, I'd love that.

Great, thank you for updating the bug.

And thank you both for your thoughtful replies. I appreciate them. :-)

For what it's worth, I think Ryan makes a compelling case for sticking with
Gerrit (and I'm still not convinced that another switch would do more good
than harm). I'm still deeply worried about the ability to use and improve
Gerrit. It would be horribly painful to see all of the work switching from
SVN to Git (a large portion of which was intended to allow easy code
contributions) go to waste because this particular Git front-end has scared
everyone away.

MZMcBride



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


innocentkiller at gmail

Jul 27, 2012, 6:58 AM

Post #16 of 36 (1298 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Fri, Jul 27, 2012 at 9:42 AM, MZMcBride <z [at] mzmcbride> wrote:
> It feels a bit like buying a car that has no steering wheel. I didn't really
> want to overrun our bug tracker with Gerrit bugs, but I can certainly file a
> few against it.
>

Please do. I file every bug upstream as well, after it's been filed in
our BZ.

> I'm not trying to be an asshole, but I really don't understand how such a
> basic feature is missing (which is what I meant by "how does anyone use
> Gerrit?"). There's a dashboard feature that accepts user IDs to view a
> particular user's contributions to Gerrit, but without an index (or some
> other way to match IDs to usernames), I really have no idea how you're
> supposed to be able to look at a particular user's contributions.
>

Just as a minor nitpick--those dashboards aren't meant to be viewed by
anyone other than the author themselves (which is why it's the main page
when you login, as well as the default page for My -> Commits).

There's a couple of changes coming in 2.5 to this regard:
1) Personal dashboards will now be private -- the proper way to query
someone's work is the "owner:" query in the search box.
2) With 2.5, you'll also be able to save "dashboards" or "queries" for
pages you commonly look up (or just want to remember for later)

A quick note on the search field: it's super-powerful. I know I've pointed
at the docs before, but I really encourage you to read them[0] if you're
the type of user who likes doing these sorts of interesting queries.
Also, in the merge queue for upstream right now (I'm praying it makes
it into 2.5 before the branch) is search suggestions [1]. This should
make it wayyy easier to find things you're looking for.

-Chad

[0] https://gerrit.wikimedia.org/r/Documentation/user-search.html
[1] https://gerrit-review.googlesource.com/#/c/36932/

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


faidon at wikimedia

Jul 27, 2012, 7:16 AM

Post #17 of 36 (1308 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Thu, Jul 26, 2012 at 11:36:50PM -0700, Rob Lanphier wrote:
> On Thu, Jul 26, 2012 at 12:49 PM, Faidon Liambotis <faidon [at] wikimedia>wrote:
> > My understanding of the process was that we would collect a broad set of
> > arguments/ideas/proposals and people would be later assigned to the task
> > of evaluating them and proposing a viable solution and a migration path
> > (or not, and propose that we stay with Gerrit).
> >
>
> Yes, we're seeking a broad range of proposals. However, "proposals" is the
> key word. That means looking the requirements, reading the website and
> matching against those requirements, and stitching together something that
> at least looks good on paper. I'm not expecting anyone to set up a
> prototype, but I am asking that, given how long we've been talking about
> this, that we narrow down our options a bit to the things that we know are
> worth looking at rather than (still, a year later) having the "have you
> looked at this?" discussion again.

I think GitLab looks promising but I'm unable to judge it against all of
our requirements just from the online demo and without spending some
amount of time on it. I just put some pros and cons as I see them to the
Wiki page and hope it can be considered.

Regards,
Faidon

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


roan.kattouw at gmail

Jul 27, 2012, 8:28 AM

Post #18 of 36 (1276 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Jul 27, 2012 6:58 AM, "Chad" <innocentkiller [at] gmail> wrote:
> 1) Personal dashboards will now be private -- the proper way to query
> someone's work is the "owner:" query in the search box.
As MZ and I found out last night, this is not the case. An owner: search
only finds changes that person *started*, so it doesn't find changes by
others they've contributed patchsets to. Searching for an e-mail address
does get all changes someone's been involved in (even if they only comment
on the change), I believe it's equivalent to reviewer:. But this is all far
from obvious and took me a while to figure out, people who haven't used
Gerrit before don't really stand much of a chance there.

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


roan.kattouw at gmail

Jul 27, 2012, 8:32 AM

Post #19 of 36 (1279 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Jul 27, 2012 7:17 AM, "Faidon Liambotis" <faidon [at] wikimedia> wrote:
> I think GitLab looks promising but I'm unable to judge it against all of
> our requirements just from the online demo and without spending some
> amount of time on it. I just put some pros and cons as I see them to the
> Wiki page and hope it can be considered.
>
I would also like Gitlabs to be considered, so I'll poke at that wiki page
later. I may or may not have time to play with it before Monday.

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


roan.kattouw at gmail

Jul 27, 2012, 8:33 AM

Post #20 of 36 (1272 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Jul 27, 2012 1:11 AM, "Antoine Musso" > We have disallowed branch
creation and merging for now, that can
> definitely be opened up. Chad recently opened the sandbox reference and
> we have a few of them:
>
> remotes/gerrit/sandbox/apramana/gsoc
> remotes/gerrit/sandbox/demon/foo-bar
> remotes/gerrit/sandbox/devunt/oauth
> remotes/gerrit/sandbox/ori/hacks
>
> They are actual branch we can most definitely merge -no-ff back in master.
> http://www.mediawiki.org/wiki/Gerrit/personal_sandbox
>
This is a great feature, but I think most people realize it exists. Was it
ever publicized widely?

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


innocentkiller at gmail

Jul 27, 2012, 8:37 AM

Post #21 of 36 (1273 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Fri, Jul 27, 2012 at 11:33 AM, Roan Kattouw <roan.kattouw [at] gmail> wrote:
> On Jul 27, 2012 1:11 AM, "Antoine Musso" > We have disallowed branch
> creation and merging for now, that can
>> definitely be opened up. Chad recently opened the sandbox reference and
>> we have a few of them:
>>
>> remotes/gerrit/sandbox/apramana/gsoc
>> remotes/gerrit/sandbox/demon/foo-bar
>> remotes/gerrit/sandbox/devunt/oauth
>> remotes/gerrit/sandbox/ori/hacks
>>
>> They are actual branch we can most definitely merge -no-ff back in master.
>> http://www.mediawiki.org/wiki/Gerrit/personal_sandbox
>>
> This is a great feature, but I think most people realize it exists. Was it
> ever publicized widely?
>

I sent out an e-mail announcing it:
"Personal sandbox space in Gerrit" [0]

It was also documented on-wiki:
https://www.mediawiki.org/wiki/Gerrit/personal_sandbox

-Chad

[0] http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/061584.html

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


hashar+wmf at free

Jul 27, 2012, 9:38 AM

Post #22 of 36 (1274 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

Le 27/07/12 15:42, MZMcBride a écrit :
> I don't think it's fair to say that my posts have been unconstructive. I've
> tried to present actual problems (such as the lack of an authors list) that
> inhibit being able to effectively use Gerrit.
<snip>

To clarify, I was mostly ranting about the form. Your posts are
definitely constructive and you are a huge asset to all the tech team by
constantly reporting what is wrong and opening bugs. So keep please
doing that :-]

--
Antoine "hashar" Musso


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


rlane32 at gmail

Jul 27, 2012, 10:17 AM

Post #23 of 36 (1275 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

> I did mention how Android used a homemade tool to do the reviews. It was
> introduced to me by a friend who is doing Android development for mobile
> phone companies. At first I was like: what about the existing google
> code or github? Then he explained me their pre commit workflow and it
> made me sure we wanted to use that.
> I think Ryan met the OpenStack folks who are using Gerrit. That probably
> convinced him it was the right tool for us too.
>

Actually, we started using Gerrit for Ops before OpenStack switched to
it. It's just a happy coincidence.

- Ryan

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


rlane32 at gmail

Jul 27, 2012, 10:25 AM

Post #24 of 36 (1274 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Fri, Jul 27, 2012 at 6:42 AM, MZMcBride <z [at] mzmcbride> wrote:
> Antoine Musso wrote:
>> MZ, Do you even have a labs account? Your continuous rants are far from
>> being constructive and makes everyone lose their time.
>
> Nope. I looked at getting one once or twice, but the process seemed too
> bureaucratic and I ended up walking away. I imagine I'll make one once
> self-registration becomes possible.
>

Give me a break. You fill out a request that asks for like 4 pieces of
information, then (usually the same day) someone creates an account
for you, which sends you a password by email. It's seriously like 3
clicks.

This process is about 17234872748 times less bureaucratic then the svn
request process was.

- Ryan

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


robla at wikimedia

Jul 27, 2012, 10:29 AM

Post #25 of 36 (1307 views)
Permalink
Re: Criteria for "serious alternative" [In reply to]

On Fri, Jul 27, 2012 at 6:42 AM, MZMcBride <z [at] mzmcbride> wrote:
>
> For what it's worth, I think Ryan makes a compelling case for sticking with
> Gerrit (and I'm still not convinced that another switch would do more good
> than harm). I'm still deeply worried about the ability to use and improve
> Gerrit. It would be horribly painful to see all of the work switching from
> SVN to Git (a large portion of which was intended to allow easy code
> contributions) go to waste because this particular Git front-end has scared
> everyone away.


For what it's worth, this is pretty much exactly where I'm at right now.
In spite of my defense of Gerrit, I'm not blind to it's manifold
deficiencies in its current form. In addition to the problems for new
volunteer contributors, there's a steep learning curve for new employees.
I'm also worried about the steep learning curve anyone from our community
(myself included) would have in getting set up to improve Gerrit through
writing patches and plugins, though I'll take Chad at his word that it's
really not as bad as many of us fear.

But, I'm also still not convinced that another switch would do more
good than harm.

I think our best mitigation strategy is to do as good a job as we possibly
can integrating Gerrit with GitHub, combined with other improvements to
Gerrit.

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

First page Previous page 1 2 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.