future of the mediawiki extension?

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

[ Please Cc: me in these discussions ]

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

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.

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 ;-).

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,

On 2017-10-30 11:29:55, Matthieu Moy wrote:

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.

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

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 ;-)

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

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.

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.

On 2017-10-31 10:37:29, Junio C Hamano wrote:

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.

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

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.

On 2017-11-07 09:44:03, Junio C Hamano wrote:

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.

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

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 <git@matthieu-moy.fr> writes:

That is perfectly fine.