Status of more regular code deployments

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Status of more regular code deployments

MZMcBride-2
Hi.

Is there a status update about more regular code deployments to Wikimedia
wikis? I know it's been discussed endlessly, but I was under the impression
that it was a real goal going forward. Is that still the case?

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

MZMcBride-2
MZMcBride wrote:
> Is there a status update about more regular code deployments to Wikimedia
> wikis? I know it's been discussed endlessly, but I was under the impression
> that it was a real goal going forward. Is that still the case?

Hmm, I guess not. Perhaps we'll soon see a return to the "before Wikimania"
meme (shortly followed by the "after the fundraiser" meme).

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Rob Lanphier-4
On Sun, May 29, 2011 at 9:15 AM, MZMcBride <[hidden email]> wrote:
> MZMcBride wrote:
>> Is there a status update about more regular code deployments to Wikimedia
>> wikis? I know it's been discussed endlessly, but I was under the impression
>> that it was a real goal going forward. Is that still the case?
>
> Hmm, I guess not. Perhaps we'll soon see a return to the "before Wikimania"
> meme (shortly followed by the "after the fundraiser" meme).

We updated the MediaWiki roadmap in Berlin:
http://www.mediawiki.org/wiki/MediaWiki_roadmap

The tl;dr version:
*  1.17 - May (we still might make it...we're very, very close)
*  1.18 - July, with tarball release in August
*  1.19 - October, with tarball release in November
*  1.20 - January 2012, with tarball release in February

That's a very rough outline, and I put confidence numbers in there
(e.g. 30% for 1.18) to emphasize that these are pretty rough
projections.

As stated above:  1.17 is very, very close to being complete, and the
1.18 review queue is starting to look much better.  Compare:
1.18:  http://toolserver.org/~robla/crstats/crstats.118all.html
1.17:  http://toolserver.org/~robla/crstats/crstats.117all.html

As you can see, there's still a lot of review to do for a 1.18
release, but it's not as out of control as 1.17 was.  A 1.18
deployment in July is plausible, though comparing the graphs and
mapping them to our actual 1.17 deployment, we're probably looking at
August.

Rob

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

MZMcBride-2
Rob Lanphier wrote:
> We updated the MediaWiki roadmap in Berlin:
> http://www.mediawiki.org/wiki/MediaWiki_roadmap
>
> The tl;dr version:
> *  1.17 - May (we still might make it...we're very, very close)
> *  1.18 - July, with tarball release in August
> *  1.19 - October, with tarball release in November
> *  1.20 - January 2012, with tarball release in February

Thank you for replying and thank you for updating the roadmap.

I think the main question in my message got lost, though. When I said "more
regular" code deployments, I meant less than or equal to a month. Perhaps
even weekly.

At one point or another, it was a goal to get back to that kind of more
regular code deployments to the live sites (particularly given the issues
that resulted from the large 1.17 upgrade). Is that still a goal?

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Trevor Parscal-2
Based on the schedule given, I would deduct that it's no longer our goal to
release as often as we may have once believed was ideal - and sometimes even
achieved.

There's been tons of discussion about what is an ideal release schedule for
us (probably literally if you printed it out at 12pt on standard copy
paper). At this point I think we are balancing between fighting the bad
habits that got us into the 1.17 rut, and trying to give our engineering
team enough time to do significant work (rather than spending 1 day a week
pushing code).

It's my expectation that this will always fluctuate, never reach anything
resembling a stable rhythm, and that whether that's good or bad, that is and
will continue to be reality.

If you feel that releasing frequently is important, as a non-reviewer
without shell access and no official power to release anything, this must be
frustrating. Maybe we could instead of bickering about when code should be
released, come up with and support new roles that volunteers can take on
that would accelerate the code review and release process.

Right now, volunteers can effectively slow it by committing code - not that
that's in any way a bad thing of course, volunteer code contribution is
incredibly valuable. But if volunteers can also help in other ways to push
that code along the pipeline in productive ways, that would likely take much
of the frustration out of this situation for everyone.

Any ideas?

- Trevor

On Tue, May 31, 2011 at 12:12 AM, MZMcBride <[hidden email]> wrote:

> Rob Lanphier wrote:
> > We updated the MediaWiki roadmap in Berlin:
> > http://www.mediawiki.org/wiki/MediaWiki_roadmap
> >
> > The tl;dr version:
> > *  1.17 - May (we still might make it...we're very, very close)
> > *  1.18 - July, with tarball release in August
> > *  1.19 - October, with tarball release in November
> > *  1.20 - January 2012, with tarball release in February
>
> Thank you for replying and thank you for updating the roadmap.
>
> I think the main question in my message got lost, though. When I said "more
> regular" code deployments, I meant less than or equal to a month. Perhaps
> even weekly.
>
> At one point or another, it was a goal to get back to that kind of more
> regular code deployments to the live sites (particularly given the issues
> that resulted from the large 1.17 upgrade). Is that still a goal?
>
> MZMcBride
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Neil Kandalgaonkar
On 5/31/11 10:03 AM, Trevor Parscal wrote:

> It's my expectation that this will always fluctuate, never reach anything
> resembling a stable rhythm, and that whether that's good or bad, that is and
> will continue to be reality.

I understand how you feel, but that is unnecessarily pessimistic.

A lot of other projects of equal or greater size and complexity manage
to release much more frequently. And there are just as many voices
tugging in different directions.

So we know that the solution exists. We just have not taken the right
steps to achieve that solution.


> Any ideas?

Well, AFAIK our bottleneck is reviewing. I'm unaware of any concrete
steps that have been taken to get a scalable reviewing system happening.
I'm not saying nothing's been done, it's just that I've never seen
anyone say "okay, here's the plan".

Maybe this sounds like I'm volunteering for it, and I guess I would, but
it seems to me that the current users who can push have to come up with
a system that *they* trust. Whatever bright idea I have is going to go
down in flames if Tim et al. aren't fully committed to it and adequate
sacrifices are made in other areas to adjust to a new system. If pushing
more frequently isn't a priority for these users (or they are unable to
find the time to fix the current system) then I don't know what to do
either.

Are we all in deadlock or something? Are the users who can push waiting
from some proposals/work from the rest of the community?

--
Neil Kandalgaonkar (   <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Neil Kandalgaonkar
Followup -- I've conflated "pushing" and "releasing" in my post, but
anyway I believe it's mostly the same circle of users who do both.


On 5/31/11 10:35 AM, Neil Kandalgaonkar wrote:

> On 5/31/11 10:03 AM, Trevor Parscal wrote:
>
>> It's my expectation that this will always fluctuate, never reach anything
>> resembling a stable rhythm, and that whether that's good or bad, that
>> is and
>> will continue to be reality.
>
> I understand how you feel, but that is unnecessarily pessimistic.
>
> A lot of other projects of equal or greater size and complexity manage
> to release much more frequently. And there are just as many voices
> tugging in different directions.
>
> So we know that the solution exists. We just have not taken the right
> steps to achieve that solution.
>
>
>> Any ideas?
>
> Well, AFAIK our bottleneck is reviewing. I'm unaware of any concrete
> steps that have been taken to get a scalable reviewing system happening.
> I'm not saying nothing's been done, it's just that I've never seen
> anyone say "okay, here's the plan".
>
> Maybe this sounds like I'm volunteering for it, and I guess I would, but
> it seems to me that the current users who can push have to come up with
> a system that *they* trust. Whatever bright idea I have is going to go
> down in flames if Tim et al. aren't fully committed to it and adequate
> sacrifices are made in other areas to adjust to a new system. If pushing
> more frequently isn't a priority for these users (or they are unable to
> find the time to fix the current system) then I don't know what to do
> either.
>
> Are we all in deadlock or something? Are the users who can push waiting
> from some proposals/work from the rest of the community?
>

--
Neil Kandalgaonkar (   <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Russell N. Nelson - rnnelson
> Well, AFAIK our bottleneck is reviewing.

I don't think that's the only bottleneck. An unwillingness to release code is a sign of a lack of trust. Reviewed code is a source of trust. But there are other sources of trust:
  o code reviews
  o test cases (a bug isn't fixed until there's a test case which ensures that it won't come back.)
  o readable code.
  o beta testing that actually gets tested.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Alex Zaddach
In reply to this post by Trevor Parscal-2
On 5/31/11, Trevor Parscal <[hidden email]> wrote:
> There's been tons of discussion about what is an ideal release schedule for
> us (probably literally if you printed it out at 12pt on standard copy
> paper). At this point I think we are balancing between fighting the bad
> habits that got us into the 1.17 rut, and trying to give our engineering
> team enough time to do significant work (rather than spending 1 day a week
> pushing code).

One issue is that "time spent deploying" does not appear to be
independent of "time between deployments." If it always took a day to
deploy new code, that would be a good argument in favor of more time
between deployments. But in practice, the more time that passes
without pushing code to the site, the longer it takes to complete the
deployment. Spending a week deploying every other month doesn't really
save much time over spending a day every week.

-- Alex

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Brion Vibber
On Tue, May 31, 2011 at 2:50 PM, Alex "Mr.Z-man" <[hidden email]>wrote:

> On 5/31/11, Trevor Parscal <[hidden email]> wrote:
> > There's been tons of discussion about what is an ideal release schedule
> for
> > us (probably literally if you printed it out at 12pt on standard copy
> > paper). At this point I think we are balancing between fighting the bad
> > habits that got us into the 1.17 rut, and trying to give our engineering
> > team enough time to do significant work (rather than spending 1 day a
> week
> > pushing code).
>
> One issue is that "time spent deploying" does not appear to be
> independent of "time between deployments." If it always took a day to
> deploy new code, that would be a good argument in favor of more time
> between deployments. But in practice, the more time that passes
> without pushing code to the site, the longer it takes to complete the
> deployment. Spending a week deploying every other month doesn't really
> save much time over spending a day every week.
>

I'd actually consider it pretty ideal to spend a day every week deploying
updates, gathering feedback, and making fixes. Rather than an argument in
favor of longer cycles, I'd consider that an argument in favor of shorter
cycles!

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

MZMcBride-2
In reply to this post by Trevor Parscal-2
Trevor Parscal wrote:
> If you feel that releasing frequently is important, as a non-reviewer
> without shell access and no official power to release anything, this must be
> frustrating. Maybe we could instead of bickering about when code should be
> released, come up with and support new roles that volunteers can take on
> that would accelerate the code review and release process.

Yes, it's incredibly frustrating to the point that volunteer developers have
walked away from MediaWiki code development. This is the "wiki project";
things are supposed to be fast! When someone makes a patch or a commit and
the best we can say is "it might get looked at this year with a fifty
percent confidence interval," that's not okay.

Code deployments to the live sites need to happen more often than quarterly.
There are almost no benefits to such a long gap between deployments and the
detriments are clear.

Is there a problem with saying hell or high water, we won't go more than a
month without a deployment? I realize Wikimedia is a bit different, but
taking a page out of the rest of the business world's book, you set a
deadline and then it just fucking gets met. No excuses, no questions. The
problem seems to be finding anyone to lay down the damn law.

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Brion Vibber
On Tue, May 31, 2011 at 3:20 PM, MZMcBride <[hidden email]> wrote:

> Yes, it's incredibly frustrating to the point that volunteer developers
> have
> walked away from MediaWiki code development. This is the "wiki project";
> things are supposed to be fast! When someone makes a patch or a commit and
> the best we can say is "it might get looked at this year with a fifty
> percent confidence interval," that's not okay.
>
> Code deployments to the live sites need to happen more often than
> quarterly.
> There are almost no benefits to such a long gap between deployments and the
> detriments are clear.
>
> Is there a problem with saying hell or high water, we won't go more than a
> month without a deployment? I realize Wikimedia is a bit different, but
> taking a page out of the rest of the business world's book, you set a
> deadline and then it just fucking gets met. No excuses, no questions. The
> problem seems to be finding anyone to lay down the damn law.
>

Sing it, brother! We're getting *some* stuff through quicker within the
deployment branches, but not nearly as much as we ought to.

Whatever the overall release branching frequency, there's also an update
cycle within that in getting fixes & independent features (usually
extensions) pushed out to the wild, and that's the cycle that's often most
important to users (because that's where their most immediate problems get
fixed) & developers (because users are where we get feedback).

Fixes need to be hitting production within days at longest, and more
features than just UploadWizard and ArticleFeedback should be able to make
it out on their own schedule without being forced to wait for a total
infrastructure update.

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Neil Kandalgaonkar
In reply to this post by MZMcBride-2
On 5/31/11 3:20 PM, MZMcBride wrote:

> taking a page out of the rest of the business world's book, you set a
> deadline and then it just fucking gets met. No excuses, no questions.

I think you have an optimistic view of how businesses actually work. :)

But, in any case, in a business, there is a Plan that everyone is trying
to follow and in theory, deviations from that Plan are avoided. In our
environment we want to be responsive to the schedule of a volunteer
developer, who may be completely unaware or uninterested in our plans.

Perhaps the answer is that we have to give the volunteer developers some
obvious pathway to harmonizing their and our priorities. Like, if you're
working on files and multimedia, you should be emailing Bryan, me, or
maybe Tim or Russell. Could it be that simple?


> The
> problem seems to be finding anyone to lay down the damn law.

Well, it's not like wiki pages happen by someone cracking a whip either.
That said, we would benefit from some urgency towards correcting the
problem.




--
Neil Kandalgaonkar     <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

MZMcBride-2
Neil Kandalgaonkar wrote:
> On 5/31/11 3:20 PM, MZMcBride wrote:
>> taking a page out of the rest of the business world's book, you set a
>> deadline and then it just fucking gets met. No excuses, no questions.
>
> I think you have an optimistic view of how businesses actually work. :)

It's funny that you say that. When there was a hard deadline for the
UploadWizard being deployed (November 30?), what happened? Was the deadline
met?

It's not a matter of Wikimedia having the ability to set and meet deadlines;
they've pretty clearly demonstrated that when something is important enough,
it's not an issue. In this case, it's a matter of finding/creating the
_willingness_ to set/meet the deadlines (and the lack of resulting
consequences if/when deadlines are missed).

I occasionally show my face at wiki-meetups, and invariably tech comes up
for discussion (MediaWiki/tech being at the center of nearly everything
Wikimedia). My view (and perhaps others share it) is that Wikimedia code
development can be summed up like this currently: there are so many cooks in
the kitchen and yet dinner is always late.

> Perhaps the answer is that we have to give the volunteer developers some
> obvious pathway to harmonizing their and our priorities. Like, if you're
> working on files and multimedia, you should be emailing Bryan, me, or
> maybe Tim or Russell. Could it be that simple?

I don't think being more explicit/clear about what people are working on
could ever be a bad thing. Will it help alleviate whichever problem it is
you're thinking about? I don't know. But I can't imagine a wiki page making
it clear who works on what is going to hurt anything. It can only really
help. :-)

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Chad
On Tue, May 31, 2011 at 6:47 PM, MZMcBride <[hidden email]> wrote:
> I occasionally show my face at wiki-meetups, and invariably tech comes up
> for discussion (MediaWiki/tech being at the center of nearly everything
> Wikimedia). My view (and perhaps others share it) is that Wikimedia code
> development can be summed up like this currently: there are so many cooks in
> the kitchen and yet dinner is always late.
>

Maybe people should stop adding so many courses to dinner ;-)

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Happy-melon
In reply to this post by Neil Kandalgaonkar

"Neil Kandalgaonkar" <[hidden email]> wrote in message
news:[hidden email]...
> On 5/31/11 3:20 PM, MZMcBride wrote:
>
>> taking a page out of the rest of the business world's book, you set a
>> deadline and then it just fucking gets met. No excuses, no questions.
>
> I think you have an optimistic view of how businesses actually work. :)

The only modification needed to bring that sentence in line with business
reality is adding "it just fucking gets met **or someone's head rolls**.

> But, in any case, in a business, there is a Plan that everyone is trying
> to follow and in theory, deviations from that Plan are avoided. In our
> environment we want to be responsive to the schedule of a volunteer
> developer, who may be completely unaware or uninterested in our plans.

Plenty of businesses work on a rolling-development model, probably more
businesses than have totally static specs.  The difference between that and
WMF, and even between WMF and other non-businesses like Linux and Mozilla,
is that if a release is mandated by some higher power and something is
holding up that release, **whatever it is gets steamrollered out of the
way**.  If there is a clear roadmap that says that any feature that's not
debugged and ready-to-go by Wednesday morning, by the first Tuesday of the
month, by the 32nd of June, whenever, then it gets reverted, no one is going
to complain when lo and behold, such features get reverted.  *Everyone* is
going to complain if the 32nd of June becomes the 32nd of December before
the feature even makes it onto the cluster.

> Perhaps the answer is that we have to give the volunteer developers some
> obvious pathway to harmonizing their and our priorities. Like, if you're
> working on files and multimedia, you should be emailing Bryan, me, or
> maybe Tim or Russell. Could it be that simple?
>
>
>> The
>> problem seems to be finding anyone to lay down the damn law.
>
> Well, it's not like wiki pages happen by someone cracking a whip either.
> That said, we would benefit from some urgency towards correcting the
> problem.

Wiki pages don't need a whip, and nor does MediaWiki.  Wiki pages are
*missing* several layers of delays and checkpoints in the
volunteer-writes-something-to-volunteer-sees-it-in-use chain.  MediaWiki is
currently like a wiki with FlaggedRevisions turned on on every articlespace
page, but with all the admins on the wiki working on other things such that
no one gets round to cleaning out the Special:OldReviewedPages list more
than once every *nine months*.  That would kill a wiki community stone dead
*pretty much instantly*.

>"Brion Vibber" <[hidden email]> wrote in message
>news:BANLkTinZzef=[hidden email]...
>
> Sing it, brother! We're getting *some* stuff through quicker within the
> deployment branches, but not nearly as much as we ought to.

The fact that some things are *not* getting stuck in the CR quagmire is part
of the *problem*, not the solution.  The upper levels of the developer
hierarchy ***obviously know*** that the mainline CR process is substantially
broken, BECAUSE ***THEY'RE NOT USING IT*** FOR THINGS THAT ARE IMPORTANT TO
THEM.  The unavoidable implication of that observation is that the work of
the volunteer developers *DOESN'T* matter to them.  Whether or not that
implication is correct (I have confidence that it's not) is irrelevant, the
fact that it's there is what's doing horrible damage to the MediaWiki
community.

--HM
 



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Brion Vibber
On Tue, May 31, 2011 at 4:31 PM, Happy-melon <[hidden email]> wrote:

> >"Brion Vibber" <[hidden email]> wrote in message
> >news:BANLkTinZzef=[hidden email]...
> >
> > Sing it, brother! We're getting *some* stuff through quicker within the
> > deployment branches, but not nearly as much as we ought to.
>
> The fact that some things are *not* getting stuck in the CR quagmire is
> part
> of the *problem*, not the solution.  The upper levels of the developer
> hierarchy ***obviously know*** that the mainline CR process is
> substantially
> broken, BECAUSE ***THEY'RE NOT USING IT*** FOR THINGS THAT ARE IMPORTANT TO
> THEM.


That's not correct -- the same code review tools are being used to look over
and comment on those things, AND THEN THE DAMN THING ACTUALLY GETS MERGED TO
THE DEPLOYMENT BRANCH BY SOMEBODY AND PUSHED TO PRODUCTION BY SOMEBODY.

It's that step 2 that's missing for everything else until the accumulated
release pressure forces a system-wide update.

The unavoidable implication of that observation is that the work of
> the volunteer developers *DOESN'T* matter to them.  Whether or not that
> implication is correct (I have confidence that it's not) is irrelevant, the
> fact that it's there is what's doing horrible damage to the MediaWiki
> community.
>


-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Roan Kattouw-2
On Wed, Jun 1, 2011 at 1:43 AM, Brion Vibber <[hidden email]> wrote:
>> substantially
>> broken, BECAUSE ***THEY'RE NOT USING IT*** FOR THINGS THAT ARE IMPORTANT TO
>> THEM.
>
>
> That's not correct -- the same code review tools are being used to look over
> and comment on those things, AND THEN THE DAMN THING ACTUALLY GETS MERGED TO
> THE DEPLOYMENT BRANCH BY SOMEBODY AND PUSHED TO PRODUCTION BY SOMEBODY.
>
Alright, we've had fun with all caps for a while, so let's focus on
solutions now.

MZ says we need to move to a system with regular deployments, where
regular is more than monthly and ideally weekly or bi-weekly. I
completely agree with this, per the "spend a day per week or a week
per month" argument. The discussion then turns into conflating
releases and deployments, followed by some back and forth yelling
about deadlines and CR processes.

So let me sketch how I see us getting there.

1. Get 1.18 reviewed
2a. Get 1.18 deployed and released
2b. At the same time, continue efforts to have code review catch up
with SVN HEAD
3. Once we have reviewed everything up to HEAD (or up to a revision
less than a week older than HEAD), deploy it to Wikimedia
4. Keep reviewing so the CR backlog doesn't grow, and deploy HEAD
again in 1-2 weeks. Rinse and repeat.

There are a few caveats here, of course:
* 2a and 2b largely compete for the time of the same developers
* 3 (initial HEAD deployment) will probably be a bit hairy because
it's a lot of code the first time. After that it's only 1-2 weeks'
worth each time
* For 4, we need to figure out a way to make CR actually happen in a
regular and timely fashion

So a lot of it comes down to implementing a proper code review
process, both for the one-off catch-up sprint (to 1.18, then to HEAD;
we've done one of these before with 1.17) and for the day-to-day
keep-up work. I think we may also need to make it clearer that
reviewers (who, typically, are paid developers working on many other
things) need to spend one-fifth of their time (i.e. a day per week for
full-time employees) on code review. This is basically the "admins
aren't watching Special:Unreviewedpages at all" problem that
Happy-melon mentioned.

So mostly, I think our immediate problems are:
* no agreed-upon strategy to tackle the problem (what do y'all think
about mine?)
* not enough man-hours spent on keeping up with new commits
** ...presumably because employed people aren't given the time to work
on it and/or made to work on it
** ...and because some of our reviewers are college students working
part-time (fortunately I'll graduate soon and have more time :D)

Thoughts?

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Brion Vibber
On Wed, Jun 1, 2011 at 7:58 AM, Roan Kattouw <[hidden email]> wrote:

> Alright, we've had fun with all caps for a while, so let's focus on
> solutions now.
>

Ok, I'm turning in my caps lock key. ;)


> So let me sketch how I see us getting there.
>
> 1. Get 1.18 reviewed
> 2a. Get 1.18 deployed and released
> 2b. At the same time, continue efforts to have code review catch up
> with SVN HEAD
> 3. Once we have reviewed everything up to HEAD (or up to a revision
> less than a week older than HEAD), deploy it to Wikimedia
> 4. Keep reviewing so the CR backlog doesn't grow, and deploy HEAD
> again in 1-2 weeks. Rinse and repeat.
>
> There are a few caveats here, of course:
> * 2a and 2b largely compete for the time of the same developers
>

That's one of the reasons actually assigning time for it should be helpful:
currently we have zero staff dedicated full-time to getting code ready for
deployment and deployed. We have several staff & contractors with it on
their list of duties, but no actual requirement that it get done on a
regular basis. With no regular short-term review & deployment schedule (even
for fixes), we all find other things to do and get out of the habit.

And let's not forget that a big part of what review does is to help develop
the reviewee's coding skills! By pointing out things that need fixing and
things to watch out for, we help all our coders become better coders. And by
pushing review closer to the original code-writing, we'll make that feedback
loop tighter & more effective.



> * 3 (initial HEAD deployment) will probably be a bit hairy because
> it's a lot of code the first time. After that it's only 1-2 weeks'
> worth each time
> * For 4, we need to figure out a way to make CR actually happen in a
> regular and timely fashion
>

+1


>
> So a lot of it comes down to implementing a proper code review
> process, both for the one-off catch-up sprint (to 1.18, then to HEAD;
> we've done one of these before with 1.17) and for the day-to-day
> keep-up work. I think we may also need to make it clearer that
> reviewers (who, typically, are paid developers working on many other
> things) need to spend one-fifth of their time (i.e. a day per week for
> full-time employees) on code review. This is basically the "admins
> aren't watching Special:Unreviewedpages at all" problem that
> Happy-melon mentioned.
>

*nod*

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Status of more regular code deployments

Roan Kattouw-2
On Wed, Jun 1, 2011 at 7:42 PM, Brion Vibber <[hidden email]> wrote:
> That's one of the reasons actually assigning time for it should be helpful:
> currently we have zero staff dedicated full-time to getting code ready for
> deployment and deployed. We have several staff & contractors with it on
> their list of duties, but no actual requirement that it get done on a
> regular basis. With no regular short-term review & deployment schedule (even
> for fixes), we all find other things to do and get out of the habit.
>
It would be nice to have someone doing this full-time yes, but even
without that, I agree that having regular short-term schedules helps
enforcing discipline.

However, I guess some people are afraid that assigning someone to this
full-time will waste their other skills and possibly make them
unhappy, and I kind of agree. However, dedicating one FTE spread among
multiple people should work too, as long as it's not more than, say,
3. I would quite like to be one of these people once I'm able to work
full-time.

> And let's not forget that a big part of what review does is to help develop
> the reviewee's coding skills! By pointing out things that need fixing and
> things to watch out for, we help all our coders become better coders. And by
> pushing review closer to the original code-writing, we'll make that feedback
> loop tighter & more effective.
>
Absolutely! Another thing that happens is that people's coding skills
improve to the point where they can *review things themselves* . This
is how we build our reviewer base: hold our existing devs to high
standards, and wait for them to grow into it.

I'm saying this because what you say in the first paragraph can be
(and at one point was) used as an argument to hire a "code reviewer",
i.e. hire a new person specifically for code review. IMO this is
doomed to fail because code review is pretty much the opposite of an
entry-level position. We can train people to be reviewers, but only if
they already have significant dev experience and have shown potential,
not if we just grabbed them off the proverbial street and they're just
getting their feet wet with MediaWiki.

Roan Kattouw (Catrope)

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