Happy New Year everybody -- we survived 2011 and have another wacky fun year of MediaWiki goodness to look forward to in 2012!
As we roll over our calendars, let's not forget it's also getting towards time to roll out another MediaWiki release. 1.19's seen a lot of refactoring goodness, bug fixes, and improvements; we need to make sure we can get those improvements out to the public.
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.
The combinations of review, testing, and actual deployments are important parts of our quality control system; we know from past experience that long waits between deployments have lead to poorly-tested code getting pushed out long after they've fallen out of our collective memory, making bugs newly discovered in them harder to find.
I believe we've got some general plans to hit deployment in February; if we hit code slush this week or so that gives some time for everybody to catch up on review, do more thorough testing and -- perhaps most importantly of all -- make sure we have good documentation on what's changed and what needs to be tested and tried out by real humans!
Note that I'm recommending a slush/freeze on trunk rather than simply branching and doing review on the release branch because that's been hard to manage in the past. I think we really need to concentrate on release polish, especially making sure that we don't have unexpected regressions and that people know what to expect has changed in the user interface and in behavior. Even "small" features like the image rotation changes we landed in 1.18 can have surprising consequences, and need to be clearly on peoples' radar before they're irrevocable.
-- brion vibber (brion @ pobox.com / bvibber @ wikimedia.org)
On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber bvibber@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 believe we've got some general plans to hit deployment in February; if we hit code slush this week or so that gives some time for everybody to catch up on review, do more thorough testing and -- perhaps most importantly of all -- make sure we have good documentation on what's changed and what needs to be tested and tried out by real humans!
Sounds good. Want to say Friday's the date to be "feature complete" to give people the rest of this week?
-Chad
Chad innocentkiller@gmail.com writes:
On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber bvibber@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.
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 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.
On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibberbvibber@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.
Can someone have a look at bug 25697, which is a very minor, easy patch? I hope to get this one in before 1.19, to go along with the new diff look.
On Tue, Jan 3, 2012 at 2:05 AM, Erwin Dokter erwin@darcoury.nl wrote:
Can someone have a look at bug 25697, which is a very minor, easy patch? I hope to get this one in before 1.19, to go along with the new diff look.
Done.
Roan
On 01/02/2012 08:49 AM, Chad wrote:
On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber bvibber@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 believe we've got some general plans to hit deployment in February; if we hit code slush this week or so that gives some time for everybody to catch up on review, do more thorough testing and -- perhaps most importantly of all -- make sure we have good documentation on what's changed and what needs to be tested and tried out by real humans!
Sounds good. Want to say Friday's the date to be "feature complete" to give people the rest of this week?
-Chad
Questions about today's freeze (from Niklas, Roan, & me in IRC):
on what -- all of trunk? core? wmf extensions? So does that mean you have to stop adding features when Friday starts, or ends? i.e. is Friday the first day of the frozen state, or the last day of the non-frozen state? Are we enforcing this in any way within SVN, or are we just agreeing to quickly revert any new features or refactoring commits that come in between now and [date]?
On Fri, Jan 6, 2012 at 9:38 AM, Sumana Harihareswara sumanah@wikimedia.org wrote:
Questions about today's freeze (from Niklas, Roan, & me in IRC):
on what -- all of trunk? core? wmf extensions?
Definitely core. Probably should apply to wmf-deployed extensions too. I think non-deployed extensions can continue doing what they're doing.
So does that mean you have to stop adding features when Friday starts, or ends? i.e. is Friday the first day of the frozen state, or the last day of the non-frozen state?
Let's give until midnight UTC, end of Friday.
Are we enforcing this in any way within SVN, or are we just agreeing to quickly revert any new features or refactoring commits that come in between now and [date]?
No changes to access -- there's still legit reasons to commit things such as followups, regression fixes and the like.
Remember everybody: we're calling this a "slush" and not an actual "freeze." The idea is to at least try and get trunk feature-complete so we can make the push in CR.
-Chad
On Fri, Jan 6, 2012 at 9:44 AM, Chad innocentkiller@gmail.com wrote:
On Fri, Jan 6, 2012 at 9:38 AM, Sumana Harihareswara sumanah@wikimedia.org wrote:
Questions about today's freeze (from Niklas, Roan, & me in IRC):
on what -- all of trunk? core? wmf extensions?
Definitely core. Probably should apply to wmf-deployed extensions too. I think non-deployed extensions can continue doing what they're doing.
So does that mean you have to stop adding features when Friday starts, or ends? i.e. is Friday the first day of the frozen state, or the last day of the non-frozen state?
Let's give until midnight UTC, end of Friday.
Are we enforcing this in any way within SVN, or are we just agreeing to quickly revert any new features or refactoring commits that come in between now and [date]?
No changes to access -- there's still legit reasons to commit things such as followups, regression fixes and the like.
Remember everybody: we're calling this a "slush" and not an actual "freeze." The idea is to at least try and get trunk feature-complete so we can make the push in CR.
And it's now midnight UTC, pencils down everybody. If you were looking to break trunk with a huge refactor...well, you missed the deadline ;-)
-Chad
I'll still be doing some work on FileBackend like fixing jenkins, cleaning up the streamFile() function, copying the swift backend to /trunk, and tying up a fix loose ends and doing fixes next week. I think heavy stuff is pretty much out of the way.
-- View this message in context: http://wikimedia.7.n6.nabble.com/Rolling-towards-1-19-scheduling-a-code-free... Sent from the Wikipedia Developers mailing list archive at Nabble.com.
wikitech-l@lists.wikimedia.org