Is it possible that you are seeing something fail during the retry, but the cause for the retry was something else?
That raises the question why that job fails.
The patch in question should only chnange the behavior of *failing* DataUpdates. If no DataUpdates fail, the new behavior should be exactly the same as the old.
Fri, Mar 15
I would like to understand the problem better. If DBAL can do the schema changes, why can't we use it for the schema changes, even if it doesn't help us with the other parts of the issue?
Thu, Mar 14
Consistent CSS classes and element IDs would indeed be great. This could go along with documentation stating explicitly what guarantees are (not) given.
I would truly value having a proper API for accessing skins via gadgets rather than relying on CSS selectors.
What are everyone's thoughts on how to address making a consistent DOM across all skins?
@Skizzerz TechCom is trying to shift weight from IRC meetings to discussion here on phabricator. For this purpose, I suggest to copy the essential parts of the RFC from the wiki to the task description and writing an email to wikitech-l, asking for input. This would mean moving the RFC to "under discussion" on the RFC board for now. If it appears like there is consensus forming in the discussion on this ticket, we could perhaps move the RFC directly to last call without the need for an IRC meeting (or you could request an IRC meeting again, if you think it would be useful).
Accepted as an RFC
Wed, Mar 13
includes/Revision/RevisionStore.php (I'll touch only getQueryInfo(). All other references are either gated directly, or are in private functions with all calls gated)
To clarify: the intent of the new policy is to allow +2 access to be granted without community discussion or consensus building, upon request of trusted organizations. This does not imply a right or automatism for that request to be followed, it can still be denied or revoked at the discretion of the groups/roles mentioned in the policy. This means that membership in a trusted org's own group must not auomatically imply membership in the mediawiki group.
Tue, Mar 12
Mon, Mar 11
Fri, Mar 8
The proposal states:
Thu, Mar 7
Wed, Mar 6
I put some related thoughts here: https://www.mediawiki.org/wiki/User:DKinzler_(WMF)/TechCom_MO#RFC_Facilitation
Tue, Mar 5
Any of the patches require a +1 from all of people who contributed to the files otherwise will be legally in trouble (we can't just change license of a file)
Mon, Mar 4
Thu, Feb 21
Tue, Feb 19
Sendmail integration could perhaps be tested on the beta cluster, but it would need manual patching.
Moving to backlog, since we are waiting for feedback from the RFC's author.
Here are a few ideas I have:
- provide a checklist for "when should I file an RFC"
- provide a checklist for "what should be in an RFC document"
- consider a last call with no feedback from outside TechCom failed. Positive feedback would be required for an RFC to be approved. This ensures that we solicit input from relevant stakeholders.
- make explicit that it is TechCom's job to solicit input from relevant stakeholders. Presently, we usually just hope that relevant people would read the radar email and react.
There is also the change that Marko proposed: require the RFC to be on phabricator, with the option to reference wiki pages; and require teh RFC discussion to be on phabricator, and discourage on-wiki discussion once discussion on phab has started.
I propose that getID() return null instead of throwing a NameTableAccessException
Mon, Feb 18
Sun, Feb 17
@Aklapper As far as I understand, the ultimate authority on who should have access to which of our repos is the CTO. Relevant angles on the issue can probably be provided by community engagement, legal, and HR. No idea what the best venue for discussion is, sorry...
Feb 15 2019
All usages in core are gone. Now we should remove usages in extensions, at least in the ones WMF maintains. Dow we want to have a separate ticket for that? The current task description doesn't call for usages to be removed.
Feb 14 2019
@Smalyshev My understanding (which may be dated or incomplete) is this: there would be no PHP rendering, JS rendering would need to happen either in the browser on on the server. If the server supports SSR (e.g. for Wikimedia projects), you can read with a non-JS browser. If the server does not support SSR (e.g. on shared hosting), then you need a JS enabled browser to read.
Feb 13 2019
@daniel, could you elaborate? I would like to create a sub-task, but I want to make sure that it's not my interpretation.
Where can I find the sonarquebe interface?
For the record, I'm currently evaluating sonograph (a desktop code analysis tool).
@daniel: sorry, I don't see how/why this should go on the releng-kanban board?