Hello all,
I hope everyone is doing well.
On https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/, it was raised correctly that namespaceDupes.php would need to be ran.
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/ and https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 can mostly run with the train (expect the mediawiki config patch) but all require namespaceDupes to be ran and on https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 could do with being deployed as close together as possible to avoid inconsistently translated namespaces.
Would as mentioned SWAT be better for all 5 patches or should we let what can ride with the train and deploy the one config patch shortly after and run for both wikis in that window? or could we ask the train runners to do that?
Thanks, Samuel
Hi Samuel
On 20-05-18 09:57:54, RhinosF1 - wrote:
On https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/, it was raised correctly that namespaceDupes.php would need to be ran.
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/ and https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 can mostly run with the train (expect the mediawiki config patch) but all require namespaceDupes to be ran and on https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 could do with being deployed as close together as possible to avoid inconsistently translated namespaces.
Would as mentioned SWAT be better for all 5 patches or should we let what can ride with the train and deploy the one config patch shortly after and run for both wikis in that window? or could we ask the train runners to do that?
What you're describing sounds like it would be a good candidate for SWAT deployment. My reasoning is that (1) it is atypical to run maintenance scripts as part of the train and (2) there are no guarantees that a train won't rollback.
That is, backporting to a version that is stable ensures that we don't end up having rolled forward to all wikis, run the maintenance script, and then having to rollback due to an unrelated problem. Additionally, the log triage that follows a train window may mean that we can't guarantee a timely deploy of the configuration change following train.
To me, this feels safer/faster/easier as a SWAT deployment; even though this might make for a particularly long SWAT window.
Thanks! -- Tyler
I’m quite happy go with a SWAT deployment and I agree that it’s probably a lot safer.
My only concern with that is that between the 2 tasks it would be 5/6 patches in the SWAT window.
It would also be my first mediawiki core + extensions SWAT so are the patches safe to +2 during / just before SWAT or Should I get that done before?
Thanks, Samuel
On Mon, 18 May 2020 at 16:25, Tyler Cipriani tcipriani@wikimedia.org wrote:
Hi Samuel
On 20-05-18 09:57:54, RhinosF1 - wrote:
On https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/, it was raised correctly that namespaceDupes.php would need to be ran.
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/ and https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 can mostly run with the train (expect the mediawiki config patch) but all require namespaceDupes
to
be ran and on https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 could do with being deployed as close together as possible to avoid inconsistently translated namespaces.
Would as mentioned SWAT be better for all 5 patches or should we let what can ride with the train and deploy the one config patch shortly after and run for both wikis in that window? or could we ask the train runners to do that?
What you're describing sounds like it would be a good candidate for SWAT deployment. My reasoning is that (1) it is atypical to run maintenance scripts as part of the train and (2) there are no guarantees that a train won't rollback.
That is, backporting to a version that is stable ensures that we don't end up having rolled forward to all wikis, run the maintenance script, and then having to rollback due to an unrelated problem. Additionally, the log triage that follows a train window may mean that we can't guarantee a timely deploy of the configuration change following train.
To me, this feels safer/faster/easier as a SWAT deployment; even though this might make for a particularly long SWAT window.
Thanks! -- Tyler _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 20-05-18 16:32:59, RhinosF1 - wrote:
My only concern with that is that between the 2 tasks it would be 5/6 patches in the SWAT window.
Yes, this work looks like it will consume a whole window easily :(
It would also be my first mediawiki core + extensions SWAT so are the patches safe to +2 during / just before SWAT or Should I get that done before?
On process I think might work:
* Merge core changes to master early in the week you plan to SWAT (but after branch cut for the week) * Prepare cherry-picks to backport to current stable + branch to go out that week * Add cherry-picks to deploy window
It's likely this is more than 6 patches :\
Syncing with a SWATter prior to SWAT and ensuring that you pick a window with some time after it (should you need more time to deploy) OR making a special window on the deployment calendar[0] for this set of changes would be best.
-- Tyler
[0]: https://wikitech.wikimedia.org/wiki/Deployments
On Mon, 18 May 2020 at 16:25, Tyler Cipriani tcipriani@wikimedia.org wrote:
Hi Samuel
On 20-05-18 09:57:54, RhinosF1 - wrote:
On https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/, it was raised correctly that namespaceDupes.php would need to be ran.
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/ and https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 can mostly run with the train (expect the mediawiki config patch) but all require namespaceDupes
to
be ran and on https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 could do with being deployed as close together as possible to avoid inconsistently translated namespaces.
Would as mentioned SWAT be better for all 5 patches or should we let what can ride with the train and deploy the one config patch shortly after and run for both wikis in that window? or could we ask the train runners to do that?
What you're describing sounds like it would be a good candidate for SWAT deployment. My reasoning is that (1) it is atypical to run maintenance scripts as part of the train and (2) there are no guarantees that a train won't rollback.
That is, backporting to a version that is stable ensures that we don't end up having rolled forward to all wikis, run the maintenance script, and then having to rollback due to an unrelated problem. Additionally, the log triage that follows a train window may mean that we can't guarantee a timely deploy of the configuration change following train.
To me, this feels safer/faster/easier as a SWAT deployment; even though this might make for a particularly long SWAT window.
Thanks! -- Tyler _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Thanks, Samuel _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I would suggest a special window.
I normally do the late window so I can see if Catrope can come an hour early for one and we do it then.
Samuel
On Mon, 18 May 2020 at 20:48, Tyler Cipriani tcipriani@wikimedia.org wrote:
On 20-05-18 16:32:59, RhinosF1 - wrote:
My only concern with that is that between the 2 tasks it would be 5/6 patches in the SWAT window.
Yes, this work looks like it will consume a whole window easily :(
It would also be my first mediawiki core + extensions SWAT so are the patches safe to +2 during / just before SWAT or Should I get that done before?
On process I think might work:
- Merge core changes to master early in the week you plan to SWAT (but
after branch cut for the week)
- Prepare cherry-picks to backport to current stable + branch to go out
that week
- Add cherry-picks to deploy window
It's likely this is more than 6 patches :\
Syncing with a SWATter prior to SWAT and ensuring that you pick a window with some time after it (should you need more time to deploy) OR making a special window on the deployment calendar[0] for this set of changes would be best.
-- Tyler
On Mon, 18 May 2020 at 16:25, Tyler Cipriani tcipriani@wikimedia.org wrote:
Hi Samuel
On 20-05-18 09:57:54, RhinosF1 - wrote:
On https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/, it was raised correctly that namespaceDupes.php would need to be ran.
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/ and https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 can mostly run with
the
train (expect the mediawiki config patch) but all require
namespaceDupes
to
be ran and on https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 could
do
with being deployed as close together as possible to avoid inconsistently translated namespaces.
Would as mentioned SWAT be better for all 5 patches or should we let
what
can ride with the train and deploy the one config patch shortly after
and
run for both wikis in that window? or could we ask the train runners
to do
that?
What you're describing sounds like it would be a good candidate for SWAT deployment. My reasoning is that (1) it is atypical to run maintenance scripts as part of the train and (2) there are no guarantees that a train won't rollback.
That is, backporting to a version that is stable ensures that we don't end up having rolled forward to all wikis, run the maintenance script, and then having to rollback due to an unrelated problem. Additionally, the log triage that follows a train window may mean that we can't guarantee a timely deploy of the configuration change following train.
To me, this feels safer/faster/easier as a SWAT deployment; even though this might make for a particularly long SWAT window.
Thanks! -- Tyler _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Thanks, Samuel _______________________________________________ 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@lists.wikimedia.org