On 03/10/2014 02:38 PM, Chris McMahon wrote:
On Mon, Mar 10, 2014 at 10:59 AM, Tyler Romeo wrote:
It's been repeated multiple times, but I'll say it again: it is disputed as
to whether account creation was "broken".
It is not disputed.
When you get to the end of the account creation proces
On 03/08/2014 05:10 PM, Ryan Lane wrote:
You don't work for WMF, so you personally have no responsibility for the
stability of the site. It's the WMF developers who have a responsibility to
ensure code they're pushing out won't break the site. As an aside, root
isn't necessary to maintain MediaWi
Le 10/03/2014 08:51, Martijn Hoekstra a écrit :
> If the test infrastructure can't handle running every test on every commit
> (why can't they by the way, and could that be remedied?) Would it be
> possible and desireable to make sure a more elaborate test suite with all
> available tests in run as
As a rule, in industry practice, developers don't get to redefine expected
functionality to avoid something being a bug.
Communications gaps on what expected functionality was are to some extent
unavoidable. Some bugs slip into that crack. But, if both the test and users
would have complaine
On Mon, Mar 10, 2014 at 10:59 AM, Tyler Romeo wrote:
>
> It's been repeated multiple times, but I'll say it again: it is disputed as
> to whether account creation was "broken".
It is not disputed.
When you get to the end of the account creation process and you do not have
an account, that is br
On Mon, Mar 10, 2014 at 2:01 PM, Brandon Harris wrote:
> This is a fairly limited view. The functionality was *broken*. It failed
> to work in the way it was expected to work. That’s what “broken” means.
I'm not going to bother repeating myself. I recommend re-reading this
thread for an expla
On Mar 10, 2014, at 10:59 AM, Tyler Romeo wrote:
> It's been repeated multiple times, but I'll say it again: it is disputed as
> to whether account creation was "broken". It is just a question of design
> and user experience. No functionality was actually broken.
This is a fairly limit
On Mon, Mar 10, 2014 at 11:50 AM, Chris McMahon wrote:
> The problem is not that the change broke tests. The problem is that the
> change broke account creation for Mobile view on a production wiki.
>
> Let me repeat: the change broke account creation on a production wiki.
>
It's been repeated m
On Sat, Mar 8, 2014 at 8:05 PM, Tyler Romeo wrote:
> On Sat, Mar 8, 2014 at 9:48 PM, Ryan Lane wrote:
>
>
> OK, then how did this change get deployed if it "broke" tests?
The problem is not that the change broke tests. The problem is that the
change broke account creation for Mobile view on a
On Mar 9, 2014 4:15 AM, "Ryan Lane" wrote:
>
> On Sat, Mar 8, 2014 at 7:05 PM, Tyler Romeo wrote:
>
> > On Sat, Mar 8, 2014 at 9:48 PM, Ryan Lane wrote:
> >
> > > Wikimedia uses deployment branches. Just because someone +2/merges
into
> > > master doesn't mean it immediately shows up on Wikimedi
I don't even know what the purpose of this thread is now. Seems to be
discussion about development practices, badgering and various other things.
I started two other threads to try and break out these important
conversations but looks like conversation is still happening here so I
guess that failed
On Sat, Mar 8, 2014 at 9:34 PM, MZMcBride wrote:
> Chad wrote:
> > On Mar 8, 2014 1:42 PM, "Brandon Harris" wrote:
> >>https://en.wikipedia.org/wiki/Badger
> >
> >New rule: calling badger is synonymous with asking for the moderation bit
> >for yourself.
>
> Fine, but first we have to ban the peo
Chad wrote:
> On Mar 8, 2014 1:42 PM, "Brandon Harris" wrote:
>>https://en.wikipedia.org/wiki/Badger
>
>New rule: calling badger is synonymous with asking for the moderation bit
>for yourself.
Fine, but first we have to ban the people who top-post and don't trim
unnecessary parts of their e-mails
On Sat, Mar 8, 2014 at 10:15 PM, Ryan Lane wrote:
> The jenkins report says it passed tests, hence why it was deployed. If
> there's other tests that aren't reporting to gerrit or if there's a test
> that needs to be added, maybe that's a post-mortem action to track?
>
Yep. Hence the reason I th
New rule: calling badger is synonymous with asking for the moderation bit
for yourself.
-Chad
On Mar 8, 2014 1:42 PM, "Brandon Harris" wrote:
>
>
> https://en.wikipedia.org/wiki/Badger
>
>
>
> On Mar 8, 2014, at 1:38 PM, Tyler Romeo wrote:
>
> > On Fri, Mar 7, 2014 at 7:04 PM, R
On Sat, Mar 8, 2014 at 7:05 PM, Tyler Romeo wrote:
> On Sat, Mar 8, 2014 at 9:48 PM, Ryan Lane wrote:
>
> > Wikimedia uses deployment branches. Just because someone +2/merges into
> > master doesn't mean it immediately shows up on Wikimedia servers. It
> needs
> > to go into a deployment branch,
On Sat, Mar 8, 2014 at 9:48 PM, Ryan Lane wrote:
> Wikimedia uses deployment branches. Just because someone +2/merges into
> master doesn't mean it immediately shows up on Wikimedia servers. It needs
> to go into a deployment branch, then it needs to get deployed by a person.
> Also, we use a gat
On Sat, Mar 8, 2014 at 6:21 PM, Tyler Romeo wrote:
> On Sat, Mar 8, 2014 at 8:38 PM, Marc A. Pelletier
> wrote:
>
> > The answer is: no, obviously not. And for that reason the MariaDB
> > developers are not allowed to simply push their latest code on our
> > infrastructure with a simple +2 to c
On Sat, Mar 8, 2014 at 8:38 PM, Marc A. Pelletier wrote:
> The answer is: no, obviously not. And for that reason the MariaDB
> developers are not allowed to simply push their latest code on our
> infrastructure with a simple +2 to code review.
>
Yes, and my point is that MediaWiki developers sh
On 03/08/2014 04:38 PM, Tyler Romeo wrote:
> Tell me something, what about the developers of MariaDB? Should they be
> responsible for WMF's stability? If they accidentally release a buggy
> version, are they expected to revert it within hours so that the WMF
> operations team can redeploy?
I'm go
On 03/08/2014 02:10 PM, Isarra Yos wrote:
On 08/03/14 09:15, Niklas Laxström wrote:
Please do not forget the contributors who want to improve MediaWiki
for their own needs. We also have to balance how much we inconvenience
them to meet the requirements of WMF. In my opinion, the balance is
alre
On Sat, Mar 8, 2014 at 2:06 PM, Ryan Lane wrote:
> On Sat, Mar 8, 2014 at 1:38 PM, Tyler Romeo wrote:
>
>> On Fri, Mar 7, 2014 at 7:04 PM, Ryan Lane wrote:
>>
>> > Yes! This is a _good_ thing. Developers should feel responsible for what
>> > they build. It's shouldn't be operation's job to make
On Sat, Mar 8, 2014 at 1:38 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 7:04 PM, Ryan Lane wrote:
>
> > Yes! This is a _good_ thing. Developers should feel responsible for what
> > they build. It's shouldn't be operation's job to make sure the site is
> > stable for code changes. Things shou
https://en.wikipedia.org/wiki/Badger
On Mar 8, 2014, at 1:38 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 7:04 PM, Ryan Lane wrote:
>
>> Yes! This is a _good_ thing. Developers should feel responsible for what
>> they build. It's shouldn't be operation's job to make sure
On Fri, Mar 7, 2014 at 7:04 PM, Ryan Lane wrote:
> Yes! This is a _good_ thing. Developers should feel responsible for what
> they build. It's shouldn't be operation's job to make sure the site is
> stable for code changes. Things should go more in this direction, in fact.
>
If you want to give
On 08/03/14 09:15, Niklas Laxström wrote:
2014-03-08 0:39 GMT+02:00 George Herbert :
This is not disrespecting development, which is extremely important by any
measure. But we're running a top-10 worldwide website, a key worldwide
information resource for humanity as a whole. We cannot cripple
2014-03-08 0:39 GMT+02:00 George Herbert :
> This is not disrespecting development, which is extremely important by any
> measure. But we're running a top-10 worldwide website, a key worldwide
> information resource for humanity as a whole. We cannot cripple
> development to try and maximize stab
On 08/03/14 02:48, Bartosz Dziewoński wrote:
> On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso
> wrote:
>
>> So a single -1 should prevent a change from being submitted until that
>> -1 is lifted by addressing the person concern(s) or correcting him/her
>> or whatever.
>
> Note that such a rul
Antoine Musso wrote:
>Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
>> On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso
>> wrote:
>>
>>> So a single -1 should prevent a change from being submitted until that
>>> -1 is lifted by addressing the person concern(s) or correcting him/her
>>> or wh
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 5:39 PM, George Herbert >wrote:
>
> > With all due respect; hell, yes, development comes in second to
> operational
> > stability.
> >
> > This is not disrespecting development, which is extremely important by
> any
> >
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 5:39 PM, George Herbert >wrote:
>
> > With all due respect; hell, yes, development comes in second to
> operational
> > stability.
> >
> > This is not disrespecting development, which is extremely important by
> any
> >
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo wrote:
>
> Right now you are placing the responsibility on the developers to make sure
> the site is stable, because any change they merge might break production
> since it is automatically sent out. If anything that gives the appearance
> that the opera
> On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen
> wrote:
>
> > Yes, it does. Unless the entire branch has a serious problem (500s or
> > major caching problems, etc.), we don't generally switch the entire branch
> > back.
> >
> > That means the only option is fix or revert a commit. The gen
> Sure, but immediately deploying untested changes to all users is a reckless
> method of having real users test something.
[snip]
> I think some of the things mentioned here are good solution. The biggest
> problem here is that this patch was launched almost completely untested. It
> should have
On Fri, Mar 7, 2014 at 5:39 PM, George Herbert wrote:
> With all due respect; hell, yes, development comes in second to operational
> stability.
>
> This is not disrespecting development, which is extremely important by any
> measure. But we're running a top-10 worldwide website, a key worldwide
On 7 March 2014 22:39, George Herbert wrote:
> With all due respect; hell, yes, development comes in second to operational
> stability.
> This is not disrespecting development, which is extremely important by any
> measure. But we're running a top-10 worldwide website, a key worldwide
> informat
On Fri, Mar 7, 2014 at 1:54 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen >wrote:
>
> > Yes, it does. Unless the entire branch has a serious problem (500s or
> > major caching problems, etc.), we don't generally switch the entire
> branch
> > back.
> >
> > That means
On Fri, Mar 7, 2014 at 5:29 PM, Greg Grossmeier wrote:
> Or a benefit, giving third-party users confidence that the core they use
> has a quick feedback loop with real users and is thoroughly tested.
>
> It's all about perspective.
>
> From these conversations, your perspective seems to be (and p
On 03/06/2014 05:07 PM, Chris McMahon wrote:
Beyond that, there are serious concerns with any feature that a) requires
javascript support in the client in order to create an account on the wiki
and b) does not honor the characters that the user types in the username
and password fields.
I agree
On 03/06/2014 09:58 PM, Tyler Romeo wrote:
I don't think you see the problem here. Consider this case as an example (I
agree that this is case-by-case, so let's limit the scope to this one).
You're forgetting that the original patch fixes a bug. In fact, it fixes a
pretty serious UX bug in my opi
> On 03/06/2014 08:29 PM, Jon Robson wrote:
> >For the record this the test that alerted us to this issue was the following:
> >https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/392/testReport/junit/(root)/Create%20failure%20messages/Create_account_passw
On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen wrote:
> Yes, it does. Unless the entire branch has a serious problem (500s or
> major caching problems, etc.), we don't generally switch the entire branch
> back.
>
> That means the only option is fix or revert a commit. The general rule is
> to
On 03/06/2014 08:29 PM, Jon Robson wrote:
For the record this the test that alerted us to this issue was the following:
https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/392/testReport/junit/(root)/Create%20failure%20messages/Create_account_password_mis
On 03/06/2014 10:44 PM, Tyler Romeo wrote:
On Thu, Mar 6, 2014 at 10:13 PM, George Herbert wrote:
Based on the timing description here, it seems more like "Either rush 1 or
rush 2".
This is also not true. Something does not have to be reverted in Gerrit in
order for it to be undeployed from
Note, in case you didn't see, since this thread was getting extremely
complicated to follow.. I started two threads - one about
"Merging near deployment branch cut time"
and
"Notifying people when integration tests"
On Fri, Mar 7, 2014 at 10:50 AM, Isarra Yos wrote:
> On 07/03/14 17:06, Antoine
On 07/03/14 17:06, Antoine Musso wrote:
Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso
wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or correcting him/her
or w
On Fri, Mar 7, 2014 at 12:37 PM, C. Scott Ananian wrote:
> The benefit of halting auto-merge is that (a) it automatically resumes
> once the deploy happens, so volunteers don't have to come back to gerrit to
> repeat their approval,
Unless it merge-conflicts now where it didn't 24 hours ago.
>
On 07/03/14 10:16, Steven Walling wrote:
Just for more background/context here... As you can see in the latest
comments on bug 61416, I'm not the only one who objects to the
implementation as currently designed. Prior to the bug, Erik M. also
proposed an alternative solution which was ignored for
On Fri, 07 Mar 2014 14:26:48 +0100, Bartosz Dziewoński
wrote:
While I still believe that the way this was done is the correct one
(seamless warning with JS; additional confirmation step without JS),
given the lack of consensus that is apparent now and wasn't apparent
earlier (Steven was the on
On Fri, Mar 7, 2014 at 12:21 PM, Brad Jorsch (Anomie) wrote:
> On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian >wrote:
>
> > I agree. I think a better technical solution would be to halt jenkins'
> > auto-merge for the 24 hour period, so that +2'ed changes are not
> > automatically merged unt
On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian wrote:
> I agree. I think a better technical solution would be to halt jenkins'
> auto-merge for the 24 hour period, so that +2'ed changes are not
> automatically merged until after the branch is cut.
I don't see how that's any better. Things st
On Fri, Mar 7, 2014 at 8:55 AM, Bartosz Dziewoński wrote:
> I really do not think that blocking merges into core for 15% of the
> week is going to do us any good. Core already has a problem with stale
> patches not being touched (for various reasons, but most stemming from
> the lack of reviewers)
Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
> On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso
> wrote:
>
>> So a single -1 should prevent a change from being submitted until that
>> -1 is lifted by addressing the person concern(s) or correcting him/her
>> or whatever.
>
> Note that such
> In fact, I still have no idea what exactly the tests encompass (I've
> heard about some browser tests for VE because I lurk a lot, never
> heard of any for core) or where to find them or how to run them.
> Either I'm slow or we have a serious documentation failure here.
>
> Can something be don
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or correcting him/her
or whatever.
Note that such a rule never been followed by anyone, including by various WMF
te
Le 07/03/2014 07:55, MZMcBride a écrit :
> Tim Starling wrote:
>> >I would never have merged it, because it had a -1 from Steven Walling,
>> >apparently speaking on behalf of others on design-l. I think changes
>> >should be made by consensus.
>
> The change also had five +1s, as noted in this thre
Le 07/03/2014 14:56, Bartosz Dziewoński a écrit :
> On Fri, 07 Mar 2014 00:34:40 +0100, Brion Vibber
> wrote:
>
>> For years and years and years we've been very free about reverting things
>> that break. No one, including old-timers like me and Tim, has the "right"
>> to not have something revert
Le 07/03/2014 02:29, Jon Robson a écrit :
> 2 problems here - tests run only for the extension the code touches
> and currently browser tests only run after as these are slow and
> people would be annoyed if code took 20 minutes to merge. We've had
> issues in the past where changes in VisualEditor
Filed https://bugzilla.wikimedia.org/show_bug.cgi?id=62371 .
--
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, 07 Mar 2014 00:34:40 +0100, Brion Vibber wrote:
For years and years and years we've been very free about reverting things
that break. No one, including old-timers like me and Tim, has the "right"
to not have something reverted. If it needs to be reverted it will be
reverted -- there is
(continued, about the deployment process)
I'm going to start this one with some quotes which summarize the topic
better than I would.
On Fri, 07 Mar 2014 00:30:24 +0100, Jon Robson wrote:
The code was merged at the final hour before a deployment train (this
is another issue that our deployment
(continued, about the browser testing)
(tl;dr where are the tests and how do I know they fail?)
So, we have some slick browser tests. Awesome! But what's not good is
that the tests run off-site, the results are not reported back to
gerrit nor Bugzilla (unless someone manually files a bug, usuall
Well, this has blown up quite a lot. I'm going to try to summarize and
comment on the discussion so far, from the perspective of the
"perpetrator" ;). Since we've gone off on quite a few tangents I'll
send one e-mail for each one I see.
Regarding the patch itself [1]:
(tl;dr we all messed up, le
On Fri, Mar 7, 2014 at 5:23 AM, Isarra Yos wrote:
> The changeset was the result of the discussion on the Design list. The
> reason Steven Walling gave for the -1 was simply not true, but attempts to
> explain this failed and consensus apparently wound up being to ignore him.
>
> Just for a littl
Le 7 mars 2014 à 07:44, C. Scott Ananian a écrit :
> If I had a procedures wishlist, it would be for:
>
> a) a prominent link beside gerrit's +2 where teams could write
> project-specific +2 guidelines.
>
> b) a gerrit page banner in the "24 hours before deployment" window for a
> given project
Tim Starling wrote:
>I would never have merged it, because it had a -1 from Steven Walling,
>apparently speaking on behalf of others on design-l. I think changes
>should be made by consensus.
The change also had five +1s, as noted in this thread. I find it
interesting that, to you, consensus now i
On Thu, Mar 6, 2014 at 7:08 PM, Erik Bernhardson wrote:
> Does core have any policies related to merging? The core features team
> has adopted a methodology(although slightly different) that we learned of
> from the VE team. Essentially +2 for 24 hours before a deployment branch
> is cut is li
On 07/03/14 03:58, Tim Starling wrote:
I would never have merged it, because it had a -1 from Steven Walling,
apparently speaking on behalf of others on design-l. I think changes
should be made by consensus.
The changeset was the result of the discussion on the Design list. The
reason Steven
On 07/03/14 11:38, Greg Grossmeier wrote:
> The suite of automatic tests caught this bug, actually. It's how the
> mobile team found out about it as they got to work this morning. So the
> testing is quite robust.
As I understand it, there was no bug, it was just a controversial
design change. Tha
On 07/03/14 09:07, Chris McMahon wrote:
> In over two years at WMF I have never been involved in a discussion
> like this, but here goes:
>
> In this case, I think it was entirely appropriate to revert
> immediately and pick up the pieces later. The source of the code
> is immaterial, if Tim Star
On Thu, Mar 6, 2014 at 10:13 PM, George Herbert wrote:
> Based on the timing description here, it seems more like "Either rush 1 or
> rush 2".
>
This is also not true. Something does not have to be reverted in Gerrit in
order for it to be undeployed from production. If there was any timing
issue
Tyler wrote:
> > 1. Fix the extension quickly
> > 2. Revert the change
> > 3. Undeploy the extension until its fixed to be compatible with core
> So to summarize, #3 is obviously not an option. For #2, are we supposed to
>
block core development, and let this bug persist indefinitely, becau
On Thu, Mar 6, 2014 at 9:21 PM, Jon Robson wrote:
> I wonder in future if it might be practical useful for test failures like
> this to automatically revert changes that made them or at least submit
> patches to revert them that way it's clear how and when things should
> be reverted.
>
Or,
I wonder in future if it might be practical useful for test failures like
this to automatically revert changes that made them or at least submit
patches to revert them that way it's clear how and when things should
be reverted.
On 6 Mar 2014 18:09, "Chris McMahon" wrote:
> On Thu, Mar 6, 2014
On Thu, Mar 6, 2014 at 6:07 PM, OQ wrote:
> So the testsuite only runs on merged code and not pending-merge? That
> sounds like a large oversight.
Picture in your mind every branch pending merge for every extension in
gerrit. Imagine how many of those branches are eventually abandoned,
imagin
For the record this the test that alerted us to this issue was the following:
https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/392/testReport/junit/(root)/Create%20failure%20messages/Create_account_password_mismatch_message/
2 problems here - tests run
> On Thu, Mar 6, 2014 at 5:49 PM, OQ wrote:
>
> > So I'm confused on the timeline here.
> >
> > Did the commit get merged before the testsuite found the breakage, or did
> > the commit get merged despite the testsuite failing?
>
>
> The commit was merged late Wednesday. The automated tests th
So the testsuite only runs on merged code and not pending-merge? That
sounds like a large oversight.
On Thu, Mar 6, 2014 at 6:55 PM, Chris McMahon wrote:
> On Thu, Mar 6, 2014 at 5:49 PM, OQ wrote:
>
> > So I'm confused on the timeline here.
> >
> > Did the commit get merged before the testsuit
On Thu, Mar 6, 2014 at 5:49 PM, OQ wrote:
> So I'm confused on the timeline here.
>
> Did the commit get merged before the testsuite found the breakage, or did
> the commit get merged despite the testsuite failing?
The commit was merged late Wednesday. The automated tests that
demonstrated the
So I'm confused on the timeline here.
Did the commit get merged before the testsuite found the breakage, or did
the commit get merged despite the testsuite failing?
Either way sounds like "When to merge a changeset" needs reviewed.
On Thu, Mar 6, 2014 at 6:38 PM, Greg Grossmeier wrote:
>
> >
> To take a couple of steps back...
>
> This happened because testing isn't robust enough?
>
> That should be discussed and followed up on.
Ish.
The suite of automatic tests caught this bug, actually. It's how the
mobile team found out about it as they got to work this morning. So the
testing
It seems that commenters here believe that the patch made it impossible to
create an account if JavaScript was disabled, or via MobileFrontend – this is
obviously not true, it just required an additional confirmation (which was by
design and +1'd by five people). Please stop spreading this disi
On Thu, Mar 6, 2014 at 4:08 PM, Erik Bernhardson wrote:
>
> Does core have any policies related to merging? The core features team
> has adopted a methodology(although slightly different) that we learned of
> from the VE team. Essentially +2 for 24 hours before a deployment branch
> is cut is l
On Thu, Mar 6, 2014 at 4:54 PM, Tyler Romeo wrote:
> On Thu, Mar 6, 2014 at 6:34 PM, Brion Vibber
> wrote:
>
> > Is there anything specific in the communications involved that you found
> > was problematic, other than a failure to include a backlink in the
> initial
> > revert?
> >
>
> I think t
On Thu, Mar 6, 2014 at 4:05 PM, Brion Vibber wrote:
> On Thu, Mar 6, 2014 at 3:54 PM, Tyler Romeo wrote:
>
> > On Thu, Mar 6, 2014 at 6:34 PM, Brion Vibber
> > wrote:
> >
> > > Is there anything specific in the communications involved that you
> found
> > > was problematic, other than a failure
Hi Tyler,
I understand you're frustrated here. As Jon says: "communication in the
wikiverse is hard". Also, running a top 10 website is also hard.
Others have covered many of the other points, but I wanted to make sure I
addressed one of the points that hasn't been covered yet:
On Thu, Mar 6,
On Thu, Mar 6, 2014 at 3:54 PM, Tyler Romeo wrote:
> On Thu, Mar 6, 2014 at 6:34 PM, Brion Vibber
> wrote:
>
> > Is there anything specific in the communications involved that you found
> > was problematic, other than a failure to include a backlink in the
> initial
> > revert?
> >
>
> I think t
On Thu, Mar 6, 2014 at 3:54 PM, Tyler Romeo wrote:
> I think this entire thing was a big failure in basic software development
> and systems administration. If MobileFrontend is so tightly coupled with
> the desktop login form, that is a problem with MobileFrontend. In addition,
> the fact that a
On Thu, Mar 6, 2014 at 6:34 PM, Brion Vibber wrote:
> Is there anything specific in the communications involved that you found
> was problematic, other than a failure to include a backlink in the initial
> revert?
>
I think this entire thing was a big failure in basic software development
and sy
To take a couple of steps back...
This happened because testing isn't robust enough?
That should be discussed and followed up on.
On Thu, Mar 6, 2014 at 3:34 PM, Brion Vibber wrote:
> On Thu, Mar 6, 2014 at 2:08 PM, Tyler Romeo wrote:
>
> > On Thu, Mar 6, 2014 at 4:15 PM, Steven Walling >
On Thu, Mar 6, 2014 at 2:08 PM, Tyler Romeo wrote:
> On Thu, Mar 6, 2014 at 4:15 PM, Steven Walling >wrote:
>
> > If your patch causes a serious UX regression like this, it's going to get
> > reverted. The core patch involved was being deployed to Wikimedia sites /
> > impacting MobileFrontEnd u
Communication in the wikiverse is hard.
To clarify, this is _not_ an issue with MobileFrontend. The same
problem effects users without JavaScript. There was a fundamental
problem with this patch that sadly didn't get caught during code
review. It broke the workflow of mobile on an important page i
On Thu, Mar 6, 2014 at 2:08 PM, Tyler Romeo wrote:
> On Thu, Mar 6, 2014 at 4:15 PM, Steven Walling >wrote:
>
> > If your patch causes a serious UX regression like this, it's going to get
> > reverted. The core patch involved was being deployed to Wikimedia sites /
> > impacting MobileFrontEnd u
Special:Code automatically generated a list of followup revisions for each
revision (based on linking/mentioning). It would be nice to have that in
Gerrit.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/lis
On Thu, Mar 6, 2014 at 4:15 PM, Steven Walling wrote:
> If your patch causes a serious UX regression like this, it's going to get
> reverted. The core patch involved was being deployed to Wikimedia sites /
> impacting MobileFrontEnd users today. If we had more time in the deployment
> cycle to wai
In over two years at WMF I have never been involved in a discussion like
this, but here goes:
In this case, I think it was entirely appropriate to revert immediately and
pick up the pieces later. The source of the code is immaterial, if Tim
Starling or Brion Vibber had merged this we would have
On Thu, Mar 6, 2014 at 8:29 PM, Tyler Romeo wrote:
> 1) not everybody is subscribed to mobile-l, so you cannot expect the
> original reviewers to see or know about it
> 2) this is an issue with MobileFrontend, not MediaWiki core
> 3) code being merged does not automatically cause a deployment, an
Hi everybody,
I cannot believe I have to say something about this, but I guess it's no
surprise.
Wikipedia has a notorious policy against edit warring, where users are
encouraged to discuss changes and achieve consensus before blindly
reverting. This applies even more so to Gerrit, since changes
98 matches
Mail list logo
