Tim Starling wrote:
> In the last week, I've been reviewing extensions that were written
> years ago, and were never properly looked at. I don't think it's
> appropriate to measure success in code review solely by the number of
> "new" revisions after the last branch point.
>
> Code review of self
Tim Starling writes:
> On 26/03/11 14:56, Mark A. Hershberger wrote:
>> If code is to survive past a week in the repository, it has to be
>> reviewed.
>>
>> If you want to make a commit that depends on un-reviewed code, you have
>> to find someone to review it. Otherwise, your commit will break
On 29/03/11 11:26, MZMcBride wrote:
> Long ago I lost track of who's in charge of what, but I'm told there is some
> sort of hierarchy in place in the tech department. Who's empowered to start
> assigning people to review code in a reasonable timeframe? Like Aryeh, I
> find this entire thread a bit
Tim Starling wrote:
> If the code review manpower is there, we can be friendly and
> encouraging to our developers, not threaten them with a revert unless
> they can make at least one developer be their friend within seven days.
>
> The WMF really is central in this, because we have a policy of hi
On Fri, Mar 25, 2011 at 11:56 PM, Mark A. Hershberger
wrote:
> As far as I can see, the main reason that people think code review
> works better under GIT is because the committer is responsible for
> getting xyr[2] code reviewed *before* it is merged. The committer is
> motivated to find get xyr
2011/3/28 Tim Starling :
> By definition, our volunteer developers have lives outside of
> MediaWiki. We have to fit in with their schedules. I don't think we
> should give them a kick in the teeth just because they committed
> something on Sunday and have to go to school on Monday.
>
> If a commit
On 26/03/11 14:56, Mark A. Hershberger wrote:
> So, other than switching to the mythical GIT, where all is rainbows and
> roses, what can we do to improve code review now?
It's no mystery. After the 1.17 deployment, the team that was doing
code review was disassembled. If you want code review to h
Brion Vibber writes:
> On Fri, Mar 25, 2011 at 8:56 PM, Mark A. Hershberger <
>> If you want to make a commit that depends on un-reviewed code, you have
>> to find someone to review it. Otherwise, your commit will break trunk
>> when that code is reverted.
>
> This is actually a lot harder than
On Fri, Mar 25, 2011 at 8:56 PM, Mark A. Hershberger <
mhershber...@wikimedia.org> wrote:
> Platonides writes:
>
> > And no, nobody wants our review paradigm to be "let's spend several
> > months on the backlog every time we want to release". It was just the
> > best we managed to afford.
>
> We'
Bryan Tong Minh wrote:
> On Sun, Mar 27, 2011 at 3:33 AM, Platonides wrote:
>> Come on. It is easy enough to check if your revision is the culprit.
>>
>> svn up -r r80247
>> cd tests/phpunit/
>> make noparser
>>
> Which takes approximately one hour to run.
> We should fix this, because otherwise no
On Sun, Mar 27, 2011 at 3:33 AM, Platonides wrote:
> Daniel Friesen wrote:
>> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80248
>> Comment gives a Tesla link saying something broke. However the Tesla
>> link does not identify that commit as the guaranteed commit that
>> actually broke cod
Roan Kattouw wrote:
> 2011/3/26 Mark A. Hershberger :
>> If code is to survive past a week in the repository, it has to be
>> reviewed.
>>
> This is basically what I suggested in the other thread, except I added
> a few other conditions that have to be satisfied before we can start
> using such a
Roan Kattouw wrote:
> 2011/3/26 Mark A. Hershberger :
>> If code is to survive past a week in the repository, it has to be
>> reviewed.
>>
> This is basically what I suggested in the other thread, except I added
> a few other conditions that have to be satisfied before we can start
> using such a p
Daniel Friesen wrote:
> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80248
> Comment gives a Tesla link saying something broke. However the Tesla
> link does not identify that commit as the guaranteed commit that
> actually broke code. The commit was followed up with several fixmes
> alr
On 11-03-25 11:57 PM, Ashar Voultoiz wrote:
> On 26/03/11 05:48, Daniel Friesen wrote:
>> What about the fixmes left open since it's not clear if anything is even
>> still broken currently.
> If it is unclear: it either need a clarification or deserve a reversion.
> We already have enough lines hid
2011/3/26 Mark A. Hershberger :
> If code is to survive past a week in the repository, it has to be
> reviewed.
>
This is basically what I suggested in the other thread, except I added
a few other conditions that have to be satisfied before we can start
using such a paradigm (relating to reviewer a
On 26/03/11 05:48, Daniel Friesen wrote:
> What about the fixmes left open since it's not clear if anything is even
> still broken currently.
If it is unclear: it either need a clarification or deserve a reversion.
We already have enough lines hiding in the fog, read to jump at you when
you get
On 11-03-25 09:23 PM, Chad wrote:
> On Fri, Mar 25, 2011 at 11:56 PM, Mark A. Hershberger
> wrote:
>> I suggest we implement this ASAP. If we start this policy on April 4th,
>> we would be doing the first round of reverts April 11th. We should
>> grandfather in the current code, of course. It
On Fri, Mar 25, 2011 at 11:56 PM, Mark A. Hershberger
wrote:
> I suggest we implement this ASAP. If we start this policy on April 4th,
> we would be doing the first round of reverts April 11th. We should
> grandfather in the current code, of course. It would be exempt from
> grim reversion reap
Platonides writes:
> And no, nobody wants our review paradigm to be "let's spend several
> months on the backlog every time we want to release". It was just the
> best we managed to afford.
We've been doing a little better for the past month, but Robla's
chart[1] is still looking ugly.
So, othe
The only one I know and like is Gerrit.
-Chad
On Mar 23, 2011 8:43 PM, "Platonides" wrote:
> I'd prefer if those superb review tools were named instead of vague
> references about greener pastures and how wonderful it will be reviewing
> code with git.
>
> And no, nobody wants our review paradigm
21 matches
Mail list logo
