This discussion is going in many directions. Let's clarify this for a second. There are two points here:
1) Updating the mappack of the Nadeo lobbies.
2) Discussion about the competitive mappacks, and that's the main point of the topic (cf 1st post).
For point 1), yes we will update it, but that's a detail.
Point 2) is more important and lots of questions remains unanswered.
The ESL mappack is a good example: some maps were wrong, so you (as a member of the community) dealt with the admin to update it, which is obivously a great thing since you're more competent than us for such discussions ; it doesn't prevent confusion though, as we are seeing here, since there's no place were it's clearly written what's the ESL mappack (it says one thing here, a different thing when you download it from the ESL website, and so on).
That confusion doesn't help in organizing the choosing of maps and mappacks on lobbies and servers. So the question remains: how to organize the mappacks votes, discussions and updates, taking all actors and contraints into considerations?
One can argue "the ESL admin just have to update its page". One can argue "nadeo just have to update their lobby". One can argue "that server hoster just have to update their server". But it doesn't make for a robust solution. One can also argue "Nadeo just have to do everything themselves", but then again, that's not a robust long-term solution for various reasons which have already been discussed ; and it also doesn't mean we will never do nothing about this either. But right now, we do have other priorities.
So let's be constructive, and think about various solutions (and by let's I don't mean only you dreamy, but everyone involved with their own constraints).
For instance: what about a github repo with maps/matchsettings? so that you have:
- Commit history
- Releases and changelogs and zips
- Pull requests with discussion
- etc.
I'm sure there are tons of other ways.
Are we on the same page?
EDIT: I said "think about various solutions" but I should have said: it's cool to think about solutions, but it's even better to think about "use cases" and constraints first, and everything together will lead to solutions ; to give a little bit of food for thought, cf this:
https://secure.phabricator.com/book/pha ... _requests/