Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Proposal: Special:SiteChanges for automatic deployment info

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


erik at wikimedia

May 2, 2012, 8:04 PM

Post #1 of 5 (136 views)
Permalink
Proposal: Special:SiteChanges for automatic deployment info

In the Wikimedia wikis, right now, we succeed to a varied degree at
letting communities know about deployments that affect them. We're
definitely getting better, and the 1.20wmf1 page is an example of
release notes done well:

http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1
http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1/overview

A concise summary with translations in multiple languages, followed by
a detailed list compiled from manually collected and curated commit
summaries. Nifty. And so much work that it's unlikely to be
sustainable. Indeed with wmf2 we're already taking shortcuts:

http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf2

No translations, no overview, less curation. And let's keep in mind
that this covers only the "regular two week cycle" deployment -- major
changes deployed between cycles aren't covered in either of those
summaries.

So how can we do better? I'd posit that it should be impossible to
deploy code without leaving an exposed audit trail generated from
commit messages, which can in turn be expanded by any interested
volunteer into a human-readable and translated summary.

I'd suggest exposing this information to a special page directly in
the relevant wiki, say "Special:SiteChanges". This special page would
show an automatically generated summary like so:

<example>
== Wednesday May 2, 19:03 ==
(2 hours ago)

'''[[mw:WMF deployments/345|Write or translate a deployment summary]]'''

Deployment 345 completed. The following changes are now running on this wiki.

=== In core ===

* ca7eb5c - Removed intval for undelete reason in API - ''committed by
Petr Onderka''
* 5813680 - Few documentation/type hint updates - ''committed by Reedy''
* e22a369 - Prevent sidebar links from jumping on page load -
''committed by Trevor Parscal'
...

=== In extension FlaggedRevs ===

* ce146dc - Fixing up LSB related stuff.. Some code duplication, but
meh for the moment (yay for us using static classes for hooks)

=== In extension DynamicPageList ===

..

== Tuesday, May 1, 15:01 ==
(1 day ago)

...
</example>

I leave it up to your imagination whether the summary would be
generated from the git repo the wiki resides in (in combination with a
deployment log), or pulled from MediaWiki.org, some combination
thereof, or some other implementation strategy. Suffice it to say that
we'd ideally want to:

* Ensure that the process of recording this information is an
automated part of deploying code updates
* Filter extensions from the Special:SiteChanges summary that are not
actually activated
* Notice when new extensions are activated that were not active in a
previous state
* Enable anyone to write deployment summaries on MediaWiki.org
* Enable anyone to translate those summaries
* Load an existing summary in the correct language on Special:SiteChanges

In the magical database backed configuration future,
Special:SiteChanges might also be able to list out config changes, but
that seems far fetched right now

In the equally magical "notifications for everything" future, users
would be able to opt into getting notified whenever a deployment
occurs.

But keeping it at a base level of functionality, does this seem like a
feasible and desirable change? Like I said, I worry about our ability
to keep up without automating this whole process, so IMO it would be
good to incrementally start building out this functionality. Otherwise
we're constantly fighting an uphill battle to ensure information gets
disseminated in a consistent fashion. But it's possible I'm
overlooking major issues that would make this too difficult to be
worthwhile.

All best,
Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tfinc at wikimedia

May 2, 2012, 8:13 PM

Post #2 of 5 (135 views)
Permalink
Re: Proposal: Special:SiteChanges for automatic deployment info [In reply to]

As part of the pre flight steps the mobile team generates a list of
gerrit changes that have gone into the deployment branch. We then
throw it on a wiki page so that its much easier to trace back what
changed. Our current list is here

http://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments

Formatting aside its become really useful to know exactly what's going
out without having to hound each developer about their changes.

This combined with Special:SiteChanges would be great in the glorious future.

--tomasz

On Wed, May 2, 2012 at 8:04 PM, Erik Moeller <erik [at] wikimedia> wrote:
> In the Wikimedia wikis, right now, we succeed to a varied degree at
> letting communities know about deployments that affect them. We're
> definitely getting better, and the 1.20wmf1 page is an example of
> release notes done well:
>
> http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1
> http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1/overview
>
> A concise summary with translations in multiple languages, followed by
> a detailed list compiled from manually collected and curated commit
> summaries. Nifty. And so much work that it's unlikely to be
> sustainable. Indeed with wmf2 we're already taking shortcuts:
>
> http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf2
>
> No translations, no overview, less curation. And let's keep in mind
> that this covers only the "regular two week cycle" deployment -- major
> changes deployed between cycles aren't covered in either of those
> summaries.
>
> So how can we do better? I'd posit that it should be impossible to
> deploy code without leaving an exposed audit trail generated from
> commit messages, which can in turn be expanded by any interested
> volunteer into a human-readable and translated summary.
>
> I'd suggest exposing this information to a special page directly in
> the relevant wiki, say "Special:SiteChanges". This special page would
> show an automatically generated summary like so:
>
> <example>
> == Wednesday May 2, 19:03 ==
> (2 hours ago)
>
> '''[[mw:WMF deployments/345|Write or translate a deployment summary]]'''
>
> Deployment 345 completed. The following changes are now running on this wiki.
>
> === In core ===
>
> * ca7eb5c - Removed intval for undelete reason in API - ''committed by
> Petr Onderka''
> * 5813680 - Few documentation/type hint updates - ''committed by Reedy''
> * e22a369 - Prevent sidebar links from jumping on page load -
> ''committed by Trevor Parscal'
> ...
>
> === In extension FlaggedRevs ===
>
> * ce146dc - Fixing up LSB related stuff.. Some code duplication, but
> meh for the moment (yay for us using static classes for hooks)
>
> === In extension DynamicPageList ===
>
> ..
>
> == Tuesday, May 1, 15:01 ==
> (1 day ago)
>
> ...
> </example>
>
> I leave it up to your imagination whether the summary would be
> generated from the git repo the wiki resides in (in combination with a
> deployment log), or pulled from MediaWiki.org,  some combination
> thereof, or some other implementation strategy. Suffice it to say that
> we'd ideally want to:
>
> * Ensure that the process of recording this information is an
> automated part of deploying code updates
> * Filter extensions from the Special:SiteChanges summary that are not
> actually activated
> * Notice when new extensions are activated that were not active in a
> previous state
> * Enable anyone to write deployment summaries on MediaWiki.org
> * Enable anyone to translate those summaries
> * Load an existing summary in the correct language on Special:SiteChanges
>
> In the magical database backed configuration future,
> Special:SiteChanges might also be able to list out config changes, but
> that seems far fetched right now
>
> In the equally magical "notifications for everything" future, users
> would be able to opt into getting notified whenever a deployment
> occurs.
>
> But keeping it at a base level of functionality, does this seem like a
> feasible and desirable change? Like I said, I worry about our ability
> to keep up without automating this whole process, so IMO it would be
> good to incrementally start building out this functionality. Otherwise
> we're constantly fighting an uphill battle to ensure information gets
> disseminated in a consistent fashion. But it's possible I'm
> overlooking major issues that would make this too difficult to be
> worthwhile.
>
> All best,
> Erik
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


strainu10 at gmail

May 3, 2012, 8:18 AM

Post #3 of 5 (127 views)
Permalink
Re: Proposal: Special:SiteChanges for automatic deployment info [In reply to]

2012/5/3 Erik Moeller <erik [at] wikimedia>:
> So how can we do better? I'd posit that it should be impossible to
> deploy code without leaving an exposed audit trail generated from
> commit messages, which can in turn be expanded by any interested
> volunteer into a human-readable and translated summary.
>
> I'd suggest exposing this information to a special page directly in
> the relevant wiki, say "Special:SiteChanges". This special page would
> show an automatically generated summary like so:

Yes, yes, please. :D This would be a big step forward.

Strainu

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


alolita.sharma at gmail

May 3, 2012, 10:46 PM

Post #4 of 5 (128 views)
Permalink
Re: Proposal: Special:SiteChanges for automatic deployment info [In reply to]

> This combined with Special:SiteChanges would be great in the glorious
future.

+1. It would indeed be a good step in the right direction.

Alolita


On Thu, May 3, 2012 at 8:18 AM, Strainu <strainu10 [at] gmail> wrote:

> 2012/5/3 Erik Moeller <erik [at] wikimedia>:
> > So how can we do better? I'd posit that it should be impossible to
> > deploy code without leaving an exposed audit trail generated from
> > commit messages, which can in turn be expanded by any interested
> > volunteer into a human-readable and translated summary.
> >
> > I'd suggest exposing this information to a special page directly in
> > the relevant wiki, say "Special:SiteChanges". This special page would
> > show an automatically generated summary like so:
>
> Yes, yes, please. :D This would be a big step forward.
>
> Strainu
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


helder.wiki at gmail

May 5, 2012, 6:19 AM

Post #5 of 5 (125 views)
Permalink
Re: Proposal: Special:SiteChanges for automatic deployment info [In reply to]

On Thu, May 3, 2012 at 12:04 AM, Erik Moeller <erik [at] wikimedia> wrote:
> I'd suggest exposing this information to a special page directly in
> the relevant wiki, say "Special:SiteChanges".
+1

> In the magical database backed configuration future,
> Special:SiteChanges might also be able to list out config changes, but
> that seems far fetched right now

On Portuguese Wikibooks we kept a history of configuration changes
which affected our project:
https://pt.wikibooks.org/wiki/Wikilivros:Histórico_de_configurações?uselang=en
If we could have some consistent way to tag bugzilla tickets which are
related to a given wiki (is it possible to add new fields for
project/lang?), then a table like that could be generated by a script
eliminating the need to do manual updates. Such a script would likely
use bugzilla API as in
https://en.wikipedia.org/wiki/MediaWiki:Gadget-BugStatusUpdate.js
(which works on pages where
https://en.wikipedia.org/wiki/Template:Tracked
is used).

Best regards,
Helder

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.