Re: [Wikitech-l] Announcing a new extension - SideBarMenu,

[Kim Eik]

The extension can be customized to your needs by hooking into
the .sidebar-menu-container css class.

setting this to include position: fixed; will get desired result.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r113517]: New comment added, and revision status changed

[MediaWiki Mail]

"Wikinaut" changed the status of MediaWiki.r113517 to "new" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113517#c32056

Old Status: fixme
New Status: new

Commit summary for MediaWiki.r113517:

add tracking category feature (enabled by default). Each page using this 
extension get automatically the tracking category with 
MediaWiki:Wikiarticlefeeds-tracking-category name (= RSS authoring page). 
Tracking-Cat-Feature can be disabled, or a different MediaWiki message text can 
be assigned. Documentation of the switch is inline and follows on MediaWiki.

Wikinaut's comment:

set new (see follow up r113541 where it is resolved)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r111964]: New comment added

[MediaWiki Mail]

"Dantman" posted a comment on MediaWiki.r111964.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111964#c32057

Commit summary for MediaWiki.r111964:

Commit a new cryptographic random generator class for use in MediaWiki.
Waiting for it to be reviewed before actually making use of it inside code and 
adding a RELEASE-NOTES entry.

Dantman's comment:

I've cloned our core git repo and put MWCryptRand into a branch and pushed it 
to GitHub while it's being worked on. When it's done I can make it a svn commit 
or commit it to our git repo when we start production use of it. (I actually 
already converted a test/mediawiki/core clone into an incompatible 
mediawiki/core clone so any changes in the underlying repo won't be a problem)

I've already added stream_set_read_buffer and the 4k -> 8k change.

https://github.com/dantman/mediawiki-core/blob/cryptrand/includes/CryptRand.php

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] PDF Download

[Nasir Khan]

Hi Santosh,
In some other thread of this mailing list i found that TCPDF(www.tcpdf.org/)
have a good support for the unicode, but i just downloaded the code and
tried it. I found that it also have some issues on for the Bengali/indic
texts. Have you tried with this library?

I will apply for the GSoC on this project and before staring on a specific
tool i would like to study the other existing tools. Because though they do
not have to full support for the languages but  they are good at some
points, like Render can render the texts properly and existing pdf tool
works well with the collection extension.

thanks
nasir



On Thu, Mar 8, 2012 at 4:55 PM, Volker Haas wrote:

> Hi all.
>
> I just wanted to confirm that Santosh's description of the current
> limitations of the PDF rendering engine are accurate.
>
> Regarding the GSOC project: As the principal developer of the current PDF
> rendering I'd also be happy to share insights on PDF rendering. Let me know
> if I can do anything to help.
>
> Best Regards,
> Volker
>
> Am 04.03.2012 07:30, schrieb Sumana Harihareswara:
>
>  On 03/03/2012 10:25 PM, Santhosh Thottingal wrote:
>>
>>> Here i have a question that at this moment is there any developer of
 developer group is working on this issue? if yes then i want to join
 with
 him.

>>> I had discussed this with Pediapress developers in the past.  I
>>> started a project many months back to develop a general purpose PDF
>>> rendering library for complex scripts and I had announced it here:
>>> http://lists.wikimedia.org/**pipermail/wikimediaindia-l/**
>>> 2011-February/002198.html
>>> And I have an online version based on the code in development
>>> http://silpa.org.in/Render. It can create PDFs from Bengali wiki pages
>>> and possibly most of the scripts that we support. The text rendering
>>> engine used is Pango. This is my petproject and 2-3 people joined me,
>>> but recently it is inactive in development since we are not getting
>>> free time.  The library require lot of work to reach a reasonably
>>> usable state. Then it require good amount of effort to integrate with
>>> collection extension.
>>>
>>> The project is hosted at 
>>> https://savannah.nongnu.org/**projects/pypdflib
>>> and available in Debian.
>>>
>>>
>>> Thanks
>>> Santhosh
>>>
>> Santhosh, it looks like Nasir might be interested in working on this as
>> a Google Summer of Code project:
>>
>>  ... Is [it] possible to apply GSoC for this issue.
>>>
>> If this is the case, Santhosh, would you be interested in possibly
>> mentoring Nasir?
>>
>>
>
> --
> Volker Haas
> Senior Developer
> brainbot technologies ag
> Boppstraße 64
> 55118 Mainz
> Phone: +49 (0)6131 2116394
>
>
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] started 6th book in the MediaWiki Virtual Library (MVL): MediaWiki Git Guide (MGG)

[Yury Katkov]

This MVL looks awesome! I've spent weeks in searching good developer
documentation that would be aggregated in one place and it turns out that
such this always was near. Thanks for this super useful page, I definetely
have to add links to it from other mediawiki pages.
10.03.2012 10:38 пользователь "Thomas Gries"  написал:

> @ all:
> please feel invited to add (*) relevant article pages to
> https://www.mediawiki.org/wiki/MGG
>
> MGG is one of currently 6 books in our virtual library
> MVL https://www.mediawiki.org/wiki/MVL
>
> @ Sumanah:
> when do think is the bot ready to automatically assign a tracking
> category of those articles,
> which are part of MVL books ? We spoke about this recently.
>
> (*) in "Extension:Collection" style
>
>
> ___
> 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] started 6th book in the MediaWiki Virtual Library (MVL): MediaWiki Git Guide (MGG)

[Chad]

You really don't need to include the issues page, that's useless to almost
everyone. Probably don't need the migration page either.

-Chad
On Mar 10, 2012 1:38 AM, "Thomas Gries"  wrote:

> @ all:
> please feel invited to add (*) relevant article pages to
> https://www.mediawiki.org/wiki/MGG
>
> MGG is one of currently 6 books in our virtual library
> MVL https://www.mediawiki.org/wiki/MVL
>
> @ Sumanah:
> when do think is the bot ready to automatically assign a tracking
> category of those articles,
> which are part of MVL books ? We spoke about this recently.
>
> (*) in "Extension:Collection" style
>
>
> ___
> 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

[MediaWiki-CodeReview] [MediaWiki r112423]: New comment added

[MediaWiki Mail]

"Amire80" posted a comment on MediaWiki.r112423.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/112423#c32058

Commit summary for MediaWiki.r112423:

Fixes bug 34723: applies the English language to CSS/JS both as a user subpage 
and a MediaWiki space page, and consequently applies LTR to JS and CSS in the 
textarea.

Amire80's comment:

Sorry, r112428.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] started 6th book in the MediaWiki Virtual Library (MVL): MediaWiki Git Guide (MGG)

[Thomas Gries]

Am 10.03.2012 11:38, schrieb Chad:
> You really don't need to include the issues page, that's useless to almost
> everyone. Probably don't need the migration page either.
>
> -Chad
it ist a starting point. Later we can remove the less-interesting pages.

BTW: started a "Git/Ask_your_questions" page :
https://www.mediawiki.org/wiki/Talk:Git/Questions
Purpose:
to collect questions. The corresponding article page can then be used to
summarise and answer the questions of general interest.




signature.asc
Description: OpenPGP digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] diff colors - more tweaking

[Erwin Dokter]

Trevor Parscal wrote:
>

I changed it to from #f2f2f2 to #f3f3f3, which is the same as Vector uses
on the sidebar and footer. I know it seems subtle, but it's actually
more noticeable than you would expect due to where it falls on a monitor's
gamma curve. Any lighter and many people's monitors will render it as white.

See r113098

- Trevor


Actually, the default background color for the Vector sidebar and footer 
is #f6f6f6, which is still pretty distinct. I would use #f9f9f9; the 
default background color for wikitables.


--
Erwin Dokter


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

[MediaWiki-CodeReview] [MediaWiki r113518]: New comment added

[MediaWiki Mail]

"Krinkle" posted a comment on MediaWiki.r113518.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113518#c32059

Commit summary for MediaWiki.r113518:

No need to create a new Revision object if we already have one available

Krinkle's comment:

Would it make sense to apply a similar change to the Revision instantiation 
from oldid around line 254 in Article::getOldIDFromRequest ? 

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] Submit a talk to Open Source Bridge by Mar 16th, get WMF subsidy

[Sumana Harihareswara]

This year I want the Wikimedia technical community to have a strong
presence at Open Source Bridge  in
Portland, Oregon, USA, June 26-29.  OSB is tech talks & hack sessions
with hands-on technologists we want, for Foundation staff recruiting
(the Portland tech scene has good people looking for jobs) and for
volunteer recruiting and collaboration (tons of Mozilla people went
there last year).  Good talks, clueful people, great food. :-)

If you submit a talk and it gets accepted, tell me, and Wikimedia
Foundation will partially subsidize or fully pay for your flight and
hotel.  If you submit a talk and it doesn't get accepted but you still
want to go, talk with me and I'll see what I can do.

Call for talks:

 Ideas: the parser rewrite, Wikimedia Labs, how we scale and optimize
performance on a shoestring budget, our git/gerrit migration, securing
PHP-based webapps, various approaches to making our data more
structured/semantic, collaborative design, lessons from our communities,
JS hacks, hetdeploy, offline/mobile, geodata...

Please forward.

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Submit a talk to Open Source Bridge by Mar 16th, get WMF subsidy

[Sumana Harihareswara]

On 03/10/2012 08:25 AM, Sumana Harihareswara wrote:
> This year I want the Wikimedia technical community to have a strong
> presence at Open Source Bridge  in
> Portland, Oregon, USA, June 26-29.  OSB is tech talks & hack sessions
> with hands-on technologists we want, for Foundation staff recruiting
> (the Portland tech scene has good people looking for jobs) and for
> volunteer recruiting and collaboration (tons of Mozilla people went
> there last year).  Good talks, clueful people, great food. :-)
> 
> If you submit a talk and it gets accepted, tell me, and Wikimedia
> Foundation will partially subsidize or fully pay for your flight and
> hotel.  If you submit a talk and it doesn't get accepted but you still
> want to go, talk with me and I'll see what I can do.
> 
> Call for talks:
> 
>  Ideas: the parser rewrite, Wikimedia Labs, how we scale and optimize
> performance on a shoestring budget, our git/gerrit migration, securing
> PHP-based webapps, various approaches to making our data more
> structured/semantic, collaborative design, lessons from our communities,
> JS hacks, hetdeploy, offline/mobile, geodata...
> 
> Please forward.

(I should add -- also there would be complications if somehow lots of
Wikimedia people get their talks accepted and I can't budget to
subsidize all of them, or you can't get a visa to the US in time, or
some unforeseen thing comes up like that.  But I don't predict those
problems happening.)

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

[MediaWiki-CodeReview] [MediaWiki r113518]: New comment added

[MediaWiki Mail]

"IAlex" posted a comment on MediaWiki.r113518.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113518#c32060

Commit summary for MediaWiki.r113518:

No need to create a new Revision object if we already have one available

IAlex's comment:

Isn't that r113468?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] Google Summer of Code update & how we'll run it

[Sumana Harihareswara]

I submitted our application to Google and we're just waiting for March
16th, when we'll hear whether we've been accepted.

I can't handle all the student-helping on my own, so please try to guide
prospective students -- point them to
https://www.mediawiki.org/wiki/Summer_of_Code_2012 and encourage them to
read the FAQ linked there.  Gregory Varnum (varnent) has also accepted
my request to be my backup on running our GSoC participation this year,
so if someone needs shepherding, Greg can help.

https://www.mediawiki.org/wiki/Summer_of_Code_2012/management#GSoC_management_philosophy
has my plans for running GSoC this year. Key points: People are more
important than code;  Hands-on mentorship and management; Quality over
quantity, scope small.

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Announcing a new extension - SideBarMenu,

[Alex Brollo]

Thank you, we did, but we wrapped the needed  jQuery code into a gadget, so
that users can set it as a personal preference. Our gadgets are growinig
and growing in number and performance! :-)

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

[Wikitech-l] HTTPS preference?

[MZMcBride]

Hi.

https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 is about adding a user
preference for HTTP vs. HTTPS while a user is logged in.

I'd really like to see this bug resolved, as I regularly encounter HTTP
links and the lack of auto-redirection is becoming a larger and larger
usability problem for me. (I don't use HTTPS-Everywhere on my personal
computer.)

I have a few questions for this list:

* Does a user preference make sense here? I argued on that bug that adding
an intermediate user preference seems a bit silly (letting the user shoot
themselves in the foot), but it's apparently common to give the user a
choice (Gmail, Twitter, Facebook, etc. all allow a choice).

(This next question is for Wikimedia ops.)

* If a user preference is implemented and the default is set to HTTPS, is
the current infrastructure ready for the increased load? That is, if the
code were magically ready tomorrow, could HTTPS be immediately deployed as a
default for logged-in users without causing any problems?

MZMcBride



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

[Wikitech-l] MediaWiki and Python

[Steven Walling]

Sandboxed Python + MediaWiki = PyPedia.

PDF: http://dl.dropbox.com/u/5548517/PyPedia.pdf

Seems interesting. Thoughts?

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

Re: [Wikitech-l] started 6th book in the MediaWiki Virtual Library (MVL): MediaWiki Git Guide (MGG)

[Sumana Harihareswara]

On 03/09/2012 10:38 PM, Thomas Gries wrote:
> @ all:
> please feel invited to add (*) relevant article pages to
> https://www.mediawiki.org/wiki/MGG
> 
> MGG is one of currently 6 books in our virtual library
> MVL https://www.mediawiki.org/wiki/MVL
> 
> @ Sumanah:
> when do think is the bot ready to automatically assign a tracking
> category of those articles,
> which are part of MVL books ? We spoke about this recently.
> 
> (*) in "Extension:Collection" style

I wouldn't mind if a bot automatically added a category to relevant
pages on mediawiki.org, starting now, to indicate that they're part of
the MediaWiki Virtual Library and to indicate what virtual books they're
in.  I don't have the expertise to do that myself with a bot, but if you
want to do it, I think that's fine.

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] HTTPS preference?

[Krenair]

I like this idea, but I think that it should be done as a global preference 
(https://bugzilla.wikimedia.org/show_bug.cgi?id=14950).

Krenair

On 10/03/12 18:58, MZMcBride wrote:


Hi.

https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 is about adding a user
preference for HTTP vs. HTTPS while a user is logged in.

I'd really like to see this bug resolved, as I regularly encounter HTTP
links and the lack of auto-redirection is becoming a larger and larger
usability problem for me. (I don't use HTTPS-Everywhere on my personal
computer.)

I have a few questions for this list:

* Does a user preference make sense here? I argued on that bug that adding
an intermediate user preference seems a bit silly (letting the user shoot
themselves in the foot), but it's apparently common to give the user a
choice (Gmail, Twitter, Facebook, etc. all allow a choice).

(This next question is for Wikimedia ops.)

* If a user preference is implemented and the default is set to HTTPS, is
the current infrastructure ready for the increased load? That is, if the
code were magically ready tomorrow, could HTTPS be immediately deployed as a
default for logged-in users without causing any problems?

MZMcBride



___
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] HTTPS preference?

[Daniel Friesen]

On Sat, 10 Mar 2012 10:58:19 -0800, MZMcBride  wrote:


Hi.

https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 is about adding a  
user

preference for HTTP vs. HTTPS while a user is logged in.

I'd really like to see this bug resolved, as I regularly encounter HTTP
links and the lack of auto-redirection is becoming a larger and larger
usability problem for me. (I don't use HTTPS-Everywhere on my personal
computer.)

I have a few questions for this list:

* Does a user preference make sense here? I argued on that bug that  
adding

an intermediate user preference seems a bit silly (letting the user shoot
themselves in the foot), but it's apparently common to give the user a
choice (Gmail, Twitter, Facebook, etc. all allow a choice).

(This next question is for Wikimedia ops.)

* If a user preference is implemented and the default is set to HTTPS, is
the current infrastructure ready for the increased load? That is, if the
code were magically ready tomorrow, could HTTPS be immediately deployed  
as a

default for logged-in users without causing any problems?

MZMcBride


I believe the idea of a HTTPS preference was WONTFIXed under the premise  
that the final goal is to have all logged in users unconditionally using  
https.


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

[MediaWiki-CodeReview] [MediaWiki r113563]: New comment added

[MediaWiki Mail]

"Reedy" posted a comment on MediaWiki.r113563.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113563#c32061

Commit summary for MediaWiki.r113563:

ignore git

Reedy's comment:

Put your fingers in your ears and shout LALALALALALALA and hope it goes away?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Announcing a new extension - SideBarMenu,

[Kim Eik]

Do you have a wiki where my extension is used? Would be interesting too see
it in action in a production environment.

-Kim

On Sat, Mar 10, 2012 at 6:49 PM, Alex Brollo  wrote:

> Thank you, we did, but we wrapped the needed  jQuery code into a gadget, so
> that users can set it as a personal preference. Our gadgets are growinig
> and growing in number and performance! :-)
>
> Alex
> ___
> 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

[MediaWiki-CodeReview] [MediaWiki r107073]: New comment added

[MediaWiki Mail]

"Nemo bis" posted a comment on MediaWiki.r107073.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/107073#c32062

Commit summary for MediaWiki.r107073:

(bug 12262) Follow-up r102026: update ul margin in shared.css

Nemo bis's comment:

This should at least be included in the release notes.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113563]: New comment added

[MediaWiki Mail]

"Jeroen De Dauw" posted a comment on MediaWiki.r113563.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113563#c32063

Commit summary for MediaWiki.r113563:

ignore git

Jeroen De Dauw's comment:

Tried doing that, did not work. Just ditched svn for this extension till either 
the git migration is done or I'm finished w/ my tinkering :)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Git, Gerrit and the coming migration

[Marcin Cieslak]

I am a seasoned developer. I only do it in my spare time and only 
when I am particularly annoyed about something not working in MediaWiki
(mostly as a feedback from plwiki community or recently checkusers).

You can see my pitiful track record here:

https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/saper 

Most of those things are urgent one-liners that got to be pushed
to deployment very quickly and I never had any problem with getting
it through the process. But I'm a small guy. So please do not
treat my remarks below as something that would make life of people
pushing hundreds of lines per week to MediaWiki more difficult.

I only don't like (as it happends with git to me recently) to
learn the tool once again from scratch just because I haven't used
it for the last 4 weeks or so.

>> Antoine Musso  wrote:
> Diederik van Liere wrote:
>>  We are making three fundamental changes in one-shot:
>
> They are not that much of change. It is like if you changed from using a
> paper map and an old car to a nice SUV with a GPS. It is still a lot of
> metal on 4 wheels with one purpose: move some fresh meat from A to B.
>
> The model is the same. Only the tool changes.
> (you can quote me on this when we finally take the decision to migrate
> to JavaScript or Python)
>
>
>> 1) Migrating from a centralized source control system to a
>> decentralized system (SVN -> Git)
>
> Decentralization itself is just a buzz word for the twitter guys. In the
> end, it does not change that much since most people have a reference
> repository.  I guess most developers will use the WMF repository as a
> reference, or at the very least, all patches will eventually end up in
> the WMF repository.
>
> We could imagine having the WMF feature team to use their own repository
> then submit a nice giant patch once in a while.

I am using mercurial, git and starting to learn fossil. There is one 
change which is partially related to  tools, partally to the distributed
nature of git.

The fundamental change is something else to me: you lose feeling
of linearity. I like hg because it still tries to give me a cosy nice
local version numbers (great to switch from SVN, you can even have
your old SVN commit numbers to stay after migration). But when
I look at the gerrit interface (not gerrit's fault) I have
no idea what was done before, what was done after, what's the history.

What happend to me on a very first day trying gerrit:

I got an email to merge a change (since somebody pushed something
conflicing in between), so I duly issued some magic git commands
and I got it pushed. However, when I came back to gerrit
I ended up with an "empty" commit:

https://gerrit.wikimedia.org/r/#change,2916

I thought I did merge though! What happened? Looks an empty commit
got filed...

I tried poking around in gerrit to find out what happened I 
had no clue, only running "git log" locally revealed that
may change was indeed merged by somebody else in the background. 

I had a feeling I have 4 or more revisions flying around ("commits")
and I could not relate them to each other. Only "git log"
locally helped me to get out of the trouble.

Looking at this screen:

https://gerrit.wikimedia.org/r/#dashboard,103

Those two commits are related, but it's totally non-obvious that
something follows up on something else. I have clicked on them
and yes, I can find that 87f491132487313144e531354578ea2fbd3b42b4
is common to both of them. Oh, cool!

In comparison to this, the current Special:Code follow up revision
system is easy, readable and very useful.

Oh, and by the way those I3577f029 and Ifb002160 are some
identifiers totally unrelated to commits (I need to learn more about
Change-Id vs. a commit... I promise I will - already got burned
by missing pre-commit hook in the repo). And there is only
date, not a timestamp to get some sense of linearity again.

I am really afraid I will be lost when my dashboard will have
many more patches and merges. 

Looking at this or any more complex git development tree makes my
cry for linear revision numbers. At least I can find out what
was before, what is after - sure it comes at a cost of potentially
more difficult merging and branching, but let's be serious,
how many "edit conflicts" do we have in the tree? 

I don't think that our development timeline is more complex than this:

http://fossil-scm.org/index.html/timeline?n=200

and this is so much more readable (and yes, I know gitk).

I read in this thread that there could be a tree-like priority system
to sort out more impactful changes from more specific ones.
Building such a tree can be very challenging and as far as I understand
we don't have a tool yet. We end up with a bunch of loose commits,
somehow connected to each other, not linearized. 

And from experience, trivial and small patches get through
to deployment very fast. It's larger things that have to wait
longer...

I presume this is less of a problem with the current use in 
operations where change

Re: [Wikitech-l] Git, Gerrit and the coming migration

[Platonides]

On 09/03/12 01:07, Ryan Lane wrote:
> The change's initial view tells you which files have comments, and how
> many comments are listed inside a file.
> 
> - Ryan

Do you have an easy-to-remember revision with inline comments?


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

Re: [Wikitech-l] HTTPS preference?

[Platonides]

On 10/03/12 19:58, MZMcBride wrote:
> Hi.
> 
> https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 is about adding a user
> preference for HTTP vs. HTTPS while a user is logged in.
> 
> I'd really like to see this bug resolved, as I regularly encounter HTTP
> links and the lack of auto-redirection is becoming a larger and larger
> usability problem for me. (I don't use HTTPS-Everywhere on my personal
> computer.)
> 
> I have a few questions for this list:
> 
> * Does a user preference make sense here? I argued on that bug that adding
> an intermediate user preference seems a bit silly (letting the user shoot
> themselves in the foot), but it's apparently common to give the user a
> choice (Gmail, Twitter, Facebook, etc. all allow a choice).

It doesn't make much sense to implement HTTPS as a (normal) user
preference. If you go to http and you are logged in (so that your
preferences can be honored), your session is not much safer by having an
immediate redirect to HTTPS, I'd consider it a placebo more than an
impprovement*.
OTOH, it could be implemented with a cookie meaning "redirect me to
https" (and nothing else). This would make both http:// and https://,
show the logged in interface, having just secure cookies.
We could also use Strict Transport Security, but that's harder to set
for all our domains (I think it'd have to be set from the root one), and
it's harder to reset if we have to go back. Still, it's something to
enable on the future.


* It'd be _slightly_ safer, mostly with read-only enemies and
short-lived sessions; but not anywhere near what expect from a "https
login".


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

Re: [Wikitech-l] HTTPS preference?

[MZMcBride]

Daniel Friesen wrote:
> I believe the idea of a HTTPS preference was WONTFIXed under the premise
> that the final goal is to have all logged in users unconditionally using
> https.

https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 looks open to me. Do
you have a link to the bug you're referring to?

Krenair wrote:
> I like this idea, but I think that it should be done as a global preference
> (https://bugzilla.wikimedia.org/show_bug.cgi?id=14950).

Well, sure, but perfect is the enemy of the done. For right now, it can at
least be added as a local user preference (or just be implemented
unconditionally)... I think. That's why I started the thread: to clarify
what needs to be done and who's ready for what. :-)

MZMcBride



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

Re: [Wikitech-l] HTTPS preference?

[John Vandenberg]

On Sun, Mar 11, 2012 at 5:58 AM, MZMcBride  wrote:
> Hi.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 is about adding a user
> preference for HTTP vs. HTTPS while a user is logged in.
>
> I'd really like to see this bug resolved, as I regularly encounter HTTP
> links and the lack of auto-redirection is becoming a larger and larger
> usability problem for me. (I don't use HTTPS-Everywhere on my personal
> computer.)

Why isnt HTTPS Everywhere a good solution for you?

-- 
John Vandenberg

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

Re: [Wikitech-l] HTTPS preference?

[MZMcBride]

John Vandenberg wrote:
> On Sun, Mar 11, 2012 at 5:58 AM, MZMcBride  wrote:
>> Hi.
>> 
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 is about adding a user
>> preference for HTTP vs. HTTPS while a user is logged in.
>> 
>> I'd really like to see this bug resolved, as I regularly encounter HTTP
>> links and the lack of auto-redirection is becoming a larger and larger
>> usability problem for me. (I don't use HTTPS-Everywhere on my personal
>> computer.)
> 
> Why isnt HTTPS Everywhere a good solution for you?

I've been using Google Chrome lately. :-(

But it looks like HTTPS Everywhere now finally supports Chrome:
, so I suppose I can resolve this for
myself.

Still, it'd be nice if it were done for everyone. When users customize their
own browsers like this, it actually slows down widespread adoption of a "new
feature" like HTTPS. That is, if HTTPS Everywhere didn't exist at all, the
large number of techy Firefox users getting annoyed by hitting http links
would be more helpful in getting auto-redirection working.

Anyway, off I go to install that extension.

MZMcBride



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

Re: [Wikitech-l] HTTPS preference?

[MZMcBride]

MZMcBride wrote:
> Anyway, off I go to install that extension.

... and the extension installs without even needing a browser restart. This
is why Chrome is so fucking irresistible.

MZMcBride



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

[MediaWiki-CodeReview] [MediaWiki r111647]: New comment added

[MediaWiki Mail]

"SPQRobin" posted a comment on MediaWiki.r111647.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111647#c32064

Commit summary for MediaWiki.r111647:

(Bug 31417) Content-holding div needs an ID.
Since the introduction of the class mw-content-ltr/rtl, it has been used to get 
the page text which is very bad because there are two class names and it is not 
always on the same place (if at all). This ID will always hold the bodytext 
(excluding categories, ArticleFeedback, ...).

SPQRobin's comment:

I'm tagging this with 1.19wmf1 so if possible/allowed it will be deployed to 
WMF wikis.

Btw, I made the page [[Manual:Interface/IDs and classes]] which hopefully 
clears up usage of a few common IDs/classes (it's still a rather short list). 
Maybe it could become as helpful as [[Manual:Interface/JavaScript]] :)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] HTTPS preference?

[Ryan Lane]

> Well, sure, but perfect is the enemy of the done. For right now, it can at
> least be added as a local user preference (or just be implemented
> unconditionally)... I think. That's why I started the thread: to clarify
> what needs to be done and who's ready for what. :-)
>

Please let's not add a silly preference like this. Let's just keep
operating under the idea that all logged in users will use HTTPS, and
keep moving towards that goal.

As for the "will the servers handle it" question: yes, I'm sure
they'll handle it fine:

http://ganglia.wikimedia.org/latest/?r=hour&cs=&ce=&m=&s=by+name&c=SSL%2520cluster%2520eqiad&tab=m&vn=

http://ganglia.wikimedia.org/latest/?r=hour&cs=&ce=&m=&s=by+name&c=SSL%2520cluster%2520esams&tab=m&vn=

http://ganglia.wikimedia.org/latest/?r=hour&cs=&ce=&m=&s=by+name&c=SSL%2520cluster%2520pmtpa&tab=m&vn=

We have 12 servers for this, and they are so very bored right now. We
have the ability to add load to them by moving wikis over gradually as
well, so we'll see if we need to add more capacity.

- Ryan

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

Re: [Wikitech-l] Git, Gerrit and the coming migration

[Ryan Lane]

On Sat, Mar 10, 2012 at 1:58 PM, Platonides  wrote:
> On 09/03/12 01:07, Ryan Lane wrote:
>> The change's initial view tells you which files have comments, and how
>> many comments are listed inside a file.
>>
>> - Ryan
>
> Do you have an easy-to-remember revision with inline comments?
>

https://gerrit.wikimedia.org/r/#change,2157

See patchsets 1 and 2.

- Ryan

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

Re: [Wikitech-l] HTTPS preference?

[MZMcBride]

Ryan Lane wrote:
>> Well, sure, but perfect is the enemy of the done. For right now, it can at
>> least be added as a local user preference (or just be implemented
>> unconditionally)... I think. That's why I started the thread: to clarify
>> what needs to be done and who's ready for what. :-)
> 
> Please let's not add a silly preference like this. Let's just keep
> operating under the idea that all logged in users will use HTTPS, and
> keep moving towards that goal.

Okay, I don't disagree. Do you think
https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 should have a different
bug summary (current summary is "User preference for HTTP vs HTTPS while
logged in") or should the bug simply be resolved "wontfix" and a separate
bug filed?
 
> As for the "will the servers handle it" question: yes, I'm sure
> they'll handle it fine:
> 
> [...]
>  
> We have 12 servers for this, and they are so very bored right now. We
> have the ability to add load to them by moving wikis over gradually as
> well, so we'll see if we need to add more capacity.

Thanks for the info!

MZMcBride



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

Re: [Wikitech-l] HTTPS preference?

[Ryan Lane]

>> Please let's not add a silly preference like this. Let's just keep
>> operating under the idea that all logged in users will use HTTPS, and
>> keep moving towards that goal.
>
> Okay, I don't disagree. Do you think
> https://bugzilla.wikimedia.org/show_bug.cgi?id=29898 should have a different
> bug summary (current summary is "User preference for HTTP vs HTTPS while
> logged in") or should the bug simply be resolved "wontfix" and a separate
> bug filed?
>

I have no preference either way, whatever you guys want to do.

- Ryan

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

[Wikitech-l] CentralAuth wiki table name prefixes?

[Krenair]

I've been trying to set up CentralAuth on a localhost test wiki, but I can't 
work out how to specify a wiki's database table name prefix.
My DB name is 'mediawiki_test3' and the table name prefix is 'mw'.
It was suggested to change the DB name to suffix a hyphen with the table name 
prefix, but it still goes looking for the same thing. ('mediawiki_test3.user')
I would've expected it to look for 'mediawiki_test3.mwuser' (what I want to 
happen) or 'mediawiki_test3-mw.user' (not interpreting mw as the table prefix), 
but it just seems to ignore what I added completely.

Anyone know how to do this?
Krenair

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

Re: [Wikitech-l] gsoc proposal idea -enhancing CentralNotice Extension

[nischay nahata]

Surely will remind you after 19th.
Bon Voyage

On Sat, Mar 10, 2012 at 1:15 AM, Ryan Kaldari wrote:

> Hello Nischay,
> I'm on vacation for the next week, but please remind me to follow up on
> this after I get back on the 19th. At first glance these sound like good
> ideas, and I would probably be available to mentor on their development.
>

-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r113518]: New comment added

[MediaWiki Mail]

"Krinkle" posted a comment on MediaWiki.r113518.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113518#c32065

Commit summary for MediaWiki.r113518:

No need to create a new Revision object if we already have one available

Krinkle's comment:

No, I was looking at the code as of this rev (that rev was before this one).


if ( $oldid === $this->mPage->getLatest() ) {
$this->mRevision = $this->mPage->getRevision();
} else {
$this->mRevision = Revision::newFromId( $oldid 
);   

I don't know the context here, but if it's possible that mRevision is already 
defined, it could use an additional  if ( $this->mRevision && 
$this->mRevision->getId() !== $oldid ) { $this->mRevision = 
Revision::newFromId( $oldid ); } wrap.

If not, then it's perfectly fine.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] We need to use git-review - need help packaging for Win/Mac (Gerrit)

[Sumana Harihareswara]

I am now the project manager for MediaWiki's switch to Git and Gerrit.
I'm working to ensure that we hit the March 21st migration date.  I am
prioritizing issues and finding workarounds.

I believe the lack of arbitrary labels/tags on changes is a big workflow
problem.[0]  The current workaround is to use "topic branches" (Gerrit
calls them topics; Git calls them branches).  To do that, you have to
use git-review.  So if you have tried and failed to install and use
git-review, please speak up ASAP so we can make our git-review
instructions and workflow more robust.

And can any of you help make native packages for git-review that work on
Mac and Windows?[1]

Thanks.

[0]
https://labsconsole.wikimedia.org/wiki/Gerrit_bugs_that_matter#Issue_287:_Arbitrary_labels.2Ftags_on_changes
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=35145

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Who can make Gerrit/Labsconsole accounts?

[Sumana Harihareswara]

I originally wrote:
> * Right now, everyone listed at
> https://meta.wikimedia.org/wiki/System_administrators as having shell
> access can make a Gerrit/Labsconsole account, and should say yes to
> everyone who asks, except for known malicious persons.  There is no
> other publicly available list that's better, so this is the list of
> people newbies can ping to ask for accounts.

I've updated
https://labsconsole.wikimedia.org/wiki/Help:Access#Access_FAQ  with the
new list of names, but everything else in my summary is still accurate.

> * Instead of relying on pinging individuals, it would be nice if there
> were a queue/requests page, but there is none right now.

Still true.  I will make one next week.

> * We have to decide whether to just create Gerrit accounts for all
> existing SVN committers.  Chad has the committer USERINFO necessary to
> create Gerrit accounts for nearly all our SVN committers, but not all.

I've decided that we shall just create Gerrit accounts for all the SVN
committers who already have email addresses listed in their Subversion
USERINFO.  Ryan can script that for me and will do that next week.  Then
we'll mention that on wikitech-l and via other communications channels,
and they can go to
https://labsconsole.wikimedia.org/wiki/Special:PasswordReset to get a
password and login.  Even if it's only half of the committers, that's
still 200 accounts we don't have to create.

> * Chad and Ryan are interested in improving the signup process so that
> anyone can register for an account without having to ask a gatekeeper,
> but there's no timeline for this.

This is still true.

> * After the switch, if anyone submits a patch in Bugzilla, we should
> encourage them to get a Gerrit account and just push there in the future.

This is still our plan.  Also: There's no autolinking from Gerrit to
Bugzilla yet, but we'll work on it (bug 35144).  For now, when referring
to a Git diff, please paste changeset "Change ID"s, or the changeset
number in the Gerrit changeset URL, into the BZ comment. Both are
globally unique.

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

[MediaWiki-CodeReview] [MediaWiki r113568]: New comment added

[MediaWiki Mail]

"Dantman" posted a comment on MediaWiki.r113568.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113568#c32066

Commit summary for MediaWiki.r113568:

Remove the explicit user lang/dir attributes, because variant names are usually 
not in the user language, and there are lang attributes on those li items.

Dantman's comment:

To be clear, userlangattributes doesn't actually do anything anymore. We put 
the lang on the  now. So while not explicit those variant links ''still'' 
are set to the user lang.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113024]: Revision status changed

[MediaWiki Mail]

"Aaron Schulz" changed the status of MediaWiki.r113024 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113024

Old status:  new
New status: ok

Commit summary for MediaWiki.r113024:

Transitional patch for bug 34832: introduce a CI-style option to allow 
deployment of 1.19 to converter wikis without disruption. The bug fix can be 
rolled out later by setting $wgBug34832TransitionalRollback = false. This is 
meant as a temporary measure, while we figure out a way to properly support 
Chinese wikis for inclusion in the 1.19 tarball.

Introduce a global variable which causes language conversion to not be disabled 
in interface messages (as before r94279). Use $wgContLang for conversion (as 
before r97849) since $wgContLang is set to the base language (e.g. zh) on 
converter wikis, whereas a typical user language (e.g. zh-tw) only has a 
FakeConverter.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113568]: New comment added

[MediaWiki Mail]

"SPQRobin" posted a comment on MediaWiki.r113568.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113568#c32067

Commit summary for MediaWiki.r113568:

Remove the explicit user lang/dir attributes, because variant names are usually 
not in the user language, and there are lang attributes on those li items.

SPQRobin's comment:

I know, but on other places they don't harm. Here they're completely redundant. 
(But the variant links have got their own lang attributes since r112442.)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113567]: Revision status changed

[MediaWiki Mail]

"SPQRobin" changed the status of MediaWiki.r113567 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113567

Old status:  new
New status: ok

Commit summary for MediaWiki.r113567:

Localisation updates for core and extension messages from translatewiki.net

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r113536]: New comment added, and revision status changed

[MediaWiki Mail]

"Aaron Schulz" changed the status of MediaWiki.r113536 to "ok" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113536#c32068

Old Status: new
New Status: ok

Commit summary for MediaWiki.r113536:

Followup r45, typo fix

Aaron Schulz's comment:

Somebody want's to break apache?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] HTTPS preference?

[K. Peachey]

On Sun, Mar 11, 2012 at 8:41 AM, MZMcBride  wrote:
> I've been using Google Chrome lately. :-(
>
> But it looks like HTTPS Everywhere now finally supports Chrome:
> , so I suppose I can resolve this for
> myself.


:o Finally! (Although it's still in beta) *installs*

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

Re: [Wikitech-l] MediaWiki and Python

[Daniel Mietchen]

Looks promising to me for things like lab notebooks.

Daniel


On Sat, Mar 10, 2012 at 8:54 PM, Steven Walling
 wrote:
> Sandboxed Python + MediaWiki = PyPedia.
>
> PDF: http://dl.dropbox.com/u/5548517/PyPedia.pdf
>
> Seems interesting. Thoughts?
>
> Steven
> ___
> 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] We need to use git-review - need help packaging for Win/Mac (Gerrit)

[Roan Kattouw]

On Sat, Mar 10, 2012 at 7:20 PM, Sumana Harihareswara
 wrote:
> I believe the lack of arbitrary labels/tags on changes is a big workflow
> problem.[0]  The current workaround is to use "topic branches" (Gerrit
> calls them topics; Git calls them branches).  To do that, you have to
> use git-review.
That's not entirely true. git-review just contains some code to guess
an appropriate topic (bug number in commit summary if available, local
branch name otherwise) and then uses a regular git command to submit
the change with a topic. The command is:

git push gerrit HEAD:refs/for/master

to push something without a topic, and

git push gerrit HEAD:refs/for/master/foobar

to push something with 'foobar' as the topic. git-review is really
just sugar coating around these hideous 'git push' commands.

Roan

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