Last modified: 2014-11-17 10:35:33 UTC
Needs doing... So we can have the niceties... considering it's over a year later :/
This is a dupe, right? Ah, no matter. We'll talk about it in triage. It does need to be done ASAP.
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
(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
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)
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
r95396
