future of the mediawiki extension?

future of the mediawiki extension?

[Antoine Beaupré]

Hi,

First thanks for the excellent feedback regarding the mediawiki
extension, it's great that obscure extensions like this see such
excellent reviews.

I think, however, it would be good to have a discussion about the future
of that extension in Git. The extension has a bit of a hybrid presence -
it is partly in git core (as a contrib, but still) and partly on GitHub
here:

https://github.com/Git-Mediawiki/Git-Mediawiki/

This leads to some confusion as to where the changes should be
made. Some people make changes straight on GitHub by forking the above
repo, others fork the Git repo, and very few actually send the patches
here, on this mailing list.

There was a discussion last year about moving the module out of git core
and onto its own repository again:

https://github.com/Git-Mediawiki/Git-Mediawiki/issues/34

There is also a discussion on releasing the code to CPAN:

https://github.com/Git-Mediawiki/Git-Mediawiki/issues/18

It should also be mentioned that this contrib isn't very active: I'm not
part of the GitHub organization, yet I'm probably the one that's been
the most active with patches in the last year (and I wasn't very active
at all). There's an issue on GitHub about this as well:

https://github.com/Git-Mediawiki/Git-Mediawiki/issues/33

So, what should be done about this contrib? Should it stay in Git core?
Or should it be punted back to the community and managed on GitHub?

Please avoid "mailing list vs GitHub" flamewars and keep to the topic of
this specific contrib's future. :)

Thanks!

A.

PS: personally, I don't care much either way. It certainly seem that I
get way better feedback here than I previously got on GitHub, but that
could be because of the hybrid way things are setup in the first
place...
-- 
To punish me for my contempt for authority, fate made me an authority myself.
                       - Albert Einstein

Re: future of the mediawiki extension?

[Matthieu Moy]

[ Please Cc: me in these discussions ]

Antoine Beaupré <anarcat@debian.org> writes:

> I think, however, it would be good to have a discussion about the future
> of that extension in Git. The extension has a bit of a hybrid presence -
> it is partly in git core (as a contrib, but still) and partly on GitHub
> here:
>
> https://github.com/Git-Mediawiki/Git-Mediawiki/

The initial plan was to use Git's contrib/ subdirectory to get more of
the Git community involved in its development, and avoid making it a
personal toy.

Initially, Git-Mediawiki is both a personnal project and a student's
project (most of the code was written by students as part of an Ensimag
project under my supervision, with strong interaction with the Git
community).

It did work well in the first times of the project, there were very
fruitfull interactions between Git-Mediawiki and Git. Some issues raised
while developing Git-Mediawiki led to improvements in the remote-helper
mechanism in Git. Some code written for Git-Mediawiki ended up in Git
(the Perl layer for the credential helpers at least). I think this would
have been harder if Git-Mediawiki was a separte project.

However, the rest of the plan did not work that well. I thought having
the code in contrib/ would help keeping the project alive if I became
inactive. It's been a while I didn't have enough time-budget to work on
the project, and the git.git review mechanism has actually blocked a lot
of contributors. Patches get posted here and there but no one takes time
for a proper submission here, and when this happens contributors give up
after the first round of review instead of re-rolling.

So, my conclusion is that a simpler submission mechanism (GitHub's
pull-requests) and a less picky code review would help Git-Mediawiki.

From previous discussions, I think Junio will agree with that: he's
reluctant to keeping too much stuff in contrib/ and usally prefers
external projects.

> It should also be mentioned that this contrib isn't very active: I'm not
> part of the GitHub organization, yet I'm probably the one that's been
> the most active with patches in the last year (and I wasn't very active
> at all).

FYI, I'm no longer using Mediawiki as much as I did, and I don't really
use Git-Mediawiki anymore.

The main blocking point to revive Git-Mediawiki is to find a new
maintainer (https://github.com/Git-Mediawiki/Git-Mediawiki/issues/33). I
believe I just found one ;-).

> Please avoid "mailing list vs GitHub" flamewars and keep to the topic of
> this specific contrib's future. :)

Note that being a separate project doesn't mean there can't be any
interaction with this list. Requests for reviews for separate projects
are usually welcome even though they don't happen often here.

There's also a hybrid solution used by git-multimail: have a copy of the
code in git.git, but do the development separately. I'm not sure it'd be
a good idea for Git-Mediawiki, but I'm mentionning it for completeness.

Regards,

-- 
Matthieu Moy
https://matthieu-moy.fr/

Re: future of the mediawiki extension?

[Antoine Beaupré]

On 2017-10-30 11:29:55, Matthieu Moy wrote:
>> It should also be mentioned that this contrib isn't very active: I'm not
>> part of the GitHub organization, yet I'm probably the one that's been
>> the most active with patches in the last year (and I wasn't very active
>> at all).
>
> FYI, I'm no longer using Mediawiki as much as I did, and I don't really
> use Git-Mediawiki anymore.
>
> The main blocking point to revive Git-Mediawiki is to find a new
> maintainer (https://github.com/Git-Mediawiki/Git-Mediawiki/issues/33). I
> believe I just found one ;-).

Eh. I assume you mean me here. As I hinted at in another thread, I am
not sure I can commit to leading the project - just scratching an
itch. But I may be able to review pull requests and make some releases
from time to time... I probably won't work on code or features I don't
need unless someone funds my work or something. ;)

We'll see where the community takes us, I guess... Always better to have
more than one maintainer, anyways, just for the bus factor... Worst
case, I'll delegate to a worthy successor. :)

A.

-- 
Votre silence ne vous protégera pas.
                        - Audrey Lorde

Re: future of the mediawiki extension?

[Junio C Hamano]

Antoine Beaupré <anarcat@debian.org> writes:

> On 2017-10-30 11:29:55, Matthieu Moy wrote:
>>> It should also be mentioned that this contrib isn't very active: I'm not
>>> part of the GitHub organization, yet I'm probably the one that's been
>>> the most active with patches in the last year (and I wasn't very active
>>> at all).
>>
>> FYI, I'm no longer using Mediawiki as much as I did, and I don't really
>> use Git-Mediawiki anymore.
>>
>> The main blocking point to revive Git-Mediawiki is to find a new
>> maintainer (https://github.com/Git-Mediawiki/Git-Mediawiki/issues/33). I
>> believe I just found one ;-).
>
> Eh. I assume you mean me here. As I hinted at in another thread, I am
> not sure I can commit to leading the project - just scratching an
> itch. But I may be able to review pull requests and make some releases
> from time to time... I probably won't work on code or features I don't
> need unless someone funds my work or something. ;)
>
> We'll see where the community takes us, I guess... Always better to have
> more than one maintainer, anyways, just for the bus factor... Worst
> case, I'll delegate to a worthy successor. :)

Heh, when you are talking about going from effectively 0 to 1 (or a
halftime), you are way too early to worry about the bus factor ;-)

Re: future of the mediawiki extension?

[Junio C Hamano]

Matthieu Moy <git@matthieu-moy.fr> writes:

> So, my conclusion is that a simpler submission mechanism (GitHub's
> pull-requests) and a less picky code review would help Git-Mediawiki.
>
> From previous discussions, I think Junio will agree with that: he's
> reluctant to keeping too much stuff in contrib/ and usally prefers
> external projects.
>
> Note that being a separate project doesn't mean there can't be any
> interaction with this list. Requests for reviews for separate projects
> are usually welcome even though they don't happen often here.

I would say that Git and its ecosystem has become mature enough that
any add-on project that aims to make life more pleasant for those
who use Git and $X together for any value of $X can now stand on its
own, without being under Git umbrella like back in the days when the
number of people who know and/or use Git were small.  The world is
no longer constrained by small number of people with Git expertise,
and it has become practical to discuss their project among those who
are familiar with (and motivated to learn) *both* Git and $X without
necessarily involving Git 'core' people.

Participants of this list will continue to strive to keep this list
the place for people to come for Git expertise.  But this list may
no longer be the best place to find those who are experts on *both*
Git and $X.  And that is why I think an external project standing on
its own would be more preferrable these days.

> There's also a hybrid solution used by git-multimail: have a copy of the
> code in git.git, but do the development separately. I'm not sure it'd be
> a good idea for Git-Mediawiki, but I'm mentionning it for completeness.

I think the plan was to make code drop from time to time at major
release points of git-multimail, but I do not think we've seen many
updates recently.

Re: future of the mediawiki extension?

[Antoine Beaupré]

On 2017-10-31 10:37:29, Junio C Hamano wrote:
>> There's also a hybrid solution used by git-multimail: have a copy of the
>> code in git.git, but do the development separately. I'm not sure it'd be
>> a good idea for Git-Mediawiki, but I'm mentionning it for completeness.
>
> I think the plan was to make code drop from time to time at major
> release points of git-multimail, but I do not think we've seen many
> updates recently.

I'd be okay with a hybrid as well. It would require minimal work on
Git's side at this stage: things can just stay as is until there's a new
"release" of the mediawiki extension and at that point you can decide if
you merge it all in or if you drop it in favor of the contrib.

I think it's also fine to punt it completely out to the community.

Either way, I may have time to do some of that work in the coming month,
so let me know what you prefer, I guess you two have the last word
here. The community, on Mediawiki's side, seem to mostly favor GitHub.

A.

-- 
Never attribute to malice that which can be adequately explained by
stupidity, but don't rule out malice.
                         - Albert Einstein

Re: future of the mediawiki extension?

[Junio C Hamano]

Antoine Beaupré <anarcat@debian.org> writes:

> On 2017-10-31 10:37:29, Junio C Hamano wrote:
>>> There's also a hybrid solution used by git-multimail: have a copy of the
>>> code in git.git, but do the development separately. I'm not sure it'd be
>>> a good idea for Git-Mediawiki, but I'm mentionning it for completeness.
>>
>> I think the plan was to make code drop from time to time at major
>> release points of git-multimail, but I do not think we've seen many
>> updates recently.
>
> I'd be okay with a hybrid as well. It would require minimal work on
> Git's side at this stage: things can just stay as is until there's a new
> "release" of the mediawiki extension and at that point you can decide if
> you merge it all in or if you drop it in favor of the contrib.
>
> I think it's also fine to punt it completely out to the community.
>
> Either way, I may have time to do some of that work in the coming month,
> so let me know what you prefer, I guess you two have the last word
> here. The community, on Mediawiki's side, seem to mostly favor GitHub.

I guess I shouldn't leave this thread hanging.

As contrib/README says, the "owners" of an area in contrib/ has the
ultimate say and control over the area, and for contrib/mw-to-git,
the "owners" have always been Matthieu, at least to me.

As he made it clear earlier in this thread that (1) he sees you as a
steady hand that can help guide the tool forward as its new "owner",
and (2) he thinks Git-Mediawiki will be helped by being an
independent project hosted at GitHub, now you have the say ;-)

A few topics from you that are already on list may want to go
through to 'master' as any other topics, but from there on, I am
fine with the development of Git-Mediawiki primarily done as a
separate project, optionally giving contrib/mw-to-git/ occasional
update dumps.  You could even choose to remove contrib/mw-to-git/*
except for git-remote-mediawiki.txt that says that the tool's main
development effort happens at GitHub to redirect people, if you
think that would reduce potential confusion.

I am also OK to serve as a patch monkey and keep going; I won't be
picking up patches to contrib/mw-to-git/ unless you (and others)
review them, though.

Re: future of the mediawiki extension?

[Antoine Beaupré]

On 2017-11-07 09:44:03, Junio C Hamano wrote:
> Antoine Beaupré <anarcat@debian.org> writes:
>
>> On 2017-10-31 10:37:29, Junio C Hamano wrote:
>>>> There's also a hybrid solution used by git-multimail: have a copy of the
>>>> code in git.git, but do the development separately. I'm not sure it'd be
>>>> a good idea for Git-Mediawiki, but I'm mentionning it for completeness.
>>>
>>> I think the plan was to make code drop from time to time at major
>>> release points of git-multimail, but I do not think we've seen many
>>> updates recently.
>>
>> I'd be okay with a hybrid as well. It would require minimal work on
>> Git's side at this stage: things can just stay as is until there's a new
>> "release" of the mediawiki extension and at that point you can decide if
>> you merge it all in or if you drop it in favor of the contrib.
>>
>> I think it's also fine to punt it completely out to the community.
>>
>> Either way, I may have time to do some of that work in the coming month,
>> so let me know what you prefer, I guess you two have the last word
>> here. The community, on Mediawiki's side, seem to mostly favor GitHub.
>
> I guess I shouldn't leave this thread hanging.
>
> As contrib/README says, the "owners" of an area in contrib/ has the
> ultimate say and control over the area, and for contrib/mw-to-git,
> the "owners" have always been Matthieu, at least to me.
>
> As he made it clear earlier in this thread that (1) he sees you as a
> steady hand that can help guide the tool forward as its new "owner",
> and (2) he thinks Git-Mediawiki will be helped by being an
> independent project hosted at GitHub, now you have the say ;-)
>
> A few topics from you that are already on list may want to go
> through to 'master' as any other topics, but from there on, I am
> fine with the development of Git-Mediawiki primarily done as a
> separate project, optionally giving contrib/mw-to-git/ occasional
> update dumps.  You could even choose to remove contrib/mw-to-git/*
> except for git-remote-mediawiki.txt that says that the tool's main
> development effort happens at GitHub to redirect people, if you
> think that would reduce potential confusion.
>
> I am also OK to serve as a patch monkey and keep going; I won't be
> picking up patches to contrib/mw-to-git/ unless you (and others)
> review them, though.

Makes sense. I think that, for now, I'll keep some sort of status quo
and "copy" (as opposed to "move") development over to GitHub. We can
then make dumps when new releases are done over there. If that proves
impractical because of changes in the build system or some other reason,
I'll send patches to clear the code from core and replace it with the
suggested .txt file.

Thanks!

A.

-- 
Like slavery and apartheid, poverty is not natural. It is man-made and
it can be overcome and eradicated by the actions of human
beings. Overcoming poverty is not a gesture of charity. It is an act
of justice.             - Nelson Mandela

Re: future of the mediawiki extension?

[Matthieu Moy]

"Junio C Hamano" <gitster@pobox.com> wrote:

> I think the plan was to make code drop from time to time at major
> release points of git-multimail, but I do not think we've seen many
> updates recently.

I realize I didn't answer this point. The reason you didn't see any
update recently is just that there haven't been any release and
actually not much development for a while on git-multimail.

I still have a list of "would be nice to have" features, but it seems
users are essentially happy with git-multimail as it is (or at least,
aren't unhappy enough to send patches or discuss interesting issues),
I haven't received any bug report or pull-requests for a long time.

But I still do maintain git-multimail and I will continue updating it
in git.git.

-- 
Matthieu Moy
https://matthieu-moy.fr/

Re: future of the mediawiki extension?

[Junio C Hamano]

Matthieu Moy <git@matthieu-moy.fr> writes:

> I realize I didn't answer this point. The reason you didn't see any
> update recently is just that there haven't been any release and
> actually not much development for a while on git-multimail.

That is perfectly fine.

> I still have a list of "would be nice to have" features, but it seems
> users are essentially happy with git-multimail as it is (or at least,
> aren't unhappy enough to send patches or discuss interesting issues),
> I haven't received any bug report or pull-requests for a long time.
>
> But I still do maintain git-multimail and I will continue updating it
> in git.git.