> Message: 4 > Date: Mon, 02 Jan 2012 18:07:17 -0500 > From: mhershber...@wikimedia.org (Mark A. Hershberger) > Subject: [Wikitech-l] Fixing bugs before deployment (was Re: Rolling > towards 1.19... scheduling a code freeze) > To: Wikimedia developers <wikitech-l@lists.wikimedia.org> > Message-ID: <87k45966vu.fsf...@spyke.nichework.com> > Content-Type: text/plain > > Chad <innocentkil...@gmail.com> writes: > > > On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber <bvib...@wikimedia.org> wrote: > >> I'd like us to plan for a code freeze on trunk -- at least a feature & > >> refactoring freeze -- starting within a few days to give us all a chance to > >> tidy up, catch up with code review, and prepare for deployments. > >> > > > > +1 > > I'm all for it! > > > Sounds good. Want to say Friday's the date to be "feature complete" to > > give people the rest of this week? > > Again, great idea. > > One thing I would like to do is make sure > https://www.mediawiki.org/wiki/MediaWiki_1.19 lists all user visible > changes. I almost said "all significant user visible changes", but then > someone might know of a user visible change, but not consider it > significant and neglect to put it in there.
I disagree having "all" visible changes listed would be useful. The majority of all changes result in some visible change (however minor). People who are interested in every change generally would already read the RELEASE-NOTES. If we make a list of changes of roughly the same scope as the release notes, it will probably have the same number of readers as the RELEASE-NOTES (Which isn't a whole lot when it comes to your average Wikimedia). Personally I liked the major feature summary we did for 1.18 on the Wiki page. It gave people just interested in "whats new", but not interested in minor differences that don't make a that much of a difference, something to look at. There's going to be a good portion of the user base who are only interested in the highlights. > > Starting next week, after the "feature complete" deadline that Chad has > proposed, I'd like to take a list of features to the different projects > and work them to try out the changes on a test deployment wiki. > > I'm trying to be more proactive about this than we have been in the > past, so that bugs like the now-infamous EXIF rotation problem > (https://bugzilla.wikimedia.org/31504) are spotted earlier and, > hopefully, dealt with *before* deployment. I doubt that the issue could have been dealt with before deployment. Most of us thought it was a fairly good idea, pre-release to the wilds of Wikimedia Commons. In my opinion, the main failures in dealing with that situation is that we didn't listen to the complaints when they happened (they were fairly immediate upon deploying 1.18 if i recall), but instead waited 2 months until someone decided to raise a fuss on foundation-l. With that said, it would be great if we could catch everything before deployment, but sometimes things will get through. > I need to start doing something similar with tool upgrades, too. If I > hadn't been content to simply nag Ops about deploying rsvg upgrades or > recompiling wikidiff2 then bugs like "rsvg on scaler does not support > styling the root element" (https://bugzilla.wikimedia.org/31122) and > "Excessive punctuation highlighting in wikidiff2" > (https://bugzilla.wikimedia.org/33331) might have been recognized > sooner. > > Mark. Some quick tests to make sure everything works ok should certainly be done during upgrades, but even still, some things will get through (For example the other rsvg bug - 33323 would be much harder to catch from quick tests, and even the rsvg bug would probably have many files that aren't visibly affected) A message on the commons village pump whenever rsvg is updated would be a good idea imho (since they are generally the folks who deal with svgs and should know if something potentially changed, and people like knowing when things change). At the end of the day though, unless you are planning to visually inspect 100 000 odd svg images and compare the before and after, I doubt you will catch all such bugs. Cheers, Bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
