Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Daniel Kinzler]

Addendum, after sleeping over this:

Do we really want to manage something that is essentially configuration, namely
the set of available content models and formats, in a database table? How is it
maintained?

For context:
* As per T113034, we are movign away from managing interwiki prefixes in the
database, in favor of configuration files.
* Namespace IDs are defined in LocalSettings.php.

The original design of ContentHandler used integer IDs for content models and
formats in the DB. A mapping to human readable names is only needed for logging
and error messages anyway. Such a mapping could be maintain in
LocalSettings.php, just like we do for namespaces. This would also serve to
avoid ID clashes. My idea back then was to have a sort of registry on
mediawiki.org where extensions could reserve an ID for themselves, so that the
same ID would stand for the same model everywhere.

The disadvantage is of course that the model and format are not obvious when
eyeballing the result of an SQL query. It also makes database dumps more
brittle, since they cannot be interpreted without knowledge of the format and
model identifiers. That's an argument for having these in the DB.

Still... configuration in the database is nasty to maintain by hand, and also
annoying for extensions that define content models. Do we introduce a simple
hook that makes sure the content model and format gets registered in the 
database?


Am 11.07.2016 um 21:26 schrieb Daniel Kinzler:
> Hi Jaime, thanks for the pointer! I had completely forgotten about that.
> 
> A few thoughts about that RFC:
> 
> * I have long thought that content_format is pretty pointless and redundant. I
> haven't seen any content model that uses different serialization formats (I
> wrote a few that support two, but only ever used one). If the serialization 
> does
> need to change for some reason, it's usually easy to detect from the first few
> bytes.
> 
> * What we need instead is versioning on the content model. It happens quite
> often that the data structure you store changes slightly. Knowing what version
> you are dealing with is quite helpful when deserializing and processing. These
> differences are much harder to auto-detect than the serialization format,
> 
> * Per-page and per-revision content model will become redundant with
> Multi-Content-Revisions. We will instead have this info in the revision_slot
> table (multiple per revision). The same design still applies, but changing the
> page and revision table would be pointless. We would just ignore the content
> model (and format) in the page and revision table, and rely on the info for 
> the
> slot table instead. At some point, we can then drop this info from page and
> revision.
> 
> I propose to introduce the content_model (and maybe also content_format) 
> tables,
> but not touch the page and revision table for now. Instead, we introduce
> revision_slots for Multi-Content-Revisions first, using the content_model 
> table,
> and introduce model versioning; maybe drop the format in the process.
> 
> What do you think?
> 
> Am 11.07.2016 um 14:27 schrieb Jaime Crespo:
>> On Mon, Jul 11, 2016 at 2:07 PM, Daniel Kinzler
>>  wrote:
>>> It seems there is disagreement about what the correct interpretation of 
>>> NULL in
>>> the rev_content_model column is. Should NULL there mean
>>
>>> What should we write into rev_content_model in the future
>>
>> Content model handling is pending a refactoring:
>> 
>> Once that happens, they should never be NULL.
>>
>> ___
>> 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] What's the "correct" content model when rev_content_model is NULL?

[Jaime Crespo]

Your last question is a non issue for me- I do not care if things are
on the database or on configuration- that is not the issue I have been
complaining about.

What I blocked is having 6000 million rows (x40 due to redundancy)
with the same column value "gzip; version 3 (1-2-3-testing-testing. It
seems to work)" when it can be summarized as a 1-byte or less id (and
that id be explained somewhere else). The difference between both
options is extremely cheap to code and not only it would save
thousands of dollars in server cost, it would also minimize
maintenance cost and dramatically increase performance (or not
decrease it) on one of the largest bottlenecks for large wikis, as it
could fit fully into memory (yes, we have 515 GB servers now).

To give you an idea how how bad things are currently: WMF's
architecture technically does not store on the main databases servers
any data (a lot of asterisks here, allow me be inexact for the sake of
simplicity), only metadata, as the wiki content is stored on the
"external storage" subsystem. I gave a try to InnoDB compression [0]
(which has a very low compression ratio and a very small block size,
as it is for real-time purposes only), yet I was able to reduce the
disk usage to less than half by only compressing the top 10 tables:
[1]. If this is not an objective measurement of how inefficient
mediawiki schema is, I do not know how I can convince you otherwise.

Of course there are a lot of history and legacy and maintenance
issues, but when the guy that actually would spend days of his life
running schema changes so they do not affect production is the one
begging for them to happen you know there is an issue. And this is not
a "mediawiki" is bad complain- I think mediawiki is a very good piece
of software- I only want to make it better with very, very small
maintenance-like changes.

> The disadvantage is of course that the model and format are not obvious when
> eyeballing the result of an SQL query.

Are you serious? Because this is super-clear already :-P:

MariaDB  db1057 enwiki > SELECT * FROM revision LIMIT 1000,1\G
*** 1. row ***
   rev_text_id: 1161 -- what?
[...]
 rev_content_model: NULL -- what?
rev_content_format: NULL
1 row in set (0.00 sec)

MariaDB  db1057 enwiki > SELECT * FROM text WHERE old_id=1161; -- WTF, old_id?
++-++
| old_id | old_text| old_flags  |
++-++
|   1161 | DB://rc1/15474102/0 | external,utf-8 |  -- WTF is this?
++-++
1 row in set (0.03 sec)

I am joking at this point, but emulating what someone that looks at
the db would say. My point is that mediawiki is no longer simple.

More recommended reading (not for you, for many developers that still
are afraid of them- and I really found many cases in the wild for
otherwise good contributors):



[0] 
[1] 


On Tue, Jul 12, 2016 at 10:40 AM, Daniel Kinzler
 wrote:
> Addendum, after sleeping over this:
>
> Do we really want to manage something that is essentially configuration, 
> namely
> the set of available content models and formats, in a database table? How is 
> it
> maintained?

-- 
Jaime Crespo


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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Daniel Kinzler]

Am 12.07.2016 um 12:25 schrieb Jaime Crespo:
> Your last question is a non issue for me- I do not care if things are
> on the database or on configuration- that is not the issue I have been
> complaining about.

Yea, still something we need to figure out :)

I'm fine with the DB based solution, if we have decent tooling for extensions to
register their content models, etc.

> What I blocked is having 6000 million rows (x40 due to redundancy)
> with the same column value "gzip; version 3 (1-2-3-testing-testing. It
> seems to work)" when it can be summarized as a 1-byte or less id (and
> that id be explained somewhere else). 

Yea, that's not what I would recommend either. What I meant is that we can now,
as a stepping stone and without blocking on a schema change, fill in the null
values in the revision table for the revisions of a page that is being converted
to a new model, to avoid confusion. Converting pages to a different model is
relatively rare, so I think it would not have much of an impact on the big 
picture.

> Of course there are a lot of history and legacy and maintenance
> issues, but when the guy that actually would spend days of his life
> running schema changes so they do not affect production is the one
> begging for them to happen you know there is an issue. And this is not
> a "mediawiki" is bad complain- I think mediawiki is a very good piece
> of software- I only want to make it better with very, very small
> maintenance-like changes.

I'm all for it!

> 
>> The disadvantage is of course that the model and format are not obvious when
>> eyeballing the result of an SQL query.
> 
> Are you serious? Because this is super-clear already :-P:

That was, if I remember correctly, one of the arguments for using readable
strings there, instead of int values and a config variable, as I originally
proposed. This was discussed at the last Berlin hackathon, must have been 2012.
Tim may remember more details. We should probably re-consider the pros and cons
we discussed back then when planning to change the scham now.

-- daniel

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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Jaime Crespo]

On Tue, Jul 12, 2016 at 12:40 PM, Daniel Kinzler
 wrote:
> Yea, still something we need to figure out :)

> That was, if I remember correctly, one of the arguments for using readable
> strings there, instead of int values and a config variable, as I originally
> proposed. This was discussed at the last Berlin hackathon, must have been 
> 2012.
> Tim may remember more details. We should probably re-consider the pros and 
> cons
> we discussed back then when planning to change the scham now.

But that was already re-reviewed and discussed and approved by Tim
himself (among others) on 2015:
.

-- 
Jaime Crespo


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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Daniel Kinzler]

Am 12.07.2016 um 13:23 schrieb Jaime Crespo:
> On Tue, Jul 12, 2016 at 12:40 PM, Daniel Kinzler
>  wrote:
>> Yea, still something we need to figure out :)
> 
>> That was, if I remember correctly, one of the arguments for using readable
>> strings there, instead of int values and a config variable, as I originally
>> proposed. This was discussed at the last Berlin hackathon, must have been 
>> 2012.
>> Tim may remember more details. We should probably re-consider the pros and 
>> cons
>> we discussed back then when planning to change the scham now.
> 
> But that was already re-reviewed and discussed and approved by Tim
> himself (among others) on 2015:
> .


Yes, I saw that. And I'm happy about it! But the aspect of maintainance and
tooling seems to be completely absent from the discussion and proposal. From a
DB perspective, looks fine. I just feel it is missing a few crucial bits. Like,
how does anything ever get into these tables?

-- daniel

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

[Wikitech-l] How to fake a login with AuthManager?

[Daniel Barrett]

What is the proper incantation for faking a successful login (for a given user) 
as part of a unit test? My old code was:

$context = RequestContext::getMain();
$specialPage = new LoginForm( $context->getRequest() );
$user->logout();
$specialPage->showReturnToPage('successredirect');
$specialPage->successfulLogin();

What is the right way to perform this task with AuthManager?

Thanks very much,
DanB


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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Brad Jorsch (Anomie)]

On Tue, Jul 12, 2016 at 4:40 AM, Daniel Kinzler  wrote:

> Do we really want to manage something that is essentially configuration,
> namely the set of available content models and formats, in a database
> table? How is it maintained?
>

One simple method: assign the numeric IDs by making the numeric ID column
auto-increment, and insert the model strings into the table as needed.
PageAssessments uses this model for tracking its project tags.[1]

The disadvantage is that there wouldn't be any cross-wiki mapping between
model names and ids, which can be mitigated somewhat by never exposing the
ids externally.

 [1]:
https://phabricator.wikimedia.org/diffusion/EPAS/browse/master/PageAssessmentsBody.php;c7b21e97f650face3a257ab70763a5abad420992$41-44

>
> Such a mapping could be maintain in LocalSettings.php, just like we do for
> namespaces. This would also serve to avoid ID clashes. My idea back then
> was to have a sort of registry on mediawiki.org where extensions could
> reserve an ID for themselves, so that the same ID would stand for the same
> model everywhere.
>

Does the registry idea work all that smoothly for namespaces, though?


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Daniel Kinzler]

Am 12.07.2016 um 17:02 schrieb Brad Jorsch (Anomie):
> On Tue, Jul 12, 2016 at 4:40 AM, Daniel Kinzler 
> One simple method: assign the numeric IDs by making the numeric ID column
> auto-increment, and insert the model strings into the table as needed.

When exactly? When update.php runs? Should work fine, but I'd like a nice
interface that extensions can use for this. Or should we check and auto-insert
on every page edit?

To answer my own question about config in the database: unlike interwiki/sites
and namespaces, this isn't realyl configuration, it's a registry used by
extensions. Users may freely derfine namespaces for their wiki, but they can't
freely define content models.

> The disadvantage is that there wouldn't be any cross-wiki mapping between
> model names and ids, which can be mitigated somewhat by never exposing the
> ids externally.

Yes, we should definitly not expose those!

> Does the registry idea work all that smoothly for namespaces, though?

I don't think it was ever really tried for namespace. But it's not a perfect
solution. Just a possibility.


-- daniel

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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Rob Lanphier]

On Tue, Jul 12, 2016 at 1:40 AM, Daniel Kinzler  wrote:

> Do we really want to manage something that is essentially configuration,
> namely
> the set of available content models and formats, in a database table? How
> is it
> maintained?
>
> For context:
> * As per T113034, we are movign away from managing interwiki prefixes in
> the
> database, in favor of configuration files.
> * Namespace IDs are defined in LocalSettings.php.
>
> The original design of ContentHandler used integer IDs for content models
> and
> formats in the DB. A mapping to human readable names is only needed for
> logging
> and error messages anyway.


This oversimplifies things greatly.  Integer IDs need to be mapped to some
well-specified, non-local (global?) identifier for many many purposes
(reading exports, writing exports, reading site content, displaying site
content for many contexts, etc)

As Jaime points out, we don't want or need 6 billion copies of the same
identifier in our database.  However, relegating that information to
LocalSettings.php means that we'll have to manually sync that critical
configuration data for use by non-PHP implementations interacting with the
information.

On Tue, Jul 12, 2016 at 3:40 AM, Daniel Kinzler  wrote:
>
> I'm fine with the DB based solution, if we have decent tooling for
> extensions to
> register their content models, etc.


We need to put a lot of thought into content model management generally.
This statement implies managing content models outside of the database is
easy.

Rob



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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Brad Jorsch (Anomie)]

On Tue, Jul 12, 2016 at 11:47 AM, Daniel Kinzler <
daniel.kinz...@wikimedia.de> wrote:

> Am 12.07.2016 um 17:02 schrieb Brad Jorsch (Anomie):
> > On Tue, Jul 12, 2016 at 4:40 AM, Daniel Kinzler <
> daniel.kinz...@wikimedia.de
> >
> > One simple method: assign the numeric IDs by making the numeric ID column
> > auto-increment, and insert the model strings into the table as needed.
>
> When exactly? When update.php runs? Should work fine, but I'd like a nice
> interface that extensions can use for this. Or should we check and
> auto-insert
> on every page edit?
>

The linked example is inserting (if necessary) on every page edit. The
check part needs to happen on every edit anyway because it needs to fetch
the ID for the name.

update.php would work too as long as things blow up clearly when someone
didn't run update.php recently enough. That could also allow us to let the
extension suggest an ID, so the registrar would only have to assign a
"random" ID in case of a conflict.


> > Does the registry idea work all that smoothly for namespaces, though?
>
> I don't think it was ever really tried for namespace. But it's not a
> perfect
> solution. Just a possibility.
>

https://www.mediawiki.org/wiki/Extension_default_namespaces?


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to fake a login with AuthManager?

[Brad Jorsch (Anomie)]

On Tue, Jul 12, 2016 at 11:01 AM, Daniel Barrett  wrote:

> What is the proper incantation for faking a successful login (for a given
> user) as part of a unit test? My old code was:
>
> $context = RequestContext::getMain();
> $specialPage = new LoginForm( $context->getRequest() );
> $user->logout();
> $specialPage->showReturnToPage('successredirect');
> $specialPage->successfulLogin();
>
> What is the right way to perform this task with AuthManager?
>

What is the task exactly? Just outputting a "login successful" page without
actually logging the user in? I guess the equivalent would be to call
SpecialUserLogin::successfulAction() (using TestingAccessWrapper).


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Daniel Kinzler]

Am 12.07.2016 um 18:00 schrieb Rob Lanphier:
> On Tue, Jul 12, 2016 at 1:40 AM, Daniel Kinzler > The original design of ContentHandler used integer IDs for content models 
>> and formats in the DB. A mapping to human readable names is only needed
>> for logging and error messages anyway.
> 
> This oversimplifies things greatly.  Integer IDs need to be mapped to some
> well-specified, non-local (global?) identifier for many many purposes
> (reading exports, writing exports, reading site content, displaying site
> content for many contexts, etc)

Yea, sorry. That we only need this for logging is what I assumed back then. Not
exposing the numeric ID at all, and using the canonical name in dumps, the API,
etc, avoids a lot of trouble (but doesn't come free).

> We need to put a lot of thought into content model management generally.
> This statement implies managing content models outside of the database is
> easy.

Well, it's the same as namespaces: they are easy to set up, but also too easy to
change, so it's easy to create a mess...

As explained in my earlier response, I now realized that content models differ
from namespaces in that they are not really configured by people, but rather
registered by extensions. That makes it a lot less awkward to have them in the
database. We still have to agree on a good trigger for the registration, but it
doesn't seem to be a tricky issue.

What we still need to figure out is how to solve the chicken-and-egg situation
with Multi-Content-Rev. At the moment, I'm thinking this might work:

* introduce content model (and format) registry in the DB, and populate it.
* leave page and revision table as they are for now.
* introduce slots table, use the new content_model (and content_format) table.
* stop using the content model (and format) from the page and revision tables
* drop the content model (and format) from the page and revision tables

Does that sound liek a good plan? Let's for a moment assume we can get slots
fully rolled out by the end of the year.

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

[Wikitech-l] Revert to 1.28.0-wmf.8

[Matthew Flaschen]

All wikis were rolled back to 1.28.0-wmf.8 last night due to an increase 
in https://phabricator.wikimedia.org/T119736 .  We're working on it, and 
will either go back to 1.28.0-wmf.9, or to 1.28.0-wmf.10 (at normal 
train pace) when it's resolved.


Matt

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

[Wikitech-l] All wikis reverted to wmf.8 last night due to T119736

[Greg Grossmeier]

https://phabricator.wikimedia.org/T119736 - "Could not find local user data for 
{Username}@{wiki}"

There was an order of magnitude increase in the rate of those errors
that started on July 7th.

Investigation and remediation is on-going.

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


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

Re: [Wikitech-l] How to fake a login with AuthManager?

[Daniel Barrett]

>On Tue, Jul 12, 2016 at 11:01 AM, Daniel Barrett  
>wrote:
>> What is the proper incantation for faking a successful login (for a given
>> user) as part of a unit test? My old code was:
>>
>> $context = RequestContext::getMain();
>> $specialPage = new LoginForm( $context->getRequest() );
>> $user->logout();
>> $specialPage->showReturnToPage('successredirect');
>> $specialPage->successfulLogin();
>>
>> What is the right way to perform this task with AuthManager?

Brad Jorsch (Anomie) asks:
>What is the task exactly? Just outputting a "login successful" page without
>actually logging the user in? I guess the equivalent would be to call
>SpecialUserLogin::successfulAction() (using TestingAccessWrapper).

Thanks Brad. I have an extension that takes a special action when a user logs 
in for the first time. (It automatically creates the user page, User:Username.) 
I have a unit test that creates a user, logs that user in (as above), and then 
checks that the user page was created.  With the LoginForm class deprecated, I 
am looking for the right way to implement this test in MW 1.27. Any insights 
are appreciated.

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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Rob Lanphier]

On Tue, Jul 12, 2016 at 8:02 AM, Brad Jorsch (Anomie)
 wrote:
> One simple method: assign the numeric IDs by making the numeric ID column
> auto-increment, and insert the model strings into the table as needed.
> PageAssessments uses this model for tracking its project tags.[1]
>
> The disadvantage is that there wouldn't be any cross-wiki mapping between
> model names and ids, which can be mitigated somewhat by never exposing the
> ids externally.

Could you explain this idea in a way that doesn't require diving into
the codebase to figure out what you mean?  Cloaking the mapping of
local ids (e.g. auto incremented in the DB) to global ids ("model
names") seems to suggest a new way of making our system behave in an
inscrutable way.

On Tue, Jul 12, 2016 at 9:00 AM, Brad Jorsch (Anomie)
 wrote:
>  [Does this namespace registry idea work?]
>
> https://www.mediawiki.org/wiki/Extension_default_namespaces?

 That doesn't seem like a good model to emulate.  We're not iana.org,
and we don't have anywhere near the rigor defined in IETF RFC 5226.  I
may put further thoughts on this topic in the Interwiki map RFC
(T113034) task

Rob

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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Daniel Kinzler]

Am 12.07.2016 um 21:02 schrieb Rob Lanphier:
> On Tue, Jul 12, 2016 at 8:02 AM, Brad Jorsch (Anomie)
>  wrote:
>> One simple method: assign the numeric IDs by making the numeric ID column
>> auto-increment, and insert the model strings into the table as needed.
>> PageAssessments uses this model for tracking its project tags.[1]
>>
>> The disadvantage is that there wouldn't be any cross-wiki mapping between
>> model names and ids, which can be mitigated somewhat by never exposing the
>> ids externally.
> 
> Could you explain this idea in a way that doesn't require diving into
> the codebase to figure out what you mean?  Cloaking the mapping of
> local ids (e.g. auto incremented in the DB) to global ids ("model
> names") seems to suggest a new way of making our system behave in an
> inscrutable way.

The idea is that in API responses (and requests), in XML dumps, etc, the content
model for wikitext will be represented as the string "wikitext", even if the
internal ID is 1 in the database of one wiki, and 37 on another. Clients have to
know the canonical names, they are not concerned with the internal ids. They are
considered an internal optimization, an implementation detail.


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Brion Vibber]

On Tuesday, July 12, 2016, Daniel Kinzler 
wrote:

> Am 12.07.2016 um 18:00 schrieb Rob Lanphier:
> > On Tue, Jul 12, 2016 at 1:40 AM, Daniel Kinzler <
> daniel.kinz...@wikimedia.de 
> >> The original design of ContentHandler used integer IDs for content
> models
> >> and formats in the DB. A mapping to human readable names is only needed
> >> for logging and error messages anyway.
> >
> > This oversimplifies things greatly.  Integer IDs need to be mapped to
> some
> > well-specified, non-local (global?) identifier for many many purposes
> > (reading exports, writing exports, reading site content, displaying site
> > content for many contexts, etc)
>
> Yea, sorry. That we only need this for logging is what I assumed back
> then. Not
> exposing the numeric ID at all, and using the canonical name in dumps, the
> API,
> etc, avoids a lot of trouble (but doesn't come free).


Yes, numeric ids are internal and never to be exposed ideally. We should've
done same wth namespaces but got dragged into compat hell. :)


>
> > We need to put a lot of thought into content model management generally.
> > This statement implies managing content models outside of the database is
> > easy.
>
> Well, it's the same as namespaces: they are easy to set up, but also too
> easy to
> change, so it's easy to create a mess...
>
> As explained in my earlier response, I now realized that content models
> differ
> from namespaces in that they are not really configured by people, but
> rather
> registered by extensions. That makes it a lot less awkward to have them in
> the
> database. We still have to agree on a good trigger for the registration,
> but it
> doesn't seem to be a tricky issue.


Yeah an auto insert if needed is good in theory, though I worry about write
contention on the central mapping table. If no write locks kept in the
common case of no insertion needed then I think the ideas proposed should
work.


>
> What we still need to figure out is how to solve the chicken-and-egg
> situation
> with Multi-Content-Rev. At the moment, I'm thinking this might work:
>
> * introduce content model (and format) registry in the DB, and populate it.
> * leave page and revision table as they are for now.
> * introduce slots table, use the new content_model (and content_format)
> table.
> * stop using the content model (and format) from the page and revision
> tables
> * drop the content model (and format) from the page and revision tables
>
> Does that sound liek a good plan? Let's for a moment assume we can get
> slots
> fully rolled out by the end of the year.


This sounds good to me - lets us introduce a more space efficient model
mapping and drop the extra fields from page and rev later.

-- brion


>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Greg Grossmeier]

> https://phabricator.wikimedia.org/T119736 - "Could not find local user data 
> for {Username}@{wiki}"
> 
> There was an order of magnitude increase in the rate of those errors
> that started on July 7th.
> 
> Investigation and remediation is on-going.

Investigation and remediation is mostly complete[0] and the vast
majority of cases have been addressed. There are still users who will
experience this error for the next ~1 day.[1]

1.28.0-wmf.10 will be branched tomorrow and we will run an abbreviated
train schedule (group0 and group1 on Wednesday, group2 on Thursday).

Thanks to Matt Flaschen and Brad Jorsch (and others like Ori Livneh and
Bryan Davis) for their help.

Sorry for the inconvenience.

Greg


[0] Modulo https://phabricator.wikimedia.org/T140156 which shouldn't
effect auto-creation.

[1] Users who were affected by this already before the fixes in the
code were deployed will still have the issue until the script that fixes
those cases completes running, which takes roughly 1 day. There is a run
of it going now, but we will run it again as we deployed fixes mid-run.

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


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

[Wikitech-l] Change to SWAT deploy (aka "let's not break things")

[Greg Grossmeier]

Hello!

For a while we've had the ability to test changes in production on a
single host (mw1017) using a special HTTP header (X-Wikimedia-Debug).
This has proved useful for many when deploying changes in production and
we are adding it to the SWAT deploy process.

See the steps at:
https://wikitech.wikimedia.org/wiki/SWAT_deploys#Doing_the_deploy

Namely:
4. After merge, the SWAT team member fetches the patch(es) to tin and then
   runs scap pull on mw1017
5. The submitter tests the change by using the instructions at
   X-Wikimedia-Debug#Staging_changes AND the SWAT team member checks the
   error logs
6. If there are no errors and the fix seems to work (if testable in that
   manner), then then SWAT team member deploys the patch to the entire
   fleet

How to test on mw1017:
https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug#Staging_changes

To less exciting SWAT deploys,

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


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

Re: [Wikitech-l] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Ori Livneh]

On Tue, Jul 12, 2016 at 4:07 PM, Greg Grossmeier  wrote:

> 
> > https://phabricator.wikimedia.org/T119736 - "Could not find local user
> data for {Username}@{wiki}"
> >
> > There was an order of magnitude increase in the rate of those errors
> > that started on July 7th.
> >
> > Investigation and remediation is on-going.
>
> Investigation and remediation is mostly complete[0] and the vast
> majority of cases have been addressed. There are still users who will
> experience this error for the next ~1 day.[1]
>

Is it actually fixed? It doesn't look like it, from the logs.

Since midnight UTC on July 7, 3,195 distinct users have tried and failed to
log in a combined total of 25,047 times, or an average of approximately
eight times per user. The six days that have passed since then were
business as usual for the Wikimedia Engineering.

Our failure to react to this swiftly and comprehensively is appalling and
embarrassing. It represents failure of process at multiple levels and a
lack of accountability.

I think we need to have a serious discussion about what happened, and think
very hard about the changes we would need to make to our processes and
organizational structure to prevent a recurrence.

I think we should also reach out to the users that were affected and
apologize.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Greg Grossmeier]

> On Tue, Jul 12, 2016 at 4:07 PM, Greg Grossmeier  wrote:
> 
> > 
> > > https://phabricator.wikimedia.org/T119736 - "Could not find local user
> > data for {Username}@{wiki}"
> > >
> > > There was an order of magnitude increase in the rate of those errors
> > > that started on July 7th.
> > >
> > > Investigation and remediation is on-going.
> >
> > Investigation and remediation is mostly complete[0] and the vast
> > majority of cases have been addressed. There are still users who will
> > experience this error for the next ~1 day.[1]
> >
> 
> Is it actually fixed? It doesn't look like it, from the logs.

That was the information I was given. If it is not improved after the
fixes and letting the maint script finish then we'll know more
certainly, and with that certainty can modify our plans (as we always
do).

> Our failure to react to this swiftly and comprehensively is appalling and
> embarrassing. It represents failure of process at multiple levels and a
> lack of accountability.

Matt is working on an incident report for this.

> I think we should also reach out to the users that were affected and
> apologize.

That certainly should/could be one of the action items.

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] [Ops] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[aude]

On Tue, Jul 12, 2016 at 7:56 PM, Ori Livneh  wrote:

> On Tue, Jul 12, 2016 at 4:07 PM, Greg Grossmeier 
> wrote:
>
>> 
>> > https://phabricator.wikimedia.org/T119736 - "Could not find local user
>> data for {Username}@{wiki}"
>> >
>> > There was an order of magnitude increase in the rate of those errors
>> > that started on July 7th.
>> >
>> > Investigation and remediation is on-going.
>>
>> Investigation and remediation is mostly complete[0] and the vast
>> majority of cases have been addressed. There are still users who will
>> experience this error for the next ~1 day.[1]
>>
>
> Is it actually fixed? It doesn't look like it, from the logs.
>
> Since midnight UTC on July 7, 3,195 distinct users have tried and failed
> to log in a combined total of 25,047 times, or an average of approximately
> eight times per user. The six days that have passed since then were
> business as usual for the Wikimedia Engineering.
>
> Our failure to react to this swiftly and comprehensively is appalling and
> embarrassing. It represents failure of process at multiple levels and a
> lack of accountability.
>

This (unbreak now) bug has been open since November.  I wonder how this has
been allowed to remain open and not addressed for this long?

A new user ran into this issue in June at an editathon that I attended. In
his case, I could fix the problem by manually deleting the offending row in
the database, but most of the time, the user likely gives up :(


>
> I think we need to have a serious discussion about what happened, and
> think very hard about the changes we would need to make to our processes
> and organizational structure to prevent a recurrence.
>
> I think we should also reach out to the users that were affected and
> apologize.
>

+1

Cheers,
Katie


>
> ___
> Ops mailing list
> o...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
>


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

Re: [Wikitech-l] [Ops] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Matthew Flaschen]

On 07/12/2016 08:15 PM, aude wrote:

This (unbreak now) bug has been open since November.  I wonder how this
has been allowed to remain open and not addressed for this long?


This has not all been caused by Echo, and it really isn't one bug, just 
one symptom.


There are clearly multiple causes.  The Echo one has been addressed, and 
there are multiple fixes and mitigation on the CentralAuth/core auth 
side, some merged (e.g. https://gerrit.wikimedia.org/r/#/c/298531/ , 
https://gerrit.wikimedia.org/r/#/c/298416/ ), some still being worked 
on/discussed ( https://gerrit.wikimedia.org/r/#/c/297946/ , 
https://gerrit.wikimedia.org/r/#/c/297936/ ), but work is not done.


Matt

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

[Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Chad Horohoe]

Hi,

Daniel and I have been spending a lot of time in the last week preparing a
smooth upgrade
path for Gerrit to a new (and supported version). The migration will be
coming soon but I could
use your help testing things in the meantime.

https://gerrit-new.wikimedia.org/r/

The database is a snapshot from last week and the git data is up to date as
of a few hours
ago. Please use this opportunity to test the new installation and make sure
it works for you.
Make a change. Do some reviews. Do the things you usually would.

Again, this is snapshot data so: A) Don't worry about messing up the real
install, and B) Don't
expect any changes to persist after the migration.

If nobody identifies any major blockers, we'll go ahead and set an upgrade
time for the
immediate future.

Thanks so much!

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

Re: [Wikitech-l] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Matthew Flaschen]

On 07/12/2016 07:56 PM, Ori Livneh wrote:

Is it actually fixed? It doesn't look like it, from the logs.


It's beyond unhelpful that you would send this email without pointing to 
the logs you are referring to.  With a statement like that, a paste is 
called for. 	


If you mean the existing inconsistent state that already exists, there 
is a script running as Greg explicitly noted.



It represents failure of process at multiple levels
and a lack of accountability.


"Lack of accountability" is a serious charge, and one that I disagree 
with.  That would imply people did not take responsibility for their 
code's failures, or did not this seriously, and that is not what I see. 
 The Collaboration team and other people, such as Bryan Davis, worked 
on this promptly as soon as they were made aware, and I take full 
responsibility for causing this issue.


The severity level may not have been evident until last night (thanks to 
Legoktm for helping show this).  Could the severity have been realized 
sooner?  Yes, but I'm not sure this is the way to make that happen.



I think we need to have a serious discussion about what happened, and
think very hard about the changes we would need to make to our processes
and organizational structure to prevent a recurrence.


I am already writing an incident report, and I welcome a discussion.

However, I strongly disagree with the attitude that /there was a serious 
bug; therefore no one cared/ .


I don't dispute it's a very serious and unfortunate bug, and I agree we 
should work to prevent bugs, and ensure they're remediated more promptly.


But I take my work and the extensions my team is responsible for 
seriously, and I worked on this urgently as soon as I knew about it.


Matt Flaschen

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

Re: [Wikitech-l] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Matthew Flaschen]

On 07/12/2016 07:07 PM, Greg Grossmeier wrote:

Thanks to Matt Flaschen and Brad Jorsch (and others like Ori Livneh and
Bryan Davis) for their help.


Also Roan Kattouw, Kunal Mehta, and Stephane Bisson.

Matt


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

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Danny B.]

First of all - thanks for putting the effort to upgrade!

Unfortunately that is the last positive sentence I'll have here. However, it
is not your fault at all. It is all about expectations. And my expectations 
were that the UI/UX will be much more mature than the current version we 
use. However, my biggest expectation turned into biggest disappointment.

Things are yet more unintuitive and crazy than in the current version. Three
outstanding examples on behalf of others:
1) It took me quite a long time to find a way, how to switch between 
patchsets. Not even mentioning I can't compare them.
2) It took me also quite a long time to find a way, how to add new comment.
3) The commit message is in width limited box, which causes most of the 
messages to be partially invisible and necessity to scroll.
[I'm not going to say the solutions here, everybody should experience on 
their own...]

I assume that the slowness is just because it is testing environment and 
production will be faster, but just in case, I'm mentioning that too (ask 
for details should you need any).

I apologize for not being positive, I can imagine that being discouraging. 
On the other hand I can see one promise behind that: I believe this will be 
another kicker for faster migration to Differential & co. For the time being
- do any skins exist? If yes, wouldn't it be worth it to investigate them 
and possibly install any instead of the default one?


Kind regards


Danny B.


-- Původní zpráva --
Od: Chad Horohoe 
Komu: wikitech-l@lists.wikimedia.org, Development and Operations engineers 
(WMF only) 
Datum: 13. 7. 2016 3:19:16
Předmět: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

"Hi,

Daniel and I have been spending a lot of time in the last week preparing a
smooth upgrade
path for Gerrit to a new (and supported version). The migration will be
coming soon but I could
use your help testing things in the meantime.

https://gerrit-new.wikimedia.org/r/

The database is a snapshot from last week and the git data is up to date as
of a few hours
ago. Please use this opportunity to test the new installation and make sure
it works for you.
Make a change. Do some reviews. Do the things you usually would.

Again, this is snapshot data so: A) Don't worry about messing up the real
install, and B) Don't
expect any changes to persist after the migration.

If nobody identifies any major blockers, we'll go ahead and set an upgrade
time for the
immediate future.

Thanks so much!

-Chad & Daniel
___
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] Gerrit 2.12.2 test instance - PLEASE TEST

[Bartosz Dziewoński]

I have tested it and I love it. It is all I was hoping it would be and 
more. The inline commit editing is quite nice, the lists of related 
commits are useful, but the warnings about merge conflicts are the best 
thing ever. The sooner it's live, the better!


--
Bartosz Dziewoński

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

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Chad]

On Tue, Jul 12, 2016 at 7:39 PM Danny B.  wrote:

> First of all - thanks for putting the effort to upgrade!
>
> Unfortunately that is the last positive sentence I'll have here. However,
> it
> is not your fault at all. It is all about expectations. And my expectations
> were that the UI/UX will be much more mature than the current version we
> use. However, my biggest expectation turned into biggest disappointment.
>
>
I'm sorry that you had this expectation. Gerrit has always been a tool
written by engineers for engineers and has never benefited from a
dedicated design team working on it (to my knowledge). While I think
some things have improved, it's definitely still got rough edges and a
learning curve.


> Things are yet more unintuitive and crazy than in the current version.
> Three
> outstanding examples on behalf of others:
> 1) It took me quite a long time to find a way, how to switch between
> patchsets. Not even mentioning I can't compare them.
>

You can still compare them, it's with the "Diff against" dropdown that
defaults to "Base." It's right above the filename listing.


> 2) It took me also quite a long time to find a way, how to add new comment.
>

That reply button could be a little bigger, but yeah, the thing I'll mainly
point out is that the various action buttons have been moved closer to
the top.


> 3) The commit message is in width limited box, which causes most of the
> messages to be partially invisible and necessity to scroll.
> [I'm not going to say the solutions here, everybody should experience on
> their own...]
>
>
I see what you mean here. Maybe a CSS tweak to make it wider by default?


> I assume that the slowness is just because it is testing environment and
> production will be faster, but just in case, I'm mentioning that too (ask
> for details should you need any).
>
>
I'm not seeing slowness myself, but I have heard this complaint from a
few others. For what it's worth, this *is* running on production hardware
with higher specs than the old machine, so if anything it should be faster!
There's some new features and other things we're not quite making use
of yet, so we might need to do some further fine-tuning.


> I apologize for not being positive, I can imagine that being discouraging.
> On the other hand I can see one promise behind that: I believe this will be
> another kicker for faster migration to Differential & co.


I'm not discouraged. Thank you for the feedback!


> For the time being
> - do any skins exist? If yes, wouldn't it be worth it to investigate them
> and possibly install any instead of the default one?
>
>
No, there are no such things as skins in Gerrit. We can adjust a few things
here and there with some CSS and header files, but there's no real support
for a UI other than what Gerrit ships.

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

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Bahodir Mansurov]

Great! I especially like how scrolling works when comparing old and new  
versions of files.


Thanks for upgrading.


On Wed, 13 Jul 2016 06:17:58 +0500, Chad Horohoe   
wrote:



Hi,

Daniel and I have been spending a lot of time in the last week preparing  
a

smooth upgrade
path for Gerrit to a new (and supported version). The migration will be
coming soon but I could
use your help testing things in the meantime.

https://gerrit-new.wikimedia.org/r/

The database is a snapshot from last week and the git data is up to date  
as

of a few hours
ago. Please use this opportunity to test the new installation and make  
sure

it works for you.
Make a change. Do some reviews. Do the things you usually would.

Again, this is snapshot data so: A) Don't worry about messing up the real
install, and B) Don't
expect any changes to persist after the migration.

If nobody identifies any major blockers, we'll go ahead and set an  
upgrade

time for the
immediate future.

Thanks so much!

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



--
Baha

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

Re: [Wikitech-l] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Legoktm]

Hi,

On 07/12/2016 04:56 PM, Ori Livneh wrote:
> Is it actually fixed? It doesn't look like it, from the logs.
> 
> Since midnight UTC on July 7, 3,195 distinct users have tried and failed to
> log in a combined total of 25,047 times, or an average of approximately
> eight times per user. The six days that have passed since then were
> business as usual for the Wikimedia Engineering.

We should not be blocking login anymore. The patch[1] I deployed last
night catches the exceptions so users are able to login, but still
continues to log them. I'm not sure if there's a way to tell the
difference between an exception that was shown to a user and one that
was just logged.

[1] https://gerrit.wikimedia.org/r/#/c/298416/

-- Legoktm

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

Re: [Wikitech-l] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Matthew Flaschen]

On 07/12/2016 09:25 PM, Matthew Flaschen wrote:

I am already writing an incident report, and I welcome a discussion.


Incident report for the Echo part of this: 
https://wikitech.wikimedia.org/wiki/Incident_documentation/20160712-EchoCentralAuth 
.  Please edit and improve.


Thanks,

Matt

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

Re: [Wikitech-l] [Ops] [Engineering] The train will resume tomorrow (was Re: All wikis reverted to wmf.8 last night due to T119736)

[Giuseppe Lavagetto]

On Wed, Jul 13, 2016 at 2:15 AM, aude  wrote:
> On Tue, Jul 12, 2016 at 7:56 PM, Ori Livneh  wrote:
>> Our failure to react to this swiftly and comprehensively is appalling and
>> embarrassing. It represents failure of process at multiple levels and a lack
>> of accountability.
>
>
> This (unbreak now) bug has been open since November.  I wonder how this has
> been allowed to remain open and not addressed for this long?
>

I am sure we could've done way better even in our current structure,
but it's pretty clear to me that the absence of a team dedicated to
MediaWiki itself calls for such things to happen.

Which is pretty absurd, when you remember that 99% of our traffic is
still served by it.

Cheers

G.
-- 
Giuseppe Lavagetto, Ph.d.
Senior Technical Operations Engineer, Wikimedia Foundation

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

Re: [Wikitech-l] [Engineering] Gerrit 2.12.2 test instance - PLEASE TEST

[Mukunda Modell]

So I'll start by ignoring horrible UI/UX which, IMO, hasn't improved very
much over the old version.

I've used the test install for various routine activities and so far I've
only found one bug:

When I click the change-id link in commit messages, it takes me to a 404
page.

On Tue, Jul 12, 2016 at 8:17 PM, Chad Horohoe 
wrote:

> Hi,
>
> Daniel and I have been spending a lot of time in the last week preparing a
> smooth upgrade
> path for Gerrit to a new (and supported version). The migration will be
> coming soon but I could
> use your help testing things in the meantime.
>
> https://gerrit-new.wikimedia.org/r/
>
> The database is a snapshot from last week and the git data is up to date
> as of a few hours
> ago. Please use this opportunity to test the new installation and make
> sure it works for you.
> Make a change. Do some reviews. Do the things you usually would.
>
> Again, this is snapshot data so: A) Don't worry about messing up the real
> install, and B) Don't
> expect any changes to persist after the migration.
>
> If nobody identifies any major blockers, we'll go ahead and set an upgrade
> time for the
> immediate future.
>
> Thanks so much!
>
> -Chad & Daniel
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Niklas Laxström]

Many good and bad changes I can live with. One thing I will miss:
* Columns setting no longer wraps the diff lines. Horizontal scroll is
now unavoidable and cumbersome due to having to use either the mouse
or the arrow keys to move the cursor on the line.

Tips for others:
* I previously used 'r' to go straight to publishing my comments. This
shortcut is now 'a'.
* 'x' expands all history – the preference for having it always
expanded seems to be gone.

  -Niklas

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