Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Alolita Sharma]

On Wed, Jun 15, 2011 at 2:42 AM, Tomasz Finc  wrote:
> We also need to figure out which things can afford to wait while we
> retool.  My understanding of the Features team work is that the 20%
> tax is unaccounted for in the current model.  I'll let Alolita speak
> to it, but I don't believe we've agreed to change any dates yet as a
> result of adding 20% time to the devs schedules.


This is certainly the case for anything mobile and special projects
(offline) related. Since its a fairly new team the majority of its
members are either part time contractors or are new and operating
mostly on their own; this gives us a good challenge of on boarding new
engineers for code review & deployment

In the Features team @WMF, we've been balancing our features development
workload to ensure code reviews are consistently happening for quite a while
now. Some of our team members such as Roan consistently dedicate a 20% or
higher percentage of their time for code reviews. Our full-time development
team is *tiny* (Trevor, NeilK being the only FT feature devs in SF). Their
contribution to code review has varied. Both Roan and Trevor have helped
tremendously in marathons for Release readiness (for 1.17 in recent times)
where Features development went on-hold for months to support clearing the
release backlog. Neil has helped on multimedia related code. The rest of
features devs are part time contractors and remote but have been enormously
participatory in making code review happen and getting bug quashed (Krinkle,
Werdna, AaronSchulz).

We're still in conversation about how to best support a constant 20% from
all foundation developers. The suggestion of 1 mandatory day a week for code
review has been made. This is tough to implement since features developers
are multiplexed across many projects and time zones. They have to ensure
they can meet their deliverable deadlines as well as support ~20% time for
code review. Trevor, Neil - please feel free to jump in and add your
thoughts on this.

To support constant code-review, contributors to MW (community and
foundation) have to work together long-term. I feel on-boarding of all new
developers to learn best code review and deployment practices is essential
to make that happen. On my request, Roan put together some excellent
documentation on best practices to deploy code
(http://wikitech.wikimedia.org/view/How_to_deploy_code).
This has helped features developers and hopefully new community contributors
to better understand the nuances of MW code deployment and develop software
keeping these review guidelines in mind. If there is more knowledge that can
be shared on this topic, please feel free to edit :-)

Internally i've watched/supported our engineers becoming more familiar
with our deployment system and i'm eager to have more who are
comfortable with this from both staff and the volunteer community.

Any and all new foundation developers (whether in features, fundraising or
mobile) have been "let loose" to do code reviews after many months of
practicing-by-doing peer reviews. Same for deployments.

For any community members who have suggestions or questions, please feel
free to ping me. I'm always on irc. I'm looking for more community
contributors who would like to get on-boarded for code review and be part of
the solution :-)

HTH.
Best,
Alolita


On Wed, Jun 15, 2011 at 2:42 AM, Tomasz Finc  wrote:

> > We also need to figure out which things can afford to wait while we
> > retool.  My understanding of the Features team work is that the 20%
> > tax is unaccounted for in the current model.  I'll let Alolita speak
> > to it, but I don't believe we've agreed to change any dates yet as a
> > result of adding 20% time to the devs schedules.
>
> This is certainly the case for anything mobile and special projects
> (offline) related. Since its a fairly new team the majority of its
> members are either part time contractors or are new and operating
> mostly on their own; this gives us a good challenge of on boarding new
> engineers for code review & deployment
>
> I'm really eager to fix the latter. We currently have good
> documentation from Roan and others at
> http://wikitech.wikimedia.org/view/How_to_deploy_code and we'll have a
> much better eco system when het deploy is out. For those of you that
> actively deploy code .. do we have enough documentation for someone
> new to  learn the system? If not .. what key pieces are missing? Feel
> free to grab me on irc if you want to dive into this deeply or if your
> just curious.
>
> Internally i've watched/supported our engineers becoming more familiar
> with our deployment system and i'm eager to have more who are
> comfortable with this from both staff and the volunteer community.
>
> --tomasz
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Platonides]

Tomasz Finc wrote:
> I'm really eager to fix the latter. We currently have good
> documentation from Roan and others at
> http://wikitech.wikimedia.org/view/How_to_deploy_code and we'll have a
> much better eco system when het deploy is out. For those of you that
> actively deploy code .. do we have enough documentation for someone
> new to  learn the system? If not .. what key pieces are missing? Feel
> free to grab me on irc if you want to dive into this deeply or if your
> just curious.
>
> Internally i've watched/supported our engineers becoming more familiar
> with our deployment system and i'm eager to have more who are
> comfortable with this from both staff and the volunteer community.
>
> --tomasz

I think it is as easy as knowing how to use scap and sync-file. I would 
consider some features that [[How_to_deploy_code]] covers, such as 
deployment of a new extensions as advanced.

The rest is mostly common sense: trusting the code that you are 
deploying, not making silly syntax errors*...

I would add a note about having to be around* after you make any 
changes, in case you broke something, and -for new scappers- to also 
have some senior developer available.

I think it is worth explaining the correct way to add a configuration 
setting or group. Those are changes done quite often (shell bugs), but 
can break the sites or expose a private wiki.

* This happens to everyone, it is probably the most common cause of 
breakdown (now sync-file runs php -l for you).
** For new people: that means at least being on #wikimedia-tech.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Tomasz Finc]

> We also need to figure out which things can afford to wait while we
> retool.  My understanding of the Features team work is that the 20%
> tax is unaccounted for in the current model.  I'll let Alolita speak
> to it, but I don't believe we've agreed to change any dates yet as a
> result of adding 20% time to the devs schedules.

This is certainly the case for anything mobile and special projects
(offline) related. Since its a fairly new team the majority of its
members are either part time contractors or are new and operating
mostly on their own; this gives us a good challenge of on boarding new
engineers for code review & deployment

I'm really eager to fix the latter. We currently have good
documentation from Roan and others at
http://wikitech.wikimedia.org/view/How_to_deploy_code and we'll have a
much better eco system when het deploy is out. For those of you that
actively deploy code .. do we have enough documentation for someone
new to  learn the system? If not .. what key pieces are missing? Feel
free to grab me on irc if you want to dive into this deeply or if your
just curious.

Internally i've watched/supported our engineers becoming more familiar
with our deployment system and i'm eager to have more who are
comfortable with this from both staff and the volunteer community.

--tomasz

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Rob Lanphier]

On Mon, Jun 13, 2011 at 4:19 PM, Brion Vibber  wrote:
> When we were prepping 1.17 for deployment the theory seemed to be that it'd
> be out the door and *done* within a couple weeks and we'd be able to
> concentrate on 1.18 from there out and keep up with everything.

Part of the problem was that we weren't doing a good job of minding this list:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.17

That was my fault for not specifically tracking that, but it was
something that all of us who wanted to get 1.17 could have done.  By
"tracking", I mean looking out for superfluous additions to that list,
and nixing them.  Also, making sure that anything on that list was
truly ready to go (e.g. proper release notes already written, reviews
done, etc).

We also found that people would attach bugs to the 1.17 release
blocker just to get our attention.  Even bugs that were clearly
deployment-only got attached from time to time.

For 1.18, I've at least added a new "pre-release preparation" section
to this doc:
http://www.mediawiki.org/wiki/Release_checklist#Pre-release_preparation

Anyone interested in helping the 1.18 release process go faster can
make sure that that list is correct, and by pitching in on anything
necessary to get through that list more quickly.

There's a number of things that I'll be talking to folks on my team
about in order to make go smoother for 1.18, and there's a number of
things that I'm planning to do differently myself.  However, there's a
wider commitment that's needed to make the 1.18 cycle significantly
different from the 1.17 cycle.

> Give us a deployment date for 1.18 and make it a top priority for
> engineering.
>
> Give us a release date for 1.18 and make it a top priority for engineering.

If releasing "1.18" becomes a top priority over anything that actually
goes into it, then committing to a date is easy.  We'll just rename
"1.17" to "1.18" and call it good.  :-)

If, however, people care about the actual features that go in, and
actually care about getting through the review queue and all of that,
we need to establish how quickly we can do that in the first place.
The 1.17 deployment only provides us with so much historical guidance.
 Trevor and Roan were pretty motivated to get Resource Loader out the
door, and busted tail to get through the review queue much more
quickly than we might have otherwise done.  They sprinted through a
big backlog, and when they were done, they were ready to move on to
other stuff (and there was plenty more the org wanted them to do).  We
probably won't have the same level of dedication to the problem that
they had last go around.

We also need to figure out which things can afford to wait while we
retool.  My understanding of the Features team work is that the 20%
tax is unaccounted for in the current model.  I'll let Alolita speak
to it, but I don't believe we've agreed to change any dates yet as a
result of adding 20% time to the devs schedules.

Even when we get 20% of everyone's time, that will help, but we're
going to have to use that time more effectively than we have. I think
it's more than just telling everyone to work harder.  I think there's
a fundamental problem with the way we accept and review code.  Brion,
you and I have spoken about this, but I don't think we've gotten to
the heart of the matter.  It's pretty clear that for most reviewers,
they just haven't hit the sweet spot of speed necessary to deal with
the velocity of commits we're getting, and completeness necessary for
reviewers to feel good having their names associated with an "ok" mark
(or comfortable reverting, or whatever).  That may be a matter of
training, it may be other things, but we've gotta figure that problem,
too.  We've proven we can sprint fast enough to make a dent in the
backlog (e.g. late 2010), but we can't sustain that pace.

Also, "releasing 1.18" isn't my top priority.  Het Deploy[1] is higher
on the list.  I'm not willing to cut Het Deploy from this release just
to make a date.  We are going to have a more sane way of doing
deployments before we deploy another major version of MediaWiki.  I'm
not budging on that one.

We can set a goal, but in my experience, setting a date that engineers
don't actually believe in is counterproductive.  I'm personally not
willing to set a date until we establish that we can go *a week* at
the pace necessary to achieve anything like the goals we set out (e.g.
July).  At this point, I can set a date, but you probably won't like
it (probably September-ish).  I'd rather we show better results on the
code review process first, and only then would I venture a more
optimistic target.  I wouldn't set the date without at least making
sure that it passes the smell test with some key people here.

Anyway, I don't want to be down on the idea that we should release
more often.  It should be possible for us to get the queue down, and
keep it down with a concerted effort, and I think the concerted effort
will be worth it.

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Mark A. Hershberger]

Brion Vibber  writes:

> Give us a deployment date for 1.18 and make it a top priority for
> engineering.
>
> Give us a release date for 1.18 and make it a top priority for
> engineering.

+1000 for “top priority for engineering”

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Brion Vibber]

On Mon, Jun 13, 2011 at 4:00 PM, Rob Lanphier  wrote:

> On Tue, Jun 7, 2011 at 11:57 PM, Ashar Voultoiz 
> wrote:
> > This is a linear progression, the revision become harder and harder to
> > review since, with time, most of the easy stuff got reviewed :-) Make it
> > a long tail maybe ? :-)
>
> Well, kinda moot at this point.  Unfortunately, we're not even beating
> a linear progression to a July 15 target:
>

There's been only one data point so far (last tuesday)... so it might be
tough to extrapolate yet. :)

I'm not making a big fuss about this until 1.17 is done, since I know,
> for example, that Tim has been doing the last bits of detail work
> necessary for a 1.17 tarball release, so he hasn't been able to make
> as much of a dent as others have been available for.  Still, we're
> going to need to go faster than this to expect a deploy before August.
>  Thoughts on how to accelerate?
>

When we were prepping 1.17 for deployment the theory seemed to be that it'd
be out the door and *done* within a couple weeks and we'd be able to
concentrate on 1.18 from there out and keep up with everything.

That was several months ago... we still haven't released 1.17, there seems
to be little or no commitment to a deployment or release schedule on 1.18,
and what review has happened between 1.17 and 1.18 has been totally
unorganized ad-hoc opt-in poking.

If we're working on the assumption that 1.17 being unreleased is slowing
down 1.18 work, then what are we doing sitting around?

Get that 1.17 tarball OUT and move on. It's been "any day now" for like
three months...

Give us a deployment date for 1.18 and make it a top priority for
engineering.

Give us a release date for 1.18 and make it a top priority for engineering.

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Rob Lanphier]

On Tue, Jun 7, 2011 at 11:57 PM, Ashar Voultoiz  wrote:
> On 07/06/11 23:27, Rob Lanphier wrote:
> > http://toolserver.org/~robla/crstats/crstats.118all.html
> >
> > And here's the goals I posted on Friday:
> > 2011-Jun-03     1594
> > 2011-Jun-10     1329
> > 2011-Jun-17     1064
> > 2011-Jun-24     799
> > 2011-Jul-01     534
> > 2011-Jul-08     269
> > 2011-Jul-15     4
>
> This is a linear progression, the revision become harder and harder to
> review since, with time, most of the easy stuff got reviewed :-) Make it
> a long tail maybe ? :-)

Well, kinda moot at this point.  Unfortunately, we're not even beating
a linear progression to a July 15 target:
2011-Jun-03  1594
2011-Jun-10  1435
2011-Jun-13  1427

Extrapolating from just the June 3 to June 10 review rates (two
points!  woohoo, it's a trend!), here's the rate:
2011-Jun-03 1594
2011-Jun-10 1435
2011-Jun-17 1276
2011-Jun-24 1117
2011-Jul-01 958
2011-Jul-08 799
2011-Jul-15 640
2011-Jul-22 481
2011-Jul-29 322
2011-Aug-05 163
2011-Aug-12 4

Not all of the news is bad.  Most of the progress in the past week was
in trunk, which is where the hardest review work is:
2011-Jun-03  670
2011-Jun-10  529

A linear projection there has us finishing up July 5.  So, really,
it's a matter of making sure we apply the same focus to extensions
that we're applying to core, as well as keeping up with core reviews.

Ashar, you're point isn't lost, though.  We know from past history
that we don't tend to review at a linear rate when we buckle down.
For example, here's the 1.17 cycle:
http://toolserver.org/~robla/crstats/crstats.117all.html

We could probably figure out which flavor of curve fits the
December-February portion of that graph, and probably get something
with better predictive power.  I'll admit to being too lazy +
mathematically disinclined to work out which one it is, but I'd be
happy if someone wanted to take a shot at it.  The raw data:
http://toolserver.org/~robla/crstats/data/1.17all/crstatsdata.js

The depressing projection that's likely to come of that is that
instead of August, we're probably looking at October or later at our
current rate of review.

I'm not making a big fuss about this until 1.17 is done, since I know,
for example, that Tim has been doing the last bits of detail work
necessary for a 1.17 tarball release, so he hasn't been able to make
as much of a dent as others have been available for.  Still, we're
going to need to go faster than this to expect a deploy before August.
 Thoughts on how to accelerate?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Brion Vibber]

That reminds me I should merge docs to the roadmap page! For now those live
at http://www.mediawiki.org/wiki/Future

-- brion
On Jun 8, 2011 4:13 AM, "Roan Kattouw"  wrote:
> On Wed, Jun 8, 2011 at 9:30 AM, Dmitriy Sintsov 
wrote:
>> I wish there was WYSIWYG editor in the roadmap. It can be anything:
>> Wikia RTE, Magnus Manske visual editor, or anything else - however,
>> supporting creating content from scratch (not just editing over already
>> existing article), working with built-in parser out of box, and no
>> glitches like FCKeditor has. And being an WMF extension with all the
>> advantages of continuous integration (core / extension compatibility).
>> Dmitriy
>>
> There are people at WMF working on a visual editor. It's not on the
> roadmap page, but that doesn't mean it's not being worked on :)
>
> Roan Kattouw (Catrope)
>
> ___
> 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

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Roan Kattouw]

On Wed, Jun 8, 2011 at 9:30 AM, Dmitriy Sintsov  wrote:
> I wish there was WYSIWYG editor in the roadmap. It can be anything:
> Wikia RTE, Magnus Manske visual editor, or anything else - however,
> supporting creating content from scratch (not just editing over already
> existing article), working with built-in parser out of box, and no
> glitches like FCKeditor has. And being an WMF extension with all the
> advantages of continuous integration (core / extension compatibility).
> Dmitriy
>
There are people at WMF working on a visual editor. It's not on the
roadmap page, but that doesn't mean it's not being worked on :)

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Dmitriy Sintsov]

* Brion Vibber  [Tue, 7 Jun 2011 11:56:36 -0700]:
> Currently working (mostly backwards) to fill in the Code Review holes
> from
> before 1.18 branch point:
>
> 
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=87519&path=%2Ftrunk%2Fphase3
>
> Roadmap provisionally says July for 1.18 deployment:
> http://www.mediawiki.org/wiki/MediaWiki_roadmap
>
I wish there was WYSIWYG editor in the roadmap. It can be anything: 
Wikia RTE, Magnus Manske visual editor, or anything else - however, 
supporting creating content from scratch (not just editing over already 
existing article), working with built-in parser out of box, and no 
glitches like FCKeditor has. And being an WMF extension with all the 
advantages of continuous integration (core / extension compatibility).
Dmitriy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Ashar Voultoiz]

On 07/06/11 23:27, Rob Lanphier wrote:
> http://toolserver.org/~robla/crstats/crstats.118all.html
>
> And here's the goals I posted on Friday:
> 2011-Jun-03 1594
> 2011-Jun-10 1329
> 2011-Jun-17 1064
> 2011-Jun-24 799
> 2011-Jul-01 534
> 2011-Jul-08 269
> 2011-Jul-15 4

This is a linear progression, the revision become harder and harder to 
review since, with time, most of the easy stuff got reviewed :-) Make it 
a long tail maybe ? :-)

-- 
Ashar Voultoiz


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Ashar Voultoiz]

On 07/06/11 20:56, Brion Vibber wrote:
> Currently working (mostly backwards) to fill in the Code Review holes from
> before 1.18 branch point:

Since ci.tesla is almost stable since last week, I have switched to 
reviewing 1.18.

I might have added some bugs in the 1.17 backport queue. Is there any 
policy to backport a revision to 1.17?

-- 
Ashar Voultoiz


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Rob Lanphier]

On Tue, Jun 7, 2011 at 12:57 PM, Chad  wrote:

> On Tue, Jun 7, 2011 at 2:56 PM, Brion Vibber  wrote:
> > Currently working (mostly backwards) to fill in the Code Review holes
> from
> > before 1.18 branch point:
> >
> >
> http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=87519&path=%2Ftrunk%2Fphase3
> >
> > Roadmap provisionally says July for 1.18 deployment:
> > http://www.mediawiki.org/wiki/MediaWiki_roadmap
> >
>
> I've got a meeting, but after that I'll join in. Another CR sprint will
> do me good after all the PHPUnit I've been mucking about with.
>
> Anyone else? Let's congregate on IRC and try to make the graph
> drop today :)


Cool!  For those keeping score at home, here's the most important graph:
http://toolserver.org/~robla/crstats/crstats.118all.html

And here's the goals I posted on Friday:
2011-Jun-03 1594
2011-Jun-10 1329
2011-Jun-17 1064
2011-Jun-24 799
2011-Jul-01 534
2011-Jul-08 269
2011-Jul-15 4

...and here's where we were at as of the last snapshot: 1528.  That number
is all revs (including extensions) waiting on review before r87529.

The good news here is that core got most of the love over the past week:
http://toolserver.org/~robla/crstats/crstats.118phase3.html

That's a drop from 670 on June 3 to 611 on June 7 (midnight UTC).  Those are
the hardest ones to get through, so it's good that the progress we made was
mostly there.  Still, make sure the extensions are getting love too (even if
it means marking "deferred" on extensions that aren't slated for WMF
deployment).

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Krinkle]

Brion Vibber wrote:

> On Tue, Jun 7, 2011 at 12:58 PM, Roan Kattouw  
> wrote:
>
>> On Tue, Jun 7, 2011 at 8:56 PM, Brion Vibber  wrote:
>>> Currently working (mostly backwards) to fill in the Code Review  
>>> holes
>> from
>>> before 1.18 branch point:
>>>
>>>
>> http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=87519&path=%2Ftrunk%2Fphase3
>>>
>> Yay!
>>
>> Did you see the Etherpad in which Mark Hershberger assigned certain
>> paths to certain people?
>>
>
> Etherpad's great for notes but less great as an ongoing assignment  
> space,
> such as say a wiki page that can be found by searching.
>
> -- brion

A wiki page does make sense for assignments. Anyway, here's the data
etherpad Roan referred to:

http://etherpad.wikimedia.org/CodeReviewSignup

A constantly changing overview of what's on-topic and rough todo-list,
(which Etherpad is more suited for)
http://etherpad.wikimedia.org/CodeReviewTracker


--
Krinkle


PS: Regarding search, a somewhat complete table of contents of wmftech
related pads is here: http://etherpad.wikimedia.org/WMF-TOC

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Brion Vibber]

On Tue, Jun 7, 2011 at 12:58 PM, Roan Kattouw wrote:

> On Tue, Jun 7, 2011 at 8:56 PM, Brion Vibber  wrote:
> > Currently working (mostly backwards) to fill in the Code Review holes
> from
> > before 1.18 branch point:
> >
> >
> http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=87519&path=%2Ftrunk%2Fphase3
> >
> Yay!
>
> Did you see the Etherpad in which Mark Hershberger assigned certain
> paths to certain people?
>

Etherpad's great for notes but less great as an ongoing assignment space,
such as say a wiki page that can be found by searching.

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Roan Kattouw]

On Tue, Jun 7, 2011 at 8:56 PM, Brion Vibber  wrote:
> Currently working (mostly backwards) to fill in the Code Review holes from
> before 1.18 branch point:
>
> http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=87519&path=%2Ftrunk%2Fphase3
>
Yay!

Did you see the Etherpad in which Mark Hershberger assigned certain
paths to certain people?

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Chad]

On Tue, Jun 7, 2011 at 2:56 PM, Brion Vibber  wrote:
> Currently working (mostly backwards) to fill in the Code Review holes from
> before 1.18 branch point:
>
> http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=87519&path=%2Ftrunk%2Fphase3
>
> Roadmap provisionally says July for 1.18 deployment:
> http://www.mediawiki.org/wiki/MediaWiki_roadmap
>

I've got a meeting, but after that I'll join in. Another CR sprint will
do me good after all the PHPUnit I've been mucking about with.

Anyone else? Let's congregate on IRC and try to make the graph
drop today :)

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code

[Brion Vibber]

Currently working (mostly backwards) to fill in the Code Review holes from
before 1.18 branch point:

http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=87519&path=%2Ftrunk%2Fphase3

Roadmap provisionally says July for 1.18 deployment:
http://www.mediawiki.org/wiki/MediaWiki_roadmap

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l