Page MenuHomePhabricator

Merge iwtransclusion branch into phase3
Closed, ResolvedPublic

Description

Needs doing... So we can have the niceties... considering it's over a year later :/


Version: unspecified
Severity: enhancement

Details

Reference
bz28673

Related Objects

StatusAssignedTask
DuplicateNone
OpenNone
OpenNone
OpenNone
Declined Reguyla
ResolvedNemo_bis
OpenNone
OpenNone
DuplicateNone
StalledNone
OpenNone
StalledNone
ResolvedLegoktm
ResolvedNone
DeclinedKrenair
OpenNone
DuplicateNone
DeclinedNone
ResolvedNone
OpenNone
OpenNone
ResolvedNone
OpenNone
ResolvedCatrope
ResolvedNone

Event Timeline

bzimport raised the priority of this task from to High.
bzimport set Reference to bz28673.
bzimport added a subscriber: Unknown Object (MLST).
Reedy created this task.Apr 23 2011, 11:47 AM

This is a dupe, right? Ah, no matter. We'll talk about it in triage. It does need to be done ASAP.

Reedy added a comment.Apr 23 2011, 5:32 PM

I couldn't find one for it...

It's the other GSOC project we don't want to let rot too far. Needs a bit of work doing, but IIRC it's nothing too major

Bug #9890 is the one I was thinking of.

(In reply to comment #3)

Bug #9890 is the one I was thinking of.

I don't see how that could be ever be classed as a dup... Two separate things, createion of a feature and bringing a branch up into trunk.

Has anyone {merged up from/brought the branch up to} trunk recently? that would make it easier?

The last comment (from me) clearly discusses getting the code from the GSOC into trunk. But its fine to have this bug tracking only the merge process.

(In reply to comment #3
Has anyone {merged up from/brought the branch up to} trunk recently? that would
make it easier?

IIRC, When I discussed this with Roan and Peter, Peter said that was something he was going to do. But yes, we need to check. He should be getting this comment in his email.

Could do with checking on, and fixing up of the fixme revisions...

r69730, r70576

peter017 wrote:

(In reply to comment #6)

Could do with checking on, and fixing up of the fixme revisions...

r69730, r70576

Those were fixed a long time ago, in r69746 r69781 and r70764 (see the "Follow-up revisions" section).

As for merging up from the trunk: ok, I'll do that, but I don't have my computer with me this week-end, so, it will be next Tuesday evening...

Aren't we supposed to branch off 1.18 soon? Shouldn't this be merged into trunk after the 1.18 branch point?

(In reply to comment #8)

Aren't we supposed to branch off 1.18 soon? Shouldn't this be merged into trunk
after the 1.18 branch point?

Possibly. Maybe

Still needs dragging upto date either way

I'm actually nearly up to date with this. At r86568 at the moment, I stopped as this last 1000 was taking an age due to all the translation changes

Will bring it up to trunk and then do a sanity check

There's been some conflicts in random files (ie random language files), so I will pull them back across

AFAIK, I shouldn't have introduced many/any issues, but these things are never 100%, so will need some sanity checking when merging it back across, a few changes may need forward porting

Reedy added a comment.Apr 28 2011, 4:08 PM

Screw SVN, I give up with that branch before bringing it fully to head.

Happy-melon and others have started some fairly large parser and what not changes... These seemed to be conflicting in some cases, but fixing them doesn't seem to have removed all the conflict markers, and I noticed on clearing up later commits they're still there.

Might be easier to branch freshly, forward merge the changes (manually, or semi automagically), and then push out to trunk (even if it then gets reverted out for 1.18)

Reedy added a comment.Apr 29 2011, 1:05 AM

Redone it all in a new folder

A lot quicker, easier and better. Merging the conflicts on a revision by revision basis really makes it nice

Take a look at http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&path=%2Fbranches%2Fiwtransclusion%2Fphase3v2