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 <e...@wikimedia.org> 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@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
