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

Mailing List Archive: Wikipedia: Wikitech

We're still in a code slush (Re: How to avoid a post-branch code slush)

 

 

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


robla at wikimedia

Feb 10, 2012, 11:05 PM

Post #1 of 3 (195 views)
Permalink
We're still in a code slush (Re: How to avoid a post-branch code slush)

Hi everyone,

I probably mistitled my last message in the "How to avoid a
post-branch code slush" thread. There seems to be a misconception
that the code slush is over.

Please go back and read the thread. The status quo is *there is still
a code slush*. What this means:
1. No big architectural changes without discussion. Not merely "hey,
I sent a message, and no one responded", but as in: you send a
message, and two or three people say "yeah, you're right, that needs
to happen, make it so" without serious dissent
2. No big omnibus whitespace cleanups. These are of debatable use
any time, but now they make backporting a big pain-in-the-butt, and
we'll need to do a lot of backporting to 1.19.
3. Have a reviewer lined up ready to ok your revision *before you
commit it*. If you can't get a tentative commitment from a reviewer,
don't commit it.

We have a couple of different options in this interim period between
now and when we start using Git:
a. we let people commit as was previously normal into trunk, but we
only migrate the code that's been formally reviewed.
b. we insist on pre-commit review from now until we go live on Git.

So far, there hasn't been a lot of discussion on either option. Brion
and Roan both pointed out problems with option "a", while no one has
raised a serious objection to option "b".

Rob

On Wed, Feb 8, 2012 at 10:23 PM, Rob Lanphier <robla [at] wikimedia> wrote:
> On Wed, Feb 8, 2012 at 3:43 PM, Brion Vibber <brion [at] pobox> wrote:
>> This is one of the reasons I've been hoping we'd move to a more pre-commit
>> review model. Especially for big refactorings and cleanups that have
>> limited immediate value, we tend to get a lot of breakages a not a lot of
>> interest in fully reviewing them (eg actually checking all the code paths
>> to make sure they really work).
>
> Here's the thinking that lead to where we are: the cutover to Git is
> the point at which we want to fully move to precommit.  It seems like
> an enormous pain-in-the-butt to move to full precommit with our
> current toolset (SVN + CodeReview tool).
>
> However, we're much closer than we've ever been to having Git, and it
> may be worth dealing with some short-term pain.
>
>> To a certain degree, I'd actually consider it desirable to have a permanent
>> 'slush' to the extent that destabilizing work should *always* be talked out
>> a bit and tested before it lands on trunk/head/master.
>
> Yup, agree 100%.
>
> Let's all just pretend this has always been the status quo starting
> right now.  I think we've already established that there used to be
> more liberal reversion, and that when that went away, so too went our
> ability to stay on top of the review queue.
>
>> If we're not ready to go fully git the instant we branch 1.19,
>
> Given that the branch just happened, and we're not ready yet, that's
> the case.  Chad can give you more of an update, but my understanding
> is:
> *  A (hopefully) final test migration of core is slated for this week.
>  Chad believes he's got all of the blocking problems sorted out.
> *  Extensions migration isn't going so smoothly.  The same tools that
> work splendidly with core seem to crash with the very small subset of
> extensions that he's tried it out with.  Could be a minor problem
> that's easy to fix, or could be gawd awful.  TBD
> *  We'd like a two-week window of warning/testing/playing around
> before making the cutover.
>
> All told, the current plan is beginning of March for core, middle of
> March for extensions.  More details here:
> https://www.mediawiki.org/wiki/Git/Conversion
>
> ...and in the email that I hear Chad is writing  :-)
>
>> we may wish
>> to consider applying more formal review to things proposed to go into trunk
>> on SVN. This may be simpler than attempting to synchronize SVN and git via
>> post-SVN-pre-git reviews...
>
> I'd be perfectly fine with either outcome (more formal pre-commit
> review, or picking our SVN->Git cutover point based on what's
> reviewed).
>
> Rob

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


vasilvv at gmail

Feb 10, 2012, 11:10 PM

Post #2 of 3 (182 views)
Permalink
Re: We're still in a code slush (Re: How to avoid a post-branch code slush) [In reply to]

On Sat, Feb 11, 2012 at 11:05 AM, Rob Lanphier <robla [at] wikimedia> wrote:
> We have a couple of different options in this interim period between
> now and when we start using Git:
> a.  we let people commit as was previously normal into trunk, but we
> only migrate the code that's been formally reviewed.
> b.  we insist on pre-commit review from now until we go live on Git.
>
> So far, there hasn't been a lot of discussion on either option.  Brion
> and Roan both pointed out problems with option "a", while no one has
> raised a serious objection to option "b".
>

How are we technically going to do "a"?

--vvv

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


vasilvv at gmail

Feb 10, 2012, 11:10 PM

Post #3 of 3 (180 views)
Permalink
Re: We're still in a code slush (Re: How to avoid a post-branch code slush) [In reply to]

On Sat, Feb 11, 2012 at 11:10 AM, Victor Vasiliev <vasilvv [at] gmail> wrote:
> How are we technically going to do "a"?

Sorry, I meant "b".

--vvv

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