On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena <benapetr(a)gmail.com> wrote:
> Good job, you aren't the only one. Huggle team is using it for quite
> some time. To be honest I still feel that github is far superior to
> our gerrit installation and don't really understand why we don't use
> it for other projects too.
>
GitHub is focused on small projects; for a project with lots of patches and
committers it is problematic in many ways:
* poor repository management (fun fact: GitHub does not even log force
pushes, much less provides any ability to undo them)
* noisy commit histories due to poor support of amend-based workflows, and
also because poor message generation of the editing interface (Linus wrote
a famous rant
<https://github.com/torvalds/linux/pull/17#issuecomment-5654674> on that)
* no way to mark patches which depend on each other
* diff view works poorly for large patches
* CR interface works poorly for large patches (no way to write draft
comments so you need to do two passes; discussions can be marked as
obsolete by unrelated code changes in their vicinity)
* hard to keep track of cherry-picks
Due to labs outage, the Android alpha build has not been run since
Wednesday.
If you want to grab the latest and greatest newly merged alpha apk then you
can do so from Gerrit > Jenkins. Since the apk built there do use the same
signing certificate yet, you would have to uninstall the old alpha apk.
Here is a direct link to the alpha apk that's merged right now:
wikipedia-alpha-debug.apk
<https://integration.wikimedia.org/ci/job/apps-android-wikipedia-gradlew/409…>
If you want the very latest you can follow these steps instead:
1. Pick the latest (top result) from Gerrit:
https://gerrit.wikimedia.org/r/#/q/status:merged+project:apps/android/wikip…
2. From the patch details, e.g. https://gerrit.wikimedia.org/r/#/c/219295/,
scroll all the way down to the bottom to the last link that says
"apps-android-wikipedia-gradlew". Follow that link.
3. On the Jenkins page that shows the Console output Click on the Status
link.
4. On the build status page download the file linked as
wikipedia-alpha-debug.apk.
Sorry for the inconvenience. I plan to respond to this thread when the
regular alpha builds are working again.
Bernd
On Wed, Jul 22, 2015 at 2:48 PM, Ryan Lane <rlane32(a)gmail.com> wrote:
> Some of the largest open source projects around are on github:
>
> https://github.com/saltstack/salt/pulse/monthly
>
> https://github.com/docker/docker/pulse/monthly
Which does not necessarily mean it does not suck for them. Some large
projects are still on Sourceforge. Some large projects still use SVN. etc.
Change is hard.
> * poor repository management (fun fact: GitHub does not even log force
> pushes, much less provides any ability to undo them)
You can have force push to master disabled. Also their fork model (which I
> dislike for other reasons) means you can limit access to the main fork to a
> small set of people and require all pull requests to come from branches of
> forks. It's the default model for basically every public github project.
>
So force pushes can only obliterate feature branches, version branches and
whatnot.
(GitHub actually developed sane management of force pushes but only
included into their enterprise version. I guess that does not quite qualify
as doing evil things but still is unpleasant.)
> * noisy commit histories due to poor support of amend-based workflows, and
> > also because poor message generation of the editing interface (Linus
> wrote
> > a famous rant
> > <https://github.com/torvalds/linux/pull/17#issuecomment-5654674> on
> that)
>
> You can manage that yourself through rebasing of PRs. That's completely
> based on your workflow and what you require of contributors (or how you do
> your merges).
GitHub's PR interface sucks with a rebase-heavy workflow. There is no
indication that a commit is a rebased version of a former commit; former
commits disappear without trace; inline comments to former commits become
unintelligible. And you need force push to do it which has potentially
disastrous effects on GitHub.
> > * no way to mark patches which depend on each other
>
> Sure you can. All PRs are also issues and can be referenced by issue
> number. If you mention the issue in a comment it adds a reference for you.
Which will not stop the CI infrastructure from testing your patch without
pulling in its dependencies, not will it stop a careless reviewer from
merging it without the dependencies.
> > * diff view works poorly for large patches
>
> It's way better than gerrit. May not be better than phabricator, though.
Here is a patch I made a few days ago:
https://gerrit.wikimedia.org/r/#/c/225827/
Here is the same patch in GitHub:
https://github.com/wikimedia/operations-software-sentry/commit/ae8bc0fe9ada…
(Warning: might crash your browser.)
> * CR interface works poorly for large patches (no way to write draft
> > comments so you need to do two passes; discussions can be marked as
> > obsolete by unrelated code changes in their vicinity)
>
> You can delete and edit your comments. Draft comments in gerrit are an
> anti-pattern IMO.
>
Deleting or reworking comments after email notifications have already been
sent out with them is much more of an antipattern.
Anyway, I did not intend to start a GitHub-vs-Gerrit deathmatch, nor to
criticize the iOS team's decision (at their team size GitHub makes perfect
sense IMO), just answer Petr's question about why don't we all just move to
GitHub.
Historically developers have had to setup their own content in mediawiki
and in mediawiki-vagrant. While this can be done with a simple import,
getting everyone on the same page is apparently not as easy. This is
generally problematic as we would like to test code locally and remotely
with the same content for various reasons.
Slightly more frustrating, there are pages titled "0.4425590476103759" on
beta labs. While trying to sign off on a feature, there is usually a
struggle when trying to find an article with suitable content. AFAIK this
won't change beta labs but would provide a nice standard for our content on
test wikis.
We aim to better things by creating a vagrant role for importing a set of
articles for testing purposes. For more information please see related
phabricator tasks [1] and [2].
In hopes of making this a nice collection of articles that multiple teams
would use, we would like to get input from our designers and devs on what
types of articles should be in this import. What qualities should these
articles contain?
1: https://phabricator.wikimedia.org/T104561
2: https://phabricator.wikimedia.org/T62116
--
Rob Moen
Wikimedia Foundation
rmoen(a)wikimedia.org
+mobile-l
Corey: Using existing infra for 4.1.7 is fine. Just to be clear, I think we
should do this as simply (even manually) as possible to avoid expanding
scope of this to include automating it just yet.
Given that we don't (currently) plan on doing another 4.y.z release after
4.1.7 and before 5.0, I suggest that we get translations hooked up to 5.0
immediately after 4.1.7. This follows the same rationale behind syncing
master & 5.0 branches after 4.1.7 and will prevent future translations from
targeting obsolete strings or being hard to port over.
On Wed, Jul 22, 2015 at 10:41 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
> Okay to move this discussion to mobile-l now?
>
> On Wednesday, July 22, 2015, Corey Floyd <cfloyd(a)wikimedia.org> wrote:
>
>> Since the existing infrastructure is still working for 4.1.7 and we
>> already have the patches ready to go, we should just get it merged.
>>
>> Agree that we need to get to this, but I think it would be less
>> disruptive to deal with this as part of 5.0, rather than add development
>> time to a legacy bug fix release. 5.0 will have new language keys and
>> (likely) a new directory structure anyways.
>>
>> Let plan on discussing translation impacts on 5.0 after we get moved to
>> Github. That we we have our new CI setup in place before making any Phab
>> tasks.
>>
>>
>>
>> On Wed, Jul 22, 2015 at 6:20 AM, Brian Gerstle <bgerstle(a)wikimedia.org>
>> wrote:
>>
>>> Correct, the ticket for the transfer
>>> <https://phabricator.wikimedia.org/T105056> has been filed. My
>>> (potentially naive) assumption is that, based on the docs, we can at least
>>> use the current "export" step to apply localization updates locally, then
>>> push a commit or pull request manually (at least for now).
>>> Assuming this is feasible, we should be able to take ownership of TWN
>>> sync independent of when we switch to GH.
>>>
>>> Corey, what do you think of TWN ownership (and sync) as part of
>>> releasing 4.1.7? We've been kicking this can down the road for a while, so
>>> I like the idea of making the next TWN sync one we run ourselves.
>>>
>>> As far as when the switch will happen, I still need to work that out
>>> with Corey to make sure we've thought through (and hopefully avoided) any
>>> potential negative impact on our ability to deliver 5.0 in Q1. My rough
>>> estimate is that moving to GH and hooking up Travis should only be a couple
>>> days work, just need to talk through it & prioritize the tasks in the
>>> backlog.
>>>
>>> On Wed, Jul 22, 2015 at 2:11 AM, Bernd Sitzmann <bernd(a)wikimedia.org>
>>> wrote:
>>>
>>>> That would be fine with me. As long as the TWN guys don't have a
>>>> problem with that to have multiple points of contact that would work nicely.
>>>>
>>>> When is the Github move going to happen?
>>>>
>>>> Bernd
>>>>
>>>> On Tue, Jul 21, 2015 at 7:20 PM, Corey Floyd <cfloyd(a)wikimedia.org>
>>>> wrote:
>>>>
>>>>> I think Bran wants us to take ownership for the iOS translations
>>>>> anyways. Since we are moving to github, this may be a good time to handoff.
>>>>>
>>>>> @Brian what are you thinking here? Too soon to think about until we
>>>>> get closer on 5.0 or do you want to start making some plans?
>>>>>
>>>>> On Tue, Jul 21, 2015 at 7:21 PM, Bernd Sitzmann <bernd(a)wikimedia.org>
>>>>> wrote:
>>>>>
>>>>>> Brian,
>>>>>>
>>>>>> I was just was thinking about TWN syncs and remembered your comment
>>>>>> that iOS is moving to Github soon. When you do let me and Stephen know
>>>>>> since Stephen is going to take over TWN sync in the future.
>>>>>>
>>>>>> The current TWN sync process[1] is based on Gerrit but I think
>>>>>> Nikerabbit said they would be able to handle Github as well[2]. Still it
>>>>>> does mean some change for TWN sync on our side. We would need to inquire
>>>>>> with the TWN folks (Nikerabbit and Siebrand) how this should be done with
>>>>>> Github (the setup needs some changes, at least a new Git remote, and the
>>>>>> repocommit command needs to change or be replaced by an alternate
>>>>>> command as well).
>>>>>>
>>>>>> Bernd
>>>>>>
>>>>>> [1]
>>>>>> https://www.mediawiki.org/wiki/Translation_of_app_string_resources
>>>>>> [2] https://phabricator.wikimedia.org/T96707
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Corey Floyd
>>>>> Software Engineer
>>>>> Mobile Apps / iOS
>>>>> Wikimedia Foundation
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
>>> IRC: bgerstle
>>>
>>
>>
>>
>> --
>> Corey Floyd
>> Software Engineer
>> Mobile Apps / iOS
>> Wikimedia Foundation
>>
>
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
sorry, didn't hit reply-all. (these lists aren't a subset of each other,
are they?)
Also, we're losing IRC notifications, but that should be easy enough to add
back via fastlane.
---------- Forwarded message ----------
From: Brian Gerstle <bgerstle(a)wikimedia.org>
Date: Wed, Jul 22, 2015 at 12:59 PM
Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
I have no problem with that, as long as everyone with +2 keeps his access
This should already be the case for the main iOS engineers, but I've made a
ticket <https://phabricator.wikimedia.org/T106547> to make sure people
don't slip through the cracks.
Oh, and when
> it syncs with phabricator tickets....
>
Phabricator ticket sync is something we're sad to lose, but it's part of
the trade-off we're making. That said, it was only slightly beneficial as
we relied more on cards being in a "Code Review" column (w/ a WIP limit)
than looking at the gerrit updates on the cards themselves (which aren't
visible from the board view). Not that GH will make this any easier, but
we're not losing too much here, IMHO.
On Wed, Jul 22, 2015 at 8:01 AM, Derk-Jan Hartman <
d.j.hartman+wmf_ml(a)gmail.com> wrote:
> I have no problem with that, as long as everyone with +2 keeps his access
> and someone manages developer account additions and removals. Oh, and when
> it syncs with phabricator tickets....
>
> DJ
>
> On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena <benapetr(a)gmail.com> wrote:
>
> > Good job, you aren't the only one. Huggle team is using it for quite
> > some time. To be honest I still feel that github is far superior to
> > our gerrit installation and don't really understand why we don't use
> > it for other projects too.
> >
> > The GitHub's pull requests are more compliant with original git
> > philosophy of Linus, see this video:
> > https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient
> > replacement to our current "git-review" mechanism, which is very
> > complex and unfriendly to new developers who probably find it very
> > difficult to use.
> >
> > On Wed, Jul 22, 2015 at 12:40 PM, Brian Gerstle <bgerstle(a)wikimedia.org>
> > wrote:
> > > Hey everyone,
> > >
> > > I'm writing with plans for the Wikimedia iOS engineering team to move
> its
> > > workflow to GitHub with Travis CI, much like RESTbase.
> > >
> > > The Wikimedia iOS engineers have been maintaining their own CI and
> build
> > > server and using Gerrit for code review. The more time efficient and
> > > commonplace approach for open source iOS software development leans
> > heavily
> > > on GitHub with Travis CI instead (e.g., WordPress[0][1] and
> > Firefox[2][3]).
> > > By using GitHub with Travis CI, the team believes it will work faster,
> > > improve testing, grow developer confidence in making code changes, and,
> > > most importantly, deploy fewer bugs to production.
> > >
> > > For builds requiring sensitive information (e.g., prod certs), will
> > > continue to run on WMF's Mac Mini. As is done for Android, when betas
> are
> > > pushed, the team will notify mobile-l.
> > >
> > > Feel free to reply or email me directly with any questions or comments.
> > >
> > > Regards,
> > >
> > > Brian
> > >
> > > 0: https://github.com/wordpress-mobile/WordPress-iOS
> > > 1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
> > > 2: https://github.com/mozilla/firefox-ios
> > > 3: https://travis-ci.org/mozilla/firefox-ios
> > >
> > > --
> > > EN Wikipedia user page:
> https://en.wikipedia.org/wiki/User:Brian.gerstle
> > > IRC: bgerstle
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l(a)lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
Hi all - just wanted to let you know about
https://phabricator.wikimedia.org/tag/reading-admin/ if you didn't know
about it already. This is a place the Reading management team adds and
tracks more manager oriented tasks.
As items get moved to Done, we will in the future probably actually want to
check into whether they should be moved farther left in the board to be
repeated / re-reviewed or figure out some appropriate lightweight workflow
for such things.
-Adam
Hi all -
I've been reviewing a list of extensions with Reading Engineering and
Reading Infrastructure leads - props to James Forrester for promoting this
discussion. Here's a list of extensions we believe currently falls under
Reading for triage (n.b., not all extensions will get active development
support).
https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
Presuming no major issues with this, I think we should move the page to
mw:Reading/Extension_Responsibility.
One important outstanding question:
Is MultimediaViewer appropriate for Reading given its consumption-oriented
nature? Or is this actually better suited to Editing (where there exists a
team named Multimedia)?
Some other notes:
* For skins with low utilization, we in time probably should coordinate
handover to interested community members (or discuss with community members
practical approaches for EOL).
* Regarding the Nostalgia skin, we believe it's only used on
https://nostalgia.wikipedia.org/wiki/HomePage, so maintenance would be
updating for breaking skin changes or security issues only.
* JsonConfig, ZeroBanner, ZeroPortal - we'll need to examine this more
closely. Yuri (who has deepest PHP knowledge on extensions) is now over in
Discovery, Jeff (JS & Lua) is in Reading, and now I'm managing instead of
writing lots of code.
* Collection probably belongs in Services