[Pkg-mediawiki-devel] Converting repository to git (was: Consolidating MW branches)

[Jonathan Wiltshire]

TL,DR: my recent reorganisation had an ulterior motive, which is "let's 
follow upstream to git!"

On 2012-10-15 16:01, Thorsten Glaser wrote:
> On Mon, 15 Oct 2012, Jonathan Wiltshire wrote:
>> I planned soon to float the
>> idea of converting the repository to git altogether - since we're 
>> having
>> that conversation now anyway do you have any objections to that?
>
> I guess I don’t object, and with that layout, it can be done “right”.
> I *do* miss my RCS IDs then…
>
> But please don’t get any ideas about gbp or some such nonsense ☺
> It’s perfectly fine to do as we’re doing now and just run the normal
> Debian way “dpkg-buildpackage -rfakeroot -S -I -i” to make a source
> package to run through cowbuilder/sbuild.

I reserve the right to use gbp myself, but I won't force it on you :) 
Let's see how I get on with converting and building a workflow and talk 
about specific implementation/policy details later, if necessary.

>> I'm afraid I don't use bzr anywhere else to I'm not motivated to
>> convert MW to that.
>
> Well, bzr can use svn repositories. (And it can use svn 1.5, at 
> least,
> checkouts; it handles them as “special cases” of bzr bound branches.)
> So that was actually not needed.
>
> But I lost that fight in FusionForge, where it actually made sense,
> upstream, on last week’s IRL meeting, and in MediaWiki, a move to
> separate git repositories makes sense.
>
> There *is* one *big* exception: the mediawiki-extensions code as it
> stands right now can only pull from svn, and the unversioned/ top-
> level directory in our SVN is to throw stuff in that wasn’t in SVN
> to begin with. So it must be kept, for now. (Mid-term, since most
> extensions moved to git too, I guess Romain should think about some
> changes to mw-extensions to support that.)

With MW upstream now in git it does make sense (to me at least) to 
follow them, if nothing else to make cherry-picking more 
straightforward. It's kind of a pain at the moment. I see no reason to 
force MW-e to follow suit though; I envisage using git sub-modules for 
this so we can bring MW-e across when you're ready.

Romain has not been active in MW for some time now; I do not know if he 
plans to work in it again in the future. My hunch is not: Romain, do you 
have strong feelings about this?

>> Adam and I had a long look at it in person yesterday and reviewed 
>> all
>> the changes
>
> Ah, great. IRL meetings always help, yeah.
>
>> WRT the extensions... Do you need help keeping them up-to-date in 
>> the
>> longer term so we don't have this problem again?
>
> The problem here wasn’t lag on the extensions side, but rather that
> the extensions are specific to the MW versions, so I tracked the 1.15
> branch of these (and fixed them in-place) until we switched MW to 
> 1.19,
> then I switched those extensions to 1.19 (and fixed them). My delay 
> was
> mostly due to the mediawiki task being a complicated mess that was 
> not
> easily separated, plus some MW changes annoyed me on the FF side, 
> and,
> since my priority (I get paid for this, remember) was the FF side, I
> didn’t investigate MW without FF integration. (It helps that our FF
> flavour drives/enables most of the extensions.)

Well, I haven't had chance yet to fully digest how extensions get from 
upstream into our svn, so I'll put this on my list of things to look at 
when it's raining and see if we can streamline the process in some way.


-- 
Jonathan Wiltshire                                      jmw at debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

<directhex> i have six years of solaris sysadmin experience, from
             8->10. i am well qualified to say it is made from bonghits
			layered on top of bonghits