Re: [Wikitech-l] Captcha for non-English speakers II

[Platonides]

On 27/07/12 16:31, Everton Zanella Alvarenga wrote:
> 2012/7/26 Platonides :
> 
>> Thet don't need to read English. They just need to type the letters they
>> see on the image. Sure, you can have a small advantage if you know what
>> letters could make a valid English word (or if you have the captcha
>> dictionary installed), but a Brazilian which can read wikipedia should
>> have no problems typing the captcha.
> 
> If that is the case, why don't we change the CAPTCH for random letters?

You should probably ask Neil Harris, the author of the captcha generator
we use.

from his 06/02/2011 mail:
> The wordlists themselves need not be secret: they are only needed to 
> create easily-typed strings that are sufficiently large in number to 
> provide a moderate challenge to brute force guessing.


I have added a random captcha at http://test.wikipedia.beta.wmflabs.org/
You can try adding urls at
http://test.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=edit
and http://en.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Sandbox for
comparing the presented captchas.

(yes, testwikibeta is quite broken right now, but the captchas show)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.

[Daniel Friesen]

On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier   
wrote:



On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen
wrote:


On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp 
wrote:


I think I understand what your saying about that, and that's one way
it could be done. I had also given some thought to extending the user,
so that an OAuth user would have limited permissions, and a SAML user
may not even exist in the data store etc. But it would be good to
hear from other developers if they have thoughts on it?



Separate user rows for OAuth?



OAuth 2.0 has a "scope" field to let the client request an auth token  
with

the scope of the permissions it is requesting, which is a space delimited
list of scope strings, to which the server can respond with an auth token
that includes that scope list, a different scope list, or an error.[1]

I think creation of an OAuth token should result in the creation of a
MediaWiki session, and that scope should be added to the session data.   
In
our initial implementation, I think each of scope strings should  
correspond

to MediaWiki permissions (i.e. mCoreRights in User.php).  However, we
should think ahead to the day when we might want to have something more
fine grained than that.

Rob

[1]  http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3


No, I already know about scope. I was just confused what Chris was trying  
to describe when he grouped separate topics into one paragraph.


OAuth 2 scope can actually apply to the auth code, refresh token, and  
access token separately. The auth code's scope defines the refresh token's  
scope. And the refresh token's scope is used when defining the access  
token's scope. But it's possible to use a refresh token to request an auth  
code with less permissions than what the refresh token has.


I don't think 'session' will work in the context we currently use it in  
core. Authorizations, especially refresh tokens are persistent while  
session storage is ephemeral and can easily forget something we don't want  
it to forget.
We also want to be careful about touching the session data at all. Besides  
the point that OAuth doesn't use cookies anywhere at all we want to be  
careful with the fact that we're probably going to need to support an  
OAuth + CORS environment where we want to erase all cookie and session  
data and pretend it doesn't exist even if the browser sends it.


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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.

[Rob Lanphier]

On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen
wrote:

> On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp 
> wrote:
>
>> I think I understand what your saying about that, and that's one way
>> it could be done. I had also given some thought to extending the user,
>> so that an OAuth user would have limited permissions, and a SAML user
>> may not even exist in the data store etc. But it would be good to
>> hear from other developers if they have thoughts on it?
>>
>
> Separate user rows for OAuth?


OAuth 2.0 has a "scope" field to let the client request an auth token with
the scope of the permissions it is requesting, which is a space delimited
list of scope strings, to which the server can respond with an auth token
that includes that scope list, a different scope list, or an error.[1]

I think creation of an OAuth token should result in the creation of a
MediaWiki session, and that scope should be added to the session data.  In
our initial implementation, I think each of scope strings should correspond
to MediaWiki permissions (i.e. mCoreRights in User.php).  However, we
should think ahead to the day when we might want to have something more
fine grained than that.

Rob

[1]  http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Roan Kattouw]

On Fri, Jul 27, 2012 at 3:29 PM, Chad  wrote:
> On Fri, Jul 27, 2012 at 6:27 PM, Terry Chay  wrote:
>> Gerrit has templating support so basic CSS changes are not difficult 
>> and require no pushes to upstream Gerrit. Delta one strange thing in that 
>> the load order of the cascade in Gerrit is… wrong. My arguments with Gerrit 
>> are in fancier scripting UI that requires delving into GWT to get done. Chad 
>> mentioned that virtually nobody has played with either yet.
>>
>
> This is not what I said. I said injecting Javascript is possible as well, 
> which
> Roan said he has experimented with before.
>
I think we're already loading jQuery for Gerrit views in production,
we're just not using it for anything yet.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Terry Chay]

Are you a Brandon plant trying to get us to resource Athena again? :-)

On Jul 27, 2012, at 3:01 AM, John Elliot  wrote:

> Are there any initiatives in the MediaWiki community for a MediaWiki
> theme that supports 'responsive design' [1] -- where content is properly
> laid out in an accessible form on all manner of devices including
> desktops and smart phones?
> 
> [1] http://www.alistapart.com/articles/responsive-web-design/
> 
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 6:27 PM, Terry Chay  wrote:
> Gerrit has templating support so basic CSS changes are not difficult 
> and require no pushes to upstream Gerrit. Delta one strange thing in that the 
> load order of the cascade in Gerrit is… wrong. My arguments with Gerrit are 
> in fancier scripting UI that requires delving into GWT to get done. Chad 
> mentioned that virtually nobody has played with either yet.
>

This is not what I said. I said injecting Javascript is possible as well, which
Roan said he has experimented with before.

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Terry Chay]

On Jul 26, 2012, at 7:04 PM, 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.

That's funny, because my experience is the exact opposite: this meeting 
is not in my calendar and I breathed a sigh of relief!

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

Gerrit has templating support so basic CSS changes are not difficult 
and require no pushes to upstream Gerrit. Delta one strange thing in that the 
load order of the cascade in Gerrit is… wrong. My arguments with Gerrit are in 
fancier scripting UI that requires delving into GWT to get done. Chad mentioned 
that virtually nobody has played with either yet.

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

The wiki page outlines exactly what went into the decision. 

For instance, I like Phabricator. However very few of the requirements 
listed when this was discussed (in March) were in Phabricator so I understand 
why Gerrit was chosen even if I have a personal dislike for it. Phabricator has 
a high velocity of new features and support (actually about 2x Gerrit) and that 
is now changes. However, even so, that isn't the case (yet).

Also, consider that even if that is the case, it's neither Features 
engineers nor the community will be inplementing/maintaining whatever solution 
is used. The maintainers will be in Platform and Ops.

Now we can argue over whether the wiki page's criterias were the "right 
ones." (For instance, should the WMF adopt the Git/GitHub philosophy of 
un-gated reviews?) But since those criteria come from the practical reality on 
how code review is actually done and integrated currently, that's a different 
argument entirely to what code review tool is best for how we currently use it.

Gerrit won simply because it is designed to work the same way we were 
currently working… warts and all. But the landscape is changing and it's time 
to re-evaluate if a course correction is in order. Hopefully this won't be the 
last (if only because I don't think any other system is going to beat Gerrit 
spec-for-spec ATM).



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Captcha for non-English speakers II

[Strainu]

2012/7/28 Max Semenik :
> On 27.07.2012, 22:09 Yury wrote:
>
>> I think that making Russian, Korean and Arabian captcha is really bad idea.
>> English keyboad layout is installed by default in all operation systems, as
>> far as I know. Moreover very interesting problems can appear if this
>> feature would be implemented. Who will decide what captcha language is
>> used? We can look at user IP address - then sometimes the foreigners will
>> be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus
>> assuming that every person who knows Ukrainian has the Ukrainian keyboard
>> layout, which is not true.
>> I think that the assumption that "everyone in the internet is able to print
>> English letters loking at their noised example" is not very bold assumption.
>
> Even funnier: imagine a Eeuropean trying to just read a Chinese
> captcha:)

Funny as it may be, this is a non-problem. You can easily have a "give
me an English CAPTCHA" link... And that would be one more step for a
robot to learn, that is, one more (thin) defence line.

Strainu

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.

[Daniel Friesen]

On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp   
wrote:



I wanted to get in a couple responses to Daniel, as well as try to
make sure the conversation doesn't die. Obviously having a lead person
in the OAuth2 process leave may effect what we want to implement. Or
may spawn a new standard in the near future. But I hope we can still
move ahead with laying the foundation for allowing other entities and
applications to work with mediawiki and WMF sites, and specifically
make sure that third parties can interact with WMF sites in a way that
is more secure than currently possible.


From the start of the OAuth idea I've been thinking we should handle the
code in an abstract way.


I definitely agree with you there, although deciding which
functionality is common is obviously the tricky part. Where we draw
that line can greatly effect the effort that is required to implement,
so I want to make sure we draw it appropriately.

I think recognizing that a user's session may have a different set of
permissions from the permissions that their group membership gives
them definitely falls into that category. Keeping track of the concept
of external entities (whether it's a university serving SAML, or an
app developer using oauth) may also fall into this category. Thoughts
from other developers?


Yeah, I think my random OAuth brainstorming reflects this too:
https://www.mediawiki.org/wiki/User:Dantman/OAuth/Brainstorm

Authorizations have an interface to return the rights that the user has in  
the authorization.
While this interface is present in the code it doesn't show up anywhere  
inside the generic part of the database for authorizations.
Instead it's handled at the plugin implementation level. In this case auth  
codes, access tokens, and refresh tokens have scope information and that  
is used by the OAuthAuthorization to return rights information.




- I started thinking that every user instance should have some sort of
->getApplication()/->getAuthorization() connection. And this would be  
used

when noting what was responsible for various edits/logs/etc...


I think I understand what your saying about that, and that's one way
it could be done. I had also given some thought to extending the user,
so that an OAuth user would have limited permissions, and a SAML user
may not even exist in the data store etc. But it would be good to
hear from other developers if they have thoughts on it?


Separate user rows for OAuth?


- To top all this off we could potentially also make a special built-in
"Import" application. This would result in all edits made by importing
edits from another wiki being nicely annotated in the UI with  
information

saying they were imported rather than actually made on the wiki by said
person.


I hadn't heard other people mention tracking edits by Import or the
Installer, but if there's support for that type of thing, then I
agree, this might be a good place to include it.



What does everyone think of this idea?



Hopefully the lack of response was due to everyone recovering from
wikimania instead of lack of enthusiasm for OAuth!



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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Captcha for non-English speakers II

[Max Semenik]

On 27.07.2012, 22:09 Yury wrote:

> I think that making Russian, Korean and Arabian captcha is really bad idea.
> English keyboad layout is installed by default in all operation systems, as
> far as I know. Moreover very interesting problems can appear if this
> feature would be implemented. Who will decide what captcha language is
> used? We can look at user IP address - then sometimes the foreigners will
> be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus
> assuming that every person who knows Ukrainian has the Ukrainian keyboard
> layout, which is not true.
> I think that the assumption that "everyone in the internet is able to print
> English letters loking at their noised example" is not very bold assumption.

Even funnier: imagine a Eeuropean trying to just read a Chinese
captcha:)

-- 
Best regards,
  Max Semenik ([[User:MaxSem]])


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Captcha for non-English speakers II

[Martijn Hoekstra]

Maybe present three or four different capcha's with different scripts,
requiring only one to be filled out?

On Fri, Jul 27, 2012 at 8:09 PM, Yury Katkov  wrote:
> I think that making Russian, Korean and Arabian captcha is really bad idea.
> English keyboad layout is installed by default in all operation systems, as
> far as I know. Moreover very interesting problems can appear if this
> feature would be implemented. Who will decide what captcha language is
> used? We can look at user IP address - then sometimes the foreigners will
> be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus
> assuming that every person who knows Ukrainian has the Ukrainian keyboard
> layout, which is not true.
> I think that the assumption that "everyone in the internet is able to print
> English letters loking at their noised example" is not very bold assumption.
> 26.07.2012 17:53 пользователь "Everton Zanella Alvarenga" <
> ezalvare...@wikimedia.org> написал:
>
>> Hi all,
>>
>> how are you? I'd like to know about the possibility of solving an old
>> issue with CAPTCHA for Wikipedias in languages other than English.
>> This bug
>>
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=5309
>>
>> was created in 2006. There is a discussion here about having CAPTCHA
>> in other languages from February 2012
>>
>>
>> http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/51951/
>>
>> but it seems there was no conclusion. After working on campus with new
>> editors in Brazil, I've checked this is a real obstacle, since most
>> people here cannot ready English at all.
>>
>> I'd like to know if there are plans to solve this issue - I hope I
>> don't sound rude, maybe this can be a minor issue when we don't see
>> the difficulties people from a different place can face. I think this
>> is important for Wikipedias other than the English one (just read
>> people comments in the bug) and we can be loosing new contributors
>> because of their first impressions. Thanks,
>>
>> Tom
>>
>> --
>> Everton Zanella Alvarenga (also Tom)
>> Wikimedia Brasil
>> Wikimedia Foundation
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Brion Vibber]

On Fri, Jul 27, 2012 at 10:59 AM, Chad  wrote:

> On Fri, Jul 27, 2012 at 1:55 PM, Chris McMahon 
> wrote:
> > I realize this is all hand-wavy and stuff, but as Brion pointed out, it's
> > all git.  With some thought behind the design, a two-way integration
> > between gerrit and github seems like it would be possible and useful.
> >
>
> Yes, I agree wholeheartedly. The main reason I've been holding off
> on doing the replication yet is that the replication system was split
> off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so
> I didn't have to set it up twice. Once we've got 2.5 running, this will
> become a *top* priority for me in our Gerrit setup.
>

Yay!


> Pulling stuff back in is probably doable (and I've heard rumors it's
> been done), but will require more investment.
>

Cordova/PhoneGap hosts their primary repositories on Apache infrastructure,
but keeps github mirrors and accepts pull requests through them.

You don't actually need special tooling; they do it pretty bare-bones by
having the accepter pull the branch, merge and push it themselves:
http://wiki.apache.org/cordova/CommitterWorkflow

Taking a pull request, cleaning it up, and popping it into gerrit for its
final verification & +2 is at least no worse than taking a patch from
Bugzilla or direct mail and sticking it in -- but should preserve the
authorship info in the commit.


If we can devise tooling to make it even easier (paste in a pull request's
URL and say "go"), that could be spiffy though.

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Brandon Harris]

On Jul 27, 2012, at 8:47 AM, Jon Robson  wrote:

> This would be best answered by Brandon.From a personal point of view if the
> mobile site still looks like a mobile site in a desktop browser at the
> start of next year I will be somewhat disappointed with myself.

I, too, shall +1 this.  

> I personally believe that mobile is the likely method for accelerating
> athenas development as there are less blockers to do that.

And again, another +1.  Mobile allows us to do radical rethinks - both 
by choice and by necessity.  In fact, it was thinking about how we were going 
to solve some information architecture problems in the mobile space that led to 
much of the reasoning behind the necessity for Athena in the first place.

> A lot of the existing bottle neck from my perspective is due to a lack of
> volunteer developers in the many mobile projects which slows important
> things like this down. Aside from the new design we are also planning some
> cool stuff for Wiki loves monuments with image uploading via mobile phones
> to commons. Poke me off list if you are keen to give time/expertise to help
> accelerate important initiatives like this. :)

Athena's timeline is murky.  We are still very much in the design 
iteration phase as far as layout and interaction goes.  However, the Agora 
project - a Foundation-specific style guide - is pretty far along and should be 
completed soon.


---
Brandon Harris, Senior Designer, Wikimedia Foundation

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


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 2:08 PM, Derric Atzrott
 wrote:
>>Yes, I agree wholeheartedly. The main reason I've been holding off on doing
> the
>>replication yet is that the replication system was split off to a plugin
> for
>>2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it
> up
>>twice. Once we've got 2.5 running, this will become a *top* priority for me
> in
>>our Gerrit setup.
>>
>>Pulling stuff back in is probably doable (and I've heard rumors it's been
> done),
>>but will require more investment.
>>
>>-Chad
>
> Not sure if anyone has mentioned this yet or not, but Gerrit 2.5 is getting
> pretty close to shipping too, so the wait shouldn't be too long.  Skimming
> through their discussion on Google Groups [1] it appears as though as of
> July 11th there have been talks of starting releasing the RC versions of
> Gerrit 2.5.  Not sure how long they usually end up staying in the RC stage
> before an actual release, but I can't imagine it is long.
>

Actually, a discussion started this morning again about what needs
doing before the branch happens. The release manager for this cycle
listed a couple of bullet points. That thread is here[0].

In general, the RC cycle is pretty quick--there's no firm rules, generally
lasts a couple of weeks while any major remaining blockers are ironed
out. I imagine we'll be seeing 2.5 final by late August at the latest.

-Chad

[0] https://groups.google.com/d/msg/repo-discuss/rxHwJJ2X9Ug/f7_6qMcsRYMJ

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Captcha for non-English speakers II

[Yury Katkov]

I think that making Russian, Korean and Arabian captcha is really bad idea.
English keyboad layout is installed by default in all operation systems, as
far as I know. Moreover very interesting problems can appear if this
feature would be implemented. Who will decide what captcha language is
used? We can look at user IP address - then sometimes the foreigners will
be in trouble. We can use Ukrainian capcha for the Ukrainian wesites - thus
assuming that every person who knows Ukrainian has the Ukrainian keyboard
layout, which is not true.
I think that the assumption that "everyone in the internet is able to print
English letters loking at their noised example" is not very bold assumption.
26.07.2012 17:53 пользователь "Everton Zanella Alvarenga" <
ezalvare...@wikimedia.org> написал:

> Hi all,
>
> how are you? I'd like to know about the possibility of solving an old
> issue with CAPTCHA for Wikipedias in languages other than English.
> This bug
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=5309
>
> was created in 2006. There is a discussion here about having CAPTCHA
> in other languages from February 2012
>
>
> http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/51951/
>
> but it seems there was no conclusion. After working on campus with new
> editors in Brazil, I've checked this is a real obstacle, since most
> people here cannot ready English at all.
>
> I'd like to know if there are plans to solve this issue - I hope I
> don't sound rude, maybe this can be a minor issue when we don't see
> the difficulties people from a different place can face. I think this
> is important for Wikipedias other than the English one (just read
> people comments in the bug) and we can be loosing new contributors
> because of their first impressions. Thanks,
>
> Tom
>
> --
> Everton Zanella Alvarenga (also Tom)
> Wikimedia Brasil
> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Derric Atzrott]

Forgot the link...

[1] https://groups.google.com/forum/#!topic/repo-discuss/ZczND3xgtaw

Sorry about that,
Derric Atzrott
Computer Specialist
Alizee Pathology


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Derric Atzrott]

>Yes, I agree wholeheartedly. The main reason I've been holding off on doing
the
>replication yet is that the replication system was split off to a plugin
for
>2.5, so I was pretty much waiting on 2.5 to land so I didn't have to set it
up
>twice. Once we've got 2.5 running, this will become a *top* priority for me
in
>our Gerrit setup.
>
>Pulling stuff back in is probably doable (and I've heard rumors it's been
done),
>but will require more investment.
>
>-Chad

Not sure if anyone has mentioned this yet or not, but Gerrit 2.5 is getting
pretty close to shipping too, so the wait shouldn't be too long.  Skimming
through their discussion on Google Groups [1] it appears as though as of
July 11th there have been talks of starting releasing the RC versions of
Gerrit 2.5.  Not sure how long they usually end up staying in the RC stage
before an actual release, but I can't imagine it is long.

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 1:55 PM, Chris McMahon  wrote:
> On Fri, Jul 27, 2012 at 11:29 AM, Rob Lanphier  wrote:
>
>>
>> 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.
>>
>>
> One thing I don't think has been explicitly said yet, although Brion hinted
> at it early on is the nature of the gerrit-github integration.  Gerrit
> serves the required workflow well for things like core and key extensions
> and puppet, so having changes made via gerrit reflected in a github view is
> great for outsiders to explore and experiment.
>
> But it would also be great, especially for certain types of community
> contributions, if we could approve pull requests from github and have those
> reflected in gerrit.
>
> I realize this is all hand-wavy and stuff, but as Brion pointed out, it's
> all git.  With some thought behind the design, a two-way integration
> between gerrit and github seems like it would be possible and useful.
>

Yes, I agree wholeheartedly. The main reason I've been holding off
on doing the replication yet is that the replication system was split
off to a plugin for 2.5, so I was pretty much waiting on 2.5 to land so
I didn't have to set it up twice. Once we've got 2.5 running, this will
become a *top* priority for me in our Gerrit setup.

Pulling stuff back in is probably doable (and I've heard rumors it's
been done), but will require more investment.

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.

[Chris Steipp]

I wanted to get in a couple responses to Daniel, as well as try to
make sure the conversation doesn't die. Obviously having a lead person
in the OAuth2 process leave may effect what we want to implement. Or
may spawn a new standard in the near future. But I hope we can still
move ahead with laying the foundation for allowing other entities and
applications to work with mediawiki and WMF sites, and specifically
make sure that third parties can interact with WMF sites in a way that
is more secure than currently possible.

> From the start of the OAuth idea I've been thinking we should handle the
> code in an abstract way.

I definitely agree with you there, although deciding which
functionality is common is obviously the tricky part. Where we draw
that line can greatly effect the effort that is required to implement,
so I want to make sure we draw it appropriately.

I think recognizing that a user's session may have a different set of
permissions from the permissions that their group membership gives
them definitely falls into that category. Keeping track of the concept
of external entities (whether it's a university serving SAML, or an
app developer using oauth) may also fall into this category. Thoughts
from other developers?

> - I started thinking that every user instance should have some sort of
> ->getApplication()/->getAuthorization() connection. And this would be used
> when noting what was responsible for various edits/logs/etc...

I think I understand what your saying about that, and that's one way
it could be done. I had also given some thought to extending the user,
so that an OAuth user would have limited permissions, and a SAML user
may not even exist in the data store etc. But it would be good to
hear from other developers if they have thoughts on it?

> - To top all this off we could potentially also make a special built-in
> "Import" application. This would result in all edits made by importing
> edits from another wiki being nicely annotated in the UI with information
> saying they were imported rather than actually made on the wiki by said
> person.

I hadn't heard other people mention tracking edits by Import or the
Installer, but if there's support for that type of thing, then I
agree, this might be a good place to include it.

>
> What does everyone think of this idea?
>

Hopefully the lack of response was due to everyone recovering from
wikimania instead of lack of enthusiasm for OAuth!

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chris McMahon]

On Fri, Jul 27, 2012 at 11:29 AM, Rob Lanphier  wrote:

>
> 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.
>
>
One thing I don't think has been explicitly said yet, although Brion hinted
at it early on is the nature of the gerrit-github integration.  Gerrit
serves the required workflow well for things like core and key extensions
and puppet, so having changes made via gerrit reflected in a github view is
great for outsiders to explore and experiment.

But it would also be great, especially for certain types of community
contributions, if we could approve pull requests from github and have those
reflected in gerrit.

I realize this is all hand-wavy and stuff, but as Brion pointed out, it's
all git.  With some thought behind the design, a two-way integration
between gerrit and github seems like it would be possible and useful.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Tomasz Finc]

On Fri, Jul 27, 2012 at 8:47 AM, Jon Robson  wrote:
> This would be best answered by Brandon.From a personal point of view if the
> mobile site still looks like a mobile site in a desktop browser at the
> start of next year I will be somewhat disappointed with myself.

+1

> I personally believe that mobile is the likely method for accelerating
> athenas development as there are less blockers to do that.

We should be looking at Athena (and other projects like it) as
guidance for how were going to approach contribution projects on
mobile. Our focus for the next year is to not just grow the readership
base but to also grow the contributor base. We've never had as many
eyes on Wikipedia as before who can't contribute. Mobile users can't
be second class citizens within the Wikimedia projects. We have to
build all new pipelines on mobile devices to make this happen. These
contributor methods may look drastically different then their desktop
counterparts.

Responsive design is an interesting technique for layout but it breaks
down for functionality. A mobile phone, a tablet, and a desktop/laptop
are used very differently. Mimicking the exact same functionality
means your failing to understand what's best for each device.

> A lot of the existing bottle neck from my perspective is due to a lack of
> volunteer developers in the many mobile projects which slows important
> things like this down. Aside from the new design we are also planning some
> cool stuff for Wiki loves monuments with image uploading via mobile phones
> to commons. Poke me off list if you are keen to give time/expertise to help
> accelerate important initiatives like this.

I'm going to re-iterate what Jon said here. We have numerous projects
going on now and we've been actively mailing, blogging, and tweeting
to get new testers/developers/etc. Were always eager to get more
people involved. If you need to catch up with what were working on
just check the mobile projects pages.

http://www.mediawiki.org/wiki/Mobile

--tomasz

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Platonides]

Chad wrote:
> 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.
That made me go to some bugs I experienced at the beginning, and look if
they were thus fixed or not.

> Issue 899:Tab to password field doesn't work if diff page is in
> background Filed: Apr 7, 2011 -
> http://code.google.com/p/gerrit/issues/detail?id=899
The bug is still open, although it got fixed. Maybe independently,
perhaps unexpectedly due to rewriten code. It took ~1 year to fix since
being filed.

> Issue 1300:   No history of removal actions Filed: Mar 25, 2012 -
> http://code.google.com/p/gerrit/issues/detail?id=1300
Pristine bug.

> Bug 35468 https://bugzilla.wikimedia.org/show_bug.cgi?id=35468
> Filed 2012-03-25 - Still happening.



The funny thing is that it is happening on gerrit.wikimedia.org
but not on https://gerrit-review.googlesource.com or
https://android-review.googlesource.com


So although they may be very responsive to patches, it may not be so
easy to get the bugs solved (other than doing so ourselves, which as
said, is not simple).



> 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).
Which is really annoying when you don't start from the home page. If I'm
signing in from a change, that's because I want to comment/review on
that change, not to go to a dashboard where it isn't even listed.

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

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


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

I don't feel comfortable with it. Too much magic, probably. It would
benefit from having an interace like bugzilla advanced search, even if
it gets coverted to the operators.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 1:29 PM, Rob Lanphier  wrote:
>  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.
>

I wrote a new plugin last night and pushed it today:

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

It took like...an hour? Yay for me ;-)

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Rob Lanphier]

On Fri, Jul 27, 2012 at 6:42 AM, 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Ryan Lane]

On Fri, Jul 27, 2012 at 6:42 AM, 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Ryan Lane]

> 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Antoine Musso]

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.


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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Jon Robson]

This would be best answered by Brandon.From a personal point of view if the
mobile site still looks like a mobile site in a desktop browser at the
start of next year I will be somewhat disappointed with myself.

I personally believe that mobile is the likely method for accelerating
athenas development as there are less blockers to do that.

A lot of the existing bottle neck from my perspective is due to a lack of
volunteer developers in the many mobile projects which slows important
things like this down. Aside from the new design we are also planning some
cool stuff for Wiki loves monuments with image uploading via mobile phones
to commons. Poke me off list if you are keen to give time/expertise to help
accelerate important initiatives like this. :)
On Jul 27, 2012 8:34 AM, "John Elliot"  wrote:

> On 2012-07-27 23:52, Jon Robson wrote:
> > The Wikipedia mobile site is being made mobile first using responsive
> > design techniques. The plan is for it to eventually mature into a
> > responsive Athena skin that can also be used on desktop.
>
> Any idea about when the responsive Athena skin might be ready? 1 month,
> 3 months, a year?
>
>
>
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[David Gerard]

On 27 July 2012 16:35, Sumana Harihareswara  wrote:

> Please note that this conversation might also be cross-posted to or
> continued on our design mailing list:
> https://lists.wikimedia.org/mailman/listinfo/design


Without joining a whole other list, can I just ask what attention is
being paid to people less connected than San Francisco geeks with
iPads? Editing Wikipedia is presently annoyingly slow on a 1Mbps
connection and pretty much unfeasible on dialup, for example.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 11:33 AM, Roan Kattouw  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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Sumana Harihareswara]

On 07/27/2012 11:34 AM, John Elliot wrote:
> On 2012-07-27 23:52, Jon Robson wrote:
>> The Wikipedia mobile site is being made mobile first using responsive
>> design techniques. The plan is for it to eventually mature into a
>> responsive Athena skin that can also be used on desktop.
> 
> Any idea about when the responsive Athena skin might be ready? 1 month,
> 3 months, a year?

Please note that this conversation might also be cross-posted to or
continued on our design mailing list:
https://lists.wikimedia.org/mailman/listinfo/design

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[John Elliot]

On 2012-07-27 23:52, Jon Robson wrote:
> The Wikipedia mobile site is being made mobile first using responsive
> design techniques. The plan is for it to eventually mature into a
> responsive Athena skin that can also be used on desktop.

Any idea about when the responsive Athena skin might be ready? 1 month,
3 months, a year?






___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Roan Kattouw]

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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Roan Kattouw]

On Jul 27, 2012 7:17 AM, "Faidon Liambotis"  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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Roan Kattouw]

On Jul 27, 2012 6:58 AM, "Chad"  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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wiki-research-l] request for Git statistics (or, "don't stand back, I don't know regular expressions") (Wiki-research-l Digest, Vol 83, Issue 13)

[Sumana Harihareswara]

On 07/24/2012 08:09 PM, Federico Leva (Nemo) wrote:
> Sumana Harihareswara, 24/07/2012 22:47:
>> Ohloh would sure be a nice resource - I'm not sure how to get it fixed
>> exactly, but please feel free to poke around, tell Ohloh where our new
>> repository is, and try to get it fixed.  Sorry, it's a low priority for
>> me right now, but you have my authorization to try to get it fixed.
> 
> The new repo for core was already there, but extensions were missing;
> I've now added them. https://www.ohloh.net/p/mediawiki
> (Some seem to partially disagree, by the way.)

Thanks for stepping up and improving our Ohloh listing, Nemo!  I hope
others can help you in figuring out and resolving any contradictions.

>> By the way, the WMF analytics team is working on some new analysis tools
>> for our use of Gerrit but it's still very rough.
>> https://gerrit.wikimedia.org/r/gitweb?p=analytics/gerrit-stats.git;a=summary
>>
>> is the repository to follow
>> (https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core,n,z).
>>
> 
> Yes, we have big hopes in this! :)
> 
> Nemo

A note from Felipe Ortega that I got permission to forward onlist:

> 
> Hi Sumana.
> 
> I see that you have solved your request.
> 
> I'm not sure if you know the toolset from my current research group for 
> extracting and analyzing data from Git, as well as for other version control 
> systems:
> 
> http://git.libresoft.es/cvsanaly
> 
> In fact, despite the name it supports CVS, SVN and Git. Here you can find a 
> glimpse of the type of data that it can generate:
> 
> http://git.libresoft.es/cvsanaly/tree/db/cvsanaly_model.svg
> 
> We also have another tools for analyzing issue tracking systems (Bugzilla, 
> SF.net, Allura, GitHub, JIRA, and Launchpad, so far).
> 
> http://git.libresoft.es/bicho
> 
> I'm not sure but they could probably help you monitor project resources and 
> solve these kind of questions. My current group at URJC has started a spinoff 
> based on these services, and they are already producing some interesting 
> stuff for clients like Samsung (for their network of partners in Android) or 
> OpenStack. Here is a mockup (they are using envision.js):
> 
> http://gsyc.es/~jgb/repro/2012-akademyes-kdevelop/swscopio.html
> 
> 
> Well, hope this helps.
> 
> Felipe.



-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Captcha for non-English speakers II

[Everton Zanella Alvarenga]

2012/7/26 Platonides :

> Thet don't need to read English. They just need to type the letters they
> see on the image. Sure, you can have a small advantage if you know what
> letters could make a valid English word (or if you have the captcha
> dictionary installed), but a Brazilian which can read wikipedia should
> have no problems typing the captcha.

If that is the case, why don't we change the CAPTCH for random letters?

-- 
Everton Zanella Alvarenga (also Tom)
Wikimedia Brasil
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Faidon Liambotis]

On Thu, Jul 26, 2012 at 11:36:50PM -0700, Rob Lanphier wrote:
> On Thu, Jul 26, 2012 at 12:49 PM, Faidon Liambotis 
> 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 9:42 AM, 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Jon Robson]

The Wikipedia mobile site is being made mobile first using responsive
design techniques. The plan is for it to eventually mature into a
responsive Athena skin that can also be used on desktop.
On Jul 27, 2012 4:24 AM, "Tei"  wrote:

> On 27 July 2012 12:53, Peter Coombe  wrote:
> > This is one of the aims of the planned 'Athena' skin:
> > https://www.mediawiki.org/wiki/Athena
> >
> > Pete / the wub
>
> Very interesting. Looks very good already.
>
>
> On 27 July 2012 12:01, John Elliot  wrote:
> > Are there any initiatives in the MediaWiki community for a MediaWiki
> > theme that supports 'responsive design' [1] -- where content is properly
> > laid out in an accessible form on all manner of devices including
> > desktops and smart phones?
> >
> > [1] http://www.alistapart.com/articles/responsive-web-design/
> >
>
> Ouch. This website is aligned to the left, and designed for a fixed
> width of 1024px.
>
> *reads content*
>
> Yet again, we remember that HTML is liquid. Is supposed to be, wen is
> made fixed, is because compromises.
>
>
> On 27 July 2012 12:08, David Gerard  wrote:
> > On 27 July 2012 11:01, John Elliot  wrote:
> >
> >> Are there any initiatives in the MediaWiki community for a MediaWiki
> >> theme that supports 'responsive design' [1] -- where content is properly
> >> laid out in an accessible form on all manner of devices including
> >> desktops and smart phones?
> >> [1] http://www.alistapart.com/articles/responsive-web-design/
> >
> >
> > http://blog.tommorris.org/post/21073443312/introducing-awfulness-js
> >
> > HTML 3.2 is looking better every day ...
>
> Infinite scrolling is not always evil.
>
> If you need to show a PDF document as a list of 200 high resolution
> JPG files. You can make the page height the resulting height if all
> the jpg where downloaded. But only download the JPG the user is
> looking at.
> If you try the naive approach,and create a html that links with 
> all the 700KB jpg files,  the page will chocke for most users, because
> will ask for too much bandwidth too quick. And maybe the users only
> need to look at the first page, to confirm is interesting (maybe are
> books, and is the wrong book, or in the wrong language ).
>
> http://es.scribd.com/doc/6457786/Godel-Escher-Bach-by-Douglas-R-Hofstadter-
>
> By making a document become a computer program, we probably lose the
> ability to garantee it will end rendering before the end of the
> existence of the universe. But is often a good tradeoff.
>
>
> --
> --
> ℱin del ℳensaje.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[MZMcBride]

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:
. 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:  ("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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 3:46 AM, Antoine Musso  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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Chad]

On Fri, Jul 27, 2012 at 2:36 AM, Rob Lanphier  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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Tei]

On 27 July 2012 12:53, Peter Coombe  wrote:
> This is one of the aims of the planned 'Athena' skin:
> https://www.mediawiki.org/wiki/Athena
>
> Pete / the wub

Very interesting. Looks very good already.


On 27 July 2012 12:01, John Elliot  wrote:
> Are there any initiatives in the MediaWiki community for a MediaWiki
> theme that supports 'responsive design' [1] -- where content is properly
> laid out in an accessible form on all manner of devices including
> desktops and smart phones?
>
> [1] http://www.alistapart.com/articles/responsive-web-design/
>

Ouch. This website is aligned to the left, and designed for a fixed
width of 1024px.

*reads content*

Yet again, we remember that HTML is liquid. Is supposed to be, wen is
made fixed, is because compromises.


On 27 July 2012 12:08, David Gerard  wrote:
> On 27 July 2012 11:01, John Elliot  wrote:
>
>> Are there any initiatives in the MediaWiki community for a MediaWiki
>> theme that supports 'responsive design' [1] -- where content is properly
>> laid out in an accessible form on all manner of devices including
>> desktops and smart phones?
>> [1] http://www.alistapart.com/articles/responsive-web-design/
>
>
> http://blog.tommorris.org/post/21073443312/introducing-awfulness-js
>
> HTML 3.2 is looking better every day ...

Infinite scrolling is not always evil.

If you need to show a PDF document as a list of 200 high resolution
JPG files. You can make the page height the resulting height if all
the jpg where downloaded. But only download the JPG the user is
looking at.
If you try the naive approach,and create a html that links with 
all the 700KB jpg files,  the page will chocke for most users, because
will ask for too much bandwidth too quick. And maybe the users only
need to look at the first page, to confirm is interesting (maybe are
books, and is the wrong book, or in the wrong language ).

http://es.scribd.com/doc/6457786/Godel-Escher-Bach-by-Douglas-R-Hofstadter-

By making a document become a computer program, we probably lose the
ability to garantee it will end rendering before the end of the
existence of the universe. But is often a good tradeoff.


-- 
--
ℱin del ℳensaje.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Peter Coombe]

This is one of the aims of the planned 'Athena' skin:
https://www.mediawiki.org/wiki/Athena

Pete / the wub


On 27 July 2012 11:01, John Elliot  wrote:
> Are there any initiatives in the MediaWiki community for a MediaWiki
> theme that supports 'responsive design' [1] -- where content is properly
> laid out in an accessible form on all manner of devices including
> desktops and smart phones?
>
> [1] http://www.alistapart.com/articles/responsive-web-design/
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[Leonard Wallentin]

> Are there any initiatives in the MediaWiki community for a MediaWiki
> theme that supports 'responsive design' [1] -- where content is properly
> laid out in an accessible form on all manner of devices including
> desktops and smart phones?
> 

I am currently working a bit on the skin for http://säsongsmat.nu to make it 
more responsive (I've gone through the head and footer, but still have work to 
do on the article rendering, e.g. hooking into the MW image rendering). Let me 
know if you want me to share the code! 
Best regardsLeo Wallentin 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Responsive web design

[David Gerard]

On 27 July 2012 11:01, John Elliot  wrote:

> Are there any initiatives in the MediaWiki community for a MediaWiki
> theme that supports 'responsive design' [1] -- where content is properly
> laid out in an accessible form on all manner of devices including
> desktops and smart phones?
> [1] http://www.alistapart.com/articles/responsive-web-design/


http://blog.tommorris.org/post/21073443312/introducing-awfulness-js

HTML 3.2 is looking better every day ...


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Responsive web design

[John Elliot]

Are there any initiatives in the MediaWiki community for a MediaWiki
theme that supports 'responsive design' [1] -- where content is properly
laid out in an accessible form on all manner of devices including
desktops and smart phones?

[1] http://www.alistapart.com/articles/responsive-web-design/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Daniel Friesen]

On Fri, 27 Jul 2012 01:10:52 -0700, Antoine Musso   
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
 

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 


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  
branche

Re: [Wikitech-l] Criteria for "serious alternative"

[Antoine Musso]

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
 

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 

> 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@lists.wikimed

Re: [Wikitech-l] Criteria for "serious alternative"

[Antoine Musso]

Le 27/07/12 04:04, MZMcBride 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.

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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Criteria for "serious alternative"

[Daniel Friesen]

On Thu, 26 Jul 2012 23:43:51 -0700, Ryan Lane  wrote:


On Thu, Jul 26, 2012 at 10:57 PM, 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:
.  
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:   
("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  
cr