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

Mailing List Archive: Wikipedia: Wikitech

Making code review happen in 1.18

 

 

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


mhershberger at wikimedia

Feb 13, 2011, 2:29 PM

Post #1 of 21 (2030 views)
Permalink
Making code review happen in 1.18

The problem with our current VCS is the sort of work-flow that has
developed around it.

But we can solve the work-flow problem without introducing an entirely
new VCS and disrupting everything for a month or so while people adjust
to the new system.

The solution I'm proposing is that we branch 1.18 immediately after the
release of the 1.17 tarball.

Revisions marked “OK” (or, perhaps, tagged “118”) on the trunk could be
merged to the 1.18 branch. Or, to make merging into 1.18 less of a
chore for a single person, we could enable those doing code review to
merge code they've reviewed into the 1.18 branch. In this way, we
achieve Roan's (and my) goal of continuous integration.

This also put the onus on the individual developers to make sure that
their code gets reviewed and that problems found get fixed.

As a bonus, we could set a date *now* to make the 1.18 release and then
just release whatever is in the 1.18 branch on that day.

I think we need a few goals thrown in to make this really good — I
propose “1.18 will include a web UI for configuring MediaWiki” and “1.18
will cut the number of global variables in half” to pick two of my
personal favorites — but I think the work-flow of how MediaWiki is
prepared for release needs to be addressed.

Mark.

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


brion at pobox

Feb 13, 2011, 2:46 PM

Post #2 of 21 (1979 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On Sun, Feb 13, 2011 at 2:29 PM, Mark A. Hershberger <
mhershberger [at] wikimedia> wrote:

>
> The problem with our current VCS is the sort of work-flow that has
> developed around it.
>
> But we can solve the work-flow problem without introducing an entirely
> new VCS and disrupting everything for a month or so while people adjust
> to the new system.
>
> The solution I'm proposing is that we branch 1.18 immediately after the
> release of the 1.17 tarball.
>
> Revisions marked “OK” (or, perhaps, tagged “118”) on the trunk could be
> merged to the 1.18 branch. Or, to make merging into 1.18 less of a
> chore for a single person, we could enable those doing code review to
> merge code they've reviewed into the 1.18 branch. In this way, we
> achieve Roan's (and my) goal of continuous integration.
>

If by this you suggest that 1.18 will be Wikimedia's actual live deployment
branch, and that it should always be within a day or two's commits from
trunk, then I can get down with that.


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


bryan.tongminh at gmail

Feb 13, 2011, 2:54 PM

Post #3 of 21 (1981 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

Hi Mark,


It is good to see people thinking about 1.18 already!

On Sun, Feb 13, 2011 at 11:29 PM, Mark A. Hershberger
<mhershberger [at] wikimedia> wrote:
>
> The problem with our current VCS is the sort of work-flow that has
> developed around it.
>
> But we can solve the work-flow problem without introducing an entirely
> new VCS and disrupting everything for a month or so while people adjust
> to the new system.
>
Can you be a bit more specific? What problems are you implying? I
think of some problems, but I don't know how they are consequences
from our workflow and VCS.

> The solution I'm proposing is that we branch 1.18 immediately after the
> release of the 1.17 tarball.
>
I agree... a bit. We should branch 1.18wmf1 immediately from trunk
once things have calmed down a bit. However, this 1.18wmf1 does not
necessarily need to be the base for 1.18. We can branch 1.18wmf2 from
trunk again and so on, until the time that we want to release 1.18
when we make a final 1.18wmfN branch and 1.18 branch.

> I think we need a few goals thrown in to make this really good I
> propose 1.18 will include a web UI for configuring MediaWiki and 1.18
> will cut the number of global variables in half to pick two of my
> personal favorites but I think the work-flow of how MediaWiki is
> prepared for release needs to be addressed.
>
Well, if you want 1.18 released before 2012... ;)


Bryan

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


p858snake at yahoo

Feb 13, 2011, 3:31 PM

Post #4 of 21 (1979 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

> Well, if you want 1.18 released before 2012... ;)
> Bryan

Well of course, Where would we be if we let the world end without a
new(ish) mediawiki release?
-Peachey

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


mhershberger at wikimedia

Feb 13, 2011, 5:11 PM

Post #5 of 21 (1975 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

Bryan Tong Minh <bryan.tongminh [at] gmail> writes:

>> The problem with our current VCS is the sort of work-flow that has
>> developed around it.
>
> Can you be a bit more specific? What problems are you implying? I
> think of some problems, but I don't know how they are consequences
> from our workflow and VCS.

The introduction and growth of various DVCS (especially git) over the
past few years has shown how a centralized VCS (like svn) ends up
affecting and even forming the workflow.

For example, we want to release only reviewed code, but we also want to
make development access (and commit bits) available to as many people as
possible.

As a result, we have code review, but it is peripheral to the process of
getting code committed to trunk. So, when the time came to put 1.17
together, we had this huge mound of un-reviewed code that had to be
examined.

This workflow is different from a DVCS. Take Linux, for example. Linus
pulls code from several lieutenants. Anyone can set up a branch of the
Linux source code and commit to it, but to get Linus to ship their code,
they have to get a lieutenant to review it and give it to Linus.

The workflow is different in that code review is an integral, not
peripheral, process. As a bonus development access is available to
anyone willing to run “git clone”.

>> I think we need a few goals thrown in to make this really good — I
>> propose “1.18 will include a web UI for configuring MediaWiki” and “1.18
>> will cut the number of global variables in half” to pick two of my
>> personal favorites — but I think the work-flow of how MediaWiki is
>> prepared for release needs to be addressed.
>>
> Well, if you want 1.18 released before 2012... ;)

I was getting a little dreamy there. One goal? One SMALL goal? A
CDB-based configuration database? That way, work on a web UI could
happen outside of the trunk, but would still be usable and ready to
integrate after 1.19 was branched.

But, yes, I want to get 1.18 out by July. If that means I have to be
satisfied with more prosaic goals like “getting code review working
better” and “keep 1.18 within a day or two's commits from trunk” (to
paraphrase Brion) then I'll be happy.

Mark.

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


mhershberger at wikimedia

Feb 13, 2011, 5:38 PM

Post #6 of 21 (1973 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

mhershberger [at] wikimedia (Mark A. Hershberger) writes:

> The solution I'm proposing is that we branch 1.18 immediately after the
> release of the 1.17 tarball.

I want to give credit where it is due. Although I haven't seen him
propose it here, this is, in fact, Robla's idea. He and I were
discussing what needed to happen for 1.18 and it was his idea to branch
1.18 immediately after the release of the 1.17 tarball.

Mark.

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


dvanliere at gmail

Feb 13, 2011, 5:47 PM

Post #7 of 21 (1977 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

+1 to migrate to a DVCS

On Sun, Feb 13, 2011 at 8:38 PM, Mark A. Hershberger <
mhershberger [at] wikimedia> wrote:

> mhershberger [at] wikimedia (Mark A. Hershberger) writes:
>
> > The solution I'm proposing is that we branch 1.18 immediately after the
> > release of the 1.17 tarball.
>
> I want to give credit where it is due. Although I haven't seen him
> propose it here, this is, in fact, Robla's idea. He and I were
> discussing what needed to happen for 1.18 and it was his idea to branch
> 1.18 immediately after the release of the 1.17 tarball.
>
> Mark.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
<a href="http://about.me/diederik">Check out my about.me profile!</a>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeroendedauw at gmail

Feb 13, 2011, 5:49 PM

Post #8 of 21 (1977 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

> +1 to migrate to a DVCS

Unless I'm mistaken no one has actually suggested doing that.

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Simetrical+wikilist at gmail

Feb 13, 2011, 5:49 PM

Post #9 of 21 (1981 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On Sun, Feb 13, 2011 at 8:11 PM, Mark A. Hershberger
<mhershberger [at] wikimedia> wrote:
> This workflow is different from a DVCS.  Take Linux, for example.  Linus
> pulls code from several lieutenants.  Anyone can set up a branch of the
> Linux source code and commit to it, but to get Linus to ship their code,
> they have to get a lieutenant to review it and give it to Linus.
>
> The workflow is different in that code review is an integral, not
> peripheral, process.  As a bonus development access is available to
> anyone willing to run “git clone”.

On the other hand, in Linux, it can be hard to get patches reviewed
and accepted in a timely fashion, because there's no clear chain of
command unless Linus personally intervenes. I think Mozilla is an
excellent model to follow, in that they have a well-defined review
process (not "everyone can object to design decisions at the eleventh
hour" like Linux) and make sure that all patches get reviewed in a
timely fashion (at least as far as I've seen). I've submitted two
patches to Mozilla, and I got immediate feedback and review on both of
them from developers responsible for the relevant areas.

What I think is important is that a) there's a formal process that
ensures all submitted code gets reviewed, and b) this process is
basically the same for everyone (with no group of people with "commit
access" who get to jump the queue). Without (b), code by new
contributors will too easily slip through the cracks. Mozilla has
everyone submit code on Bugzilla, which is awkward but works -- even
core developers have to file a bug, submit a patch there, and get
review from another qualified coder, essentially the same as anyone.
(Obviously with exceptions like backing out build breakage and so on.)
Mozilla does have people with commit access, but they're just the
ones tasked with the chore of checking in code once it's been reviewed
-- they aren't allowed to just check stuff in without going through
the review process first.

If we switched to git, perhaps we should take a look at Gerrit for a
review tool. I've heard good things about it, but never used it
myself. Whatever we use, I think it should really be "review then
commit", not "commit then review". Cherry-picking from trunk to a
branch is possibly better than reverting things in trunk (not sure),
but in the medium term it would be much better to get rid of commit
access status entirely -- once we're sure we have a
properly-functioning review process that can keep up with changes.

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


brion at pobox

Feb 13, 2011, 6:15 PM

Post #10 of 21 (1983 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On Sun, Feb 13, 2011 at 5:49 PM, Jeroen De Dauw <jeroendedauw [at] gmail>wrote:

> > +1 to migrate to a DVCS
>
> Unless I'm mistaken no one has actually suggested doing that.
>

That's been talked about a few times here already. :)

There's some notes about potential git migration plans of action at:
http://www.mediawiki.org/wiki/Git_conversion

I know Avar's looked into it to various degrees, there may be some more
notes sitting about. I'm definitely in favor of it getting done in some way,
though there remain basic issues of what to do with extensions -- roll
everything into a giant repo with core and all extensions, or do extensions
separate but make it harder to maintain a full consistent versioned set?

I can definitely say that working with branching and merging in git is
FANTASTIC -- especially for the ability to use source control as your
workspace for in-progress patches, so you get the full benefits of
versioning *and* sharing while still working on something.

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


rlane32 at gmail

Feb 13, 2011, 7:30 PM

Post #11 of 21 (1975 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

> On the other hand, in Linux, it can be hard to get patches reviewed
> and accepted in a timely fashion, because there's no clear chain of
> command unless Linus personally intervenes. I think Mozilla is an
> excellent model to follow, in that they have a well-defined review
> process (not "everyone can object to design decisions at the eleventh
> hour" like Linux) and make sure that all patches get reviewed in a
> timely fashion (at least as far as I've seen). I've submitted two
> patches to Mozilla, and I got immediate feedback and review on both of
> them from developers responsible for the relevant areas.
>
> What I think is important is that a) there's a formal process that
> ensures all submitted code gets reviewed, and b) this process is
> basically the same for everyone (with no group of people with "commit
> access" who get to jump the queue). Without (b), code by new
> contributors will too easily slip through the cracks. Mozilla has
> everyone submit code on Bugzilla, which is awkward but works -- even
> core developers have to file a bug, submit a patch there, and get
> review from another qualified coder, essentially the same as anyone.
> (Obviously with exceptions like backing out build breakage and so on.)
> Mozilla does have people with commit access, but they're just the
> ones tasked with the chore of checking in code once it's been reviewed
> -- they aren't allowed to just check stuff in without going through
> the review process first.
>

I've been working on OpenStack quite a bit lately, and though they use
bazaar w/ launchpad, and not git, the idea behind it is pretty
similar.

Everything that goes in either needs a bug or a blueprint. Everything
is a branch. You don't actually commit, but do a request for a merge,
where your branch is linked to a bug or a blueprint. Two people need
to review the commit before it merges. Every bug in openstack is
generally expected to be a single branch. I've found this works very,
very well. They already have a fairly large community after only 6
months of existence, and have accepted a very large number of features
in a short period of time.

I'm very much a fan of the distributed system over the fully
centralized after becoming accustomed to it.

> If we switched to git, perhaps we should take a look at Gerrit for a
> review tool. I've heard good things about it, but never used it
> myself. Whatever we use, I think it should really be "review then
> commit", not "commit then review". Cherry-picking from trunk to a
> branch is possibly better than reverting things in trunk (not sure),
> but in the medium term it would be much better to get rid of commit
> access status entirely -- once we're sure we have a
> properly-functioning review process that can keep up with changes.
>

For puppet in the test/dev environment and the production environment
I plan on keeping the configuration in git, and manage it via gerrit.
I have a gerrit server for testing up on the same server as the
openstack (nova) controller. So far it looks pretty nice.

- Ryan Lane

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


lists at nadir-seen-fire

Feb 13, 2011, 8:10 PM

Post #12 of 21 (1972 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On 11-02-13 06:15 PM, Brion Vibber wrote:
> On Sun, Feb 13, 2011 at 5:49 PM, Jeroen De Dauw<jeroendedauw [at] gmail>wrote:
>
>>> +1 to migrate to a DVCS
>> Unless I'm mistaken no one has actually suggested doing that.
>>
> That's been talked about a few times here already. :)
>
> There's some notes about potential git migration plans of action at:
> http://www.mediawiki.org/wiki/Git_conversion
>
> I know Avar's looked into it to various degrees, there may be some more
> notes sitting about. I'm definitely in favor of it getting done in some way,
> though there remain basic issues of what to do with extensions -- roll
> everything into a giant repo with core and all extensions, or do extensions
> separate but make it harder to maintain a full consistent versioned set?
>
> I can definitely say that working with branching and merging in git is
> FANTASTIC -- especially for the ability to use source control as your
> workspace for in-progress patches, so you get the full benefits of
> versioning *and* sharing while still working on something.
>
> -- brion
Don't forget about what git does for those of us using remote servers too.
The ease of development between working on my monaco-port (in git for
now) vs. making core changes (svn of course) is fairly noticeable.

I do my development and testing on remote servers, and multiple ones at
that (monaco-port is actually located in 4 or 5 locations; My local
repo, on the dragonballencyclopedia's prototype and live site, another
location still setup on commonjs (I used to use it for experimenting
before I had other wikis to try it on) and in my trunktest for
development in a 1.18 env). And I usually vary whether I work on a
feature from the dragonballencyclopedia prototype or trunktest.
Sometimes doing a little work on both since one is a 1.16 env and the
other trunk and some features vary in support over that border.
The last key piece of background, is I don't commit/push things to
remote repos from these servers. I don't trust my own servers with any
of my private keys used to commit to remote repos (sure, I have separate
keys, and I could give it just the ability to push to the repo without
accessing other servers... but I don't trust my own servers enough to
give them the ability to commit something to Wikimedia's svn under my
name). Hence any task of committing/pushing to a remote repo is done
from my physical computer, not the server, despite 99% of the actual
development being on the servers.

So since I work on remote machines, but commit from my local machine I
need to find a way to transfer the changes from the remote machine to
the local machine before submitting them. This is completely trivial
with git. I just make the actual commit on the server itself (since I
don't need any special access for that). Then I pull from my machine to
pull those changes from the server into my local copy. And finally I
push those changes to the public repo. Only takes a few seconds. I even
have a trivial shell script for monaco-port that pulls changes from all
my remote repos into my local one, pushes that to my github repo, and
then makes sure each of my servers using monaco-port are up to date.
(It's really just a series of git pull/push commands)
But when it comes to svn... I've taken to the habit of running `ssh
<server> "cd /path/to/wiki; svn diff" | patch -p0`. Naturally I have to
svn up both copies before that to avoid any mishaps. And if I added a
new file, I have to do a separate explicit scp. And after that I have to
go back to the remote server, and svn up it again so that it understands
that those changes are no longer a dirty working copy. If I added a file
sometimes I have to deal with a slight mess. And if I forget to svn up,
have to deal with some blech from patch. etc...

Naturally of course, git is also beautiful for my disorganized working
copy. Right now trunktest has some uncommitted stuff I'm experimenting
with. And I usually end up transferring my changes to my local copy,
then reverting everything not relevant, and in the off case where two
experiments used the same file, I have to manually edit one of those out
(though I slightly streamlined that by piping svn diff <file> to a file,
running svn revert <file>, editing the patch and deleting the change I
don't want to commit, and then running the patch command; rather than
manually undoing the code). Git changes that extremely, since there is
an index I just explicitly say which parts I want to add to the index to
commit. And it works beautifully for files where two experiments work on
the same file, I can look through the file and explicitly say which diff
chunks I actually DO want to commit without having to edit the file. And
`git gui` really does make picking those diff chunks easier (yay for ssh
-X too).

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


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


roan.kattouw at gmail

Feb 14, 2011, 6:11 AM

Post #13 of 21 (1965 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

2011/2/13 Bryan Tong Minh <bryan.tongminh [at] gmail>:
> I agree... a bit. We should branch 1.18wmf1 immediately from trunk
> once things have calmed down a bit. However, this 1.18wmf1 does not
> necessarily need to be the base for 1.18. We can branch 1.18wmf2 from
> trunk again and so on, until the time that we want to release 1.18
> when we make a final 1.18wmfN branch and 1.18 branch.
>
+1

If we want to move to continuous integration (and I think the
consensus is we do, considering the mess we've made for ourselves by
deploying 9 months worth of commits and not knowing which of the
~15,000 new revisions killed the cluster the other day), our first
step should be to get closer to continuous integration, i.e. bring
deployment closer to trunk. By the time we deploy 1.17, trunk will
already be more than two months ahead. Of course this is because we
needed time to stabilize 1.17, which in turn was caused by the amount
of new code in it. Stabilizing and deploying 1.18wmf1 should take
considerably less time and allow us to get much closer to a continuous
integration model.

Roan Kattouw (Catrope)

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


jra at baylink

Feb 14, 2011, 8:48 AM

Post #14 of 21 (1964 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

----- Original Message -----
> From: "Jeroen De Dauw" <jeroendedauw [at] gmail>

> > +1 to migrate to a DVCS
>
> Unless I'm mistaken no one has actually suggested doing that.

0 + 1 = 1, right? :-)

Cheers,
-- jra

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


mhershberger at wikimedia

Feb 14, 2011, 9:27 AM

Post #15 of 21 (1964 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

Roan Kattouw <roan.kattouw [at] gmail> writes:

> 2011/2/13 Bryan Tong Minh <bryan.tongminh [at] gmail>:
>> I agree... a bit. We should branch 1.18wmf1 immediately from trunk
>> once things have calmed down a bit. However, this 1.18wmf1 does not
>> necessarily need to be the base for 1.18. We can branch 1.18wmf2 from
>> trunk again and so on, until the time that we want to release 1.18
>> when we make a final 1.18wmfN branch and 1.18 branch.
[ SNIP ]
> Stabilizing and deploying 1.18wmf1 should take considerably less time
> and allow us to get much closer to a continuous integration model.

It sounds like you guys are balking at this idea. I'm not familiar with
how the wmfN branches have worked, so some input would help.

If we have a 1.18 branch that is, as Brion has noted (and supported), a
day or two behind trunk at most, is there a reason that the we couldn't
branch wmfN from the rolling 1.18 branch? Or even just tag it when we
wanted to mark a WMF deployment?

Mark.

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


roan.kattouw at gmail

Feb 14, 2011, 10:35 AM

Post #16 of 21 (1963 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

2011/2/14 Mark A. Hershberger <mhershberger [at] wikimedia>:
> If we have a 1.18 branch that is, as Brion has noted (and supported), a
> day or two behind trunk at most, is there a reason that the we couldn't
> branch wmfN from the rolling 1.18 branch? Or even just tag it when we
> wanted to mark a WMF deployment?
>
That works for me too. wmfN branches can't be tagged from release
branches, they have a different structure so you need to run a script
that branches off the various parts, but otherwise this sounds good.

Roan Kattouw (Catrope)

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


Platonides at gmail

Feb 15, 2011, 8:11 AM

Post #17 of 21 (1946 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

Roan Kattouw wrote:
> 2011/2/14 Mark A. Hershberger <mhershberger [at] wikimedia>:
>> If we have a 1.18 branch that is, as Brion has noted (and supported), a
>> day or two behind trunk at most, is there a reason that the we couldn't
>> branch wmfN from the rolling 1.18 branch? Or even just tag it when we
>> wanted to mark a WMF deployment?
>>
> That works for me too. wmfN branches can't be tagged from release
> branches, they have a different structure so you need to run a script
> that branches off the various parts, but otherwise this sounds good.
>
> Roan Kattouw (Catrope)

I don't think there's a reason for maintaining that structure. It could
mimic the REL1_X structure, with some server rules to plug some bits.


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


hashar+wmf at free

Feb 15, 2011, 11:12 PM

Post #18 of 21 (1946 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On 14/02/11 15:11, Roan Kattouw wrote:
> By the time we deploy 1.17, trunk will
> already be more than two months ahead. Of course this is because we
> needed time to stabilize 1.17, which in turn was caused by the amount
> of new code in it.

What about stopping adding new code in trunk until the branch is
stable/live? Most new features / refactoring can probably held by their
authors for two or three months.


--
Ashar Voultoiz


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


innocentkiller at gmail

Feb 15, 2011, 11:53 PM

Post #19 of 21 (1945 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On Wed, Feb 16, 2011 at 2:12 AM, Ashar Voultoiz <hashar+wmf [at] free> wrote:
> On 14/02/11 15:11, Roan Kattouw wrote:
>> By the time we deploy 1.17, trunk will
>> already be more than two months ahead. Of course this is because we
>> needed time to stabilize 1.17, which in turn was caused by the amount
>> of new code in it.
>
> What about stopping adding new code in trunk until the branch is
> stable/live?  Most new features / refactoring can probably held by their
> authors for two or three months.
>

I've advocated a partial freeze before, but I've been convinced over
time that they're generally unhelpful. If a committer has good code
to put in, trunk should always be allowing it.

-Chad

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


markus at semantic-mediawiki

Feb 16, 2011, 12:42 AM

Post #20 of 21 (1945 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On 16/02/2011 07:53, Chad wrote:
> On Wed, Feb 16, 2011 at 2:12 AM, Ashar Voultoiz<hashar+wmf [at] free> wrote:
>> On 14/02/11 15:11, Roan Kattouw wrote:
>>> By the time we deploy 1.17, trunk will
>>> already be more than two months ahead. Of course this is because we
>>> needed time to stabilize 1.17, which in turn was caused by the amount
>>> of new code in it.
>>
>> What about stopping adding new code in trunk until the branch is
>> stable/live? Most new features / refactoring can probably held by their
>> authors for two or three months.
>>
>
> I've advocated a partial freeze before, but I've been convinced over
> time that they're generally unhelpful. If a committer has good code
> to put in, trunk should always be allowing it.

+1

Further arguments on this issue are in [1] under "Don’t freeze the trunk
for long periods" where freezing is associated with a significant loss
of contribution activity, even beyond the time that the trunk was frozen.

- Markus

[1] http://www.codesimplicity.com/post/open-source-community-simplified/

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


innocentkiller at gmail

Feb 16, 2011, 12:46 AM

Post #21 of 21 (1946 views)
Permalink
Re: Making code review happen in 1.18 [In reply to]

On Wed, Feb 16, 2011 at 2:53 AM, Chad <innocentkiller [at] gmail> wrote:
> I've advocated a partial freeze before, but I've been convinced over
> time that they're generally unhelpful. If a committer has good code
> to put in, trunk should always be allowing it.
>

As a followup, I'd like to qualify this statement with "use common
sense." The middle of a release cycle is *not* the time to begin
restructuring vast swaths of code, stylizing every last line, or
merging branches. It just makes merge conflicts more likely and
increases release/deployment overhead.

-Chad

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