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

Mailing List Archive: Wikipedia: Wikitech

Rolling towards 1.19... scheduling a code freeze

 

 

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


bvibber at wikimedia

Jan 1, 2012, 9:49 AM

Post #1 of 6 (349 views)
Permalink
Rolling towards 1.19... scheduling a code freeze

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)
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Jan 2, 2012, 5:49 AM

Post #2 of 6 (334 views)
Permalink
Re: Rolling towards 1.19... scheduling a code freeze [In reply to]

On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber <bvibber [at] wikimedia> 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

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


sumanah at wikimedia

Jan 6, 2012, 6:38 AM

Post #3 of 6 (328 views)
Permalink
Re: Rolling towards 1.19... scheduling a code freeze [In reply to]

On 01/02/2012 08:49 AM, Chad wrote:
> On Sun, Jan 1, 2012 at 12:49 PM, Brion Vibber <bvibber [at] wikimedia> 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]?

--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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


innocentkiller at gmail

Jan 6, 2012, 6:44 AM

Post #4 of 6 (328 views)
Permalink
Re: Rolling towards 1.19... scheduling a code freeze [In reply to]

On Fri, Jan 6, 2012 at 9:38 AM, Sumana Harihareswara
<sumanah [at] wikimedia> 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

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


innocentkiller at gmail

Jan 6, 2012, 4:11 PM

Post #5 of 6 (329 views)
Permalink
Re: Rolling towards 1.19... scheduling a code freeze [In reply to]

On Fri, Jan 6, 2012 at 9:44 AM, Chad <innocentkiller [at] gmail> wrote:
> On Fri, Jan 6, 2012 at 9:38 AM, Sumana Harihareswara
> <sumanah [at] wikimedia> 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

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


aschulz4587 at gmail

Jan 6, 2012, 9:49 PM

Post #6 of 6 (333 views)
Permalink
Re: Rolling towards 1.19... scheduling a code freeze [In reply to]

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-freeze-tp2722998p3310386.html
Sent from the Wikipedia Developers mailing list archive at Nabble.com.

_______________________________________________
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.