Suggestion for Gentoo packaging

[BMintern]

I'm sorry if this has been discussed before, but I would like to give my opinion on how I think the Gentoo ebuilds should be structured. I will first start by classifying users into three main categories:

1. People who just want to use the latest stable version
2. People who want the latest development release where nearly all of the MP players are (I will call this "the latest MP version".)
3. People who want the absolute latest version

All three groups, to me, are important to address. Fortunately, Gentoo has a three-tiered approach to ebuilds as well:

1. Stable
2. Keyword masking (~*)
3. Hard masking (an entry in /usr/portage/profiles/package.mask)

Personally, if I want the latest unstable version of a program, I add an entry into /etc/portage/package.keywords, and I fully expected to do the same with Wesnoth. However, due to the latest version being hard-masked, I had to instead add an entry to /etc/portage/package.unmask. This is an annoyance because, in general, hard-masking is used for ebuilds which could break other ebuilds, which fail to compile with various USE flag configurations, or which are generally unusable. This is not generally the case with the latest MP version; it doesn't break things, and it generally works, other than a few minor bugs here and there. This is precisely the reason for using ~* unstable; to help iron out those few bugs with bug reports and patch submissions.

Other than pedantry, what is the problem with using package.unmask for wesnoth? The problem I can see is that upon syncing, the latest MP version is removed from the tree and supplanted by the latest version. This means that after a system upgrade, a player could go several days (or up to a week, depending on how long binary packaging and server conversion takes) generally being unable to play MP. Now, this is just fine for a hard-masked package, but it is a problem when the de facto method for blocking beta wesnoth is to use package.mask.

Taking everything this into account, I would like to suggest a three-tiered structure for handling ebuilds:

1. The latest stable version is in the portage tree and is not blocked at all
2. The "latest MP version" is in the portage tree and is masked by a keyword ("~x86 ~amd64 ...")
3. The very latest version (when it is not the latest MP version) is in the portage tree and is masked by package.mask

So, for example, with the switch from 1.3.14 to 1.3.15, this is what I would do:

- (Remember that 1.3.14 is already simply blocked by ~*)
- Add an ebuild for 1.3.15 (with ~*)
- Add an entry to package.mask for 1.3.15
- When other binaries have been added and the 1.3.14 server is to be shutdown, remove 1.3.15 from package.mask and remove the 1.3.14 ebuild

Does that sound reasonable? I understand that it adds one more transaction for the Gentoo wesnoth maintainer (the last bullet point), but it is generally not a very difficult step, and I would be glad to help if this is necessary. I think that such a change would allow for the three distinct groups of users I mentioned at the outset, and the players who just want to keep up with the best MP version could easily do so by allowing the keyword-blocked ebuild to be installed.

One more thing... I would like to say thank you to the Gentoo maintainer. It may seem that I am complaining, but I am just trying to offer constructive criticism so that the Gentoo Wesnoth experience is as smooth as possible. Your work is truly appreciated.

[energyman76c]

~arch is for updates of known packages and new packages where the biggest bugs were ironed out who need some testing to make sure, that they don't eat harddrives.

package.mask is for development and testing versions (like alphas, betas, rcs, kde4.0) and known broken stuff.

So ~arch is at the moment reserved for 1.2.X updates - stuff that is from a stable relase and just need a (short) testing phase before sending it to the masses.
And where does 1.3.X belong? Well, it is a known unstable development tree which just entered beta-phase. This is by definition package.mask material.

And a simple unmask entry in /etc/portage/package.unmask is not that hard, is it?

[BMintern]

~arch is for updates of known packages and new packages where the biggest bugs were ironed out who need some testing to make sure, that they don't eat harddrives.

To me that sounds precisely like "the latest MP version" of wesnoth.

package.mask is for development and testing versions (like alphas, betas, rcs, kde4.0) and known broken stuff.

Which would be the very latest 1.3.X release that hardly anyone is playing yet.

So ~arch is at the moment reserved for 1.2.X updates - stuff that is from a stable relase and just need a (short) testing phase before sending it to the masses.

Is a change to 1.2.X likely to introduce any "harddrive eating" bugs? Aren't these fixes typically important security upgrades and bug fixes? Since this is such a short cycle anyways, does ~arch even do much at all? I would contend that these releases could easily be stable. Anyone who is going to be reporting bugs at the moment is going to be on 1.3.X, and no one will upgrade to 1.2.X until it is marked stable anyways, so having it marked ~arch seems to not be doing much at all at the moment.

And where does 1.3.X belong? Well, it is a known unstable development tree which just entered beta-phase. This is by definition package.mask material.

It may be called beta, but all the best (and many other) players do their MP playing on 1.3.X. Especially now that it is 1.4-beta, it seems to especially make sense to have this marked ~arch so that more people can be testing it and getting it prepared for stable. When I install the ~arch version of a package, I am expecting it to mostly work with the exception of a few bugs that I will report. This seems to be the case right now with 1.3.X.

And a simple unmask entry in /etc/portage/package.unmask is not that hard, is it?

It's not, until you sync the portage tree and install the latest version and are no longer able to play MP for about a week. I got on just now and there were only 3 or 4 others on the server. I am basically left with a useless Wesnoth installation; I can either downgrade to 1.2.8 or go through the hassle of downloading the tarball and installing manually. To me, it makes a lot more sense to maintain the best MP functionality (which isn't really "beta" at all... only the campaigns are, really) in some version which is in the portage tree. At the moment, that is not possible. My suggestion would change that so that the best MP version would be the ~arch version and the latest version would be the masked version, while the best campaign version would be stable. Is that sensible?

I understand that with most software, beta is a clear separation from stable. In Wesnoth, however, what you are calling beta actually contains a quite stable element which represents a huge portion of its functionality, and that is MP. When 40%+ of users are using the masked version of a program, that is a good indication that it should at the least be ~arch instead of masked.

My only suggestion would be to add an ewarn to the "best MP" ~arch version which says, "It is not recommended to start a campaign on this version. Use stable instead."

This would lead to a case where campaigners would run stable, MPers would run ~arch, and developers/hardcore helpers would unmask it. How else can someone who wants to play the best MP version follow the right version of Wesnoth? It's impossible at the moment.

[energyman76c]

~arch is for updates of known packages and new packages where the biggest bugs were ironed out who need some testing to make sure, that they don't eat harddrives.

To me that sounds precisely like "the latest MP version" of wesnoth.

no. 1.3.X is 'completly' new and unstable. Software like this does not belong in ~arch.

package.mask is for development and testing versions (like alphas, betas, rcs, kde4.0) and known broken stuff.

Which would be the very latest 1.3.X release that hardly anyone is playing yet.

which covers all 1.3.X versions. Every single one.

So ~arch is at the moment reserved for 1.2.X updates - stuff that is from a stable relase and just need a (short) testing phase before sending it to the masses.

Is a change to 1.2.X likely to introduce any "harddrive eating" bugs? Aren't these fixes typically important security upgrades and bug fixes? Since this is such a short cycle anyways, does ~arch even do much at all?

it is nice to catch 'version X eats savegames' before a package hits stable tree. And it is important to check, if version X still builds against the stable tree.

I would contend that these releases could easily be stable.

And 1.2.8 is stable. Was it almost from the beginning.

Anyone who is going to be reporting bugs at the moment is going to be on 1.3.X, and no one will upgrade to 1.2.X until it is marked stable anyways, so having it marked ~arch seems to not be doing much at all at the moment.

at the moment there is no ~arch wesnoth package. 1.2.8 is out for a while and stable, and 1.3.X is development and permanently hardmasked - because that is gentoo policy.

And where does 1.3.X belong? Well, it is a known unstable development tree which just entered beta-phase. This is by definition package.mask material.

It may be called beta, but all the best (and many other) players do their MP playing on 1.3.X. Especially now that it is 1.4-beta, it seems to especially make sense to have this marked ~arch so that more people can be testing it and getting it prepared for stable. When I install the ~arch version of a package, I am expecting it to mostly work with the exception of a few bugs that I will report. This seems to be the case right now with 1.3.X.

if you want to play 1.3.X or '1.4 beta' you can always unmask it. A single one line entry in package.unmask is enough. And it might be a surprise for you, but WHY should people try unstable, testing, beta software when the stable branch works well?

If you don't care about stability, you can unmask the development version.

That is called 'choice'. The default is safe, but if you want to, you can play with the bleeding edge.

This choice is almost gone, if you force the 1.3.X versions unto the masses.

And a simple unmask entry in /etc/portage/package.unmask is not that hard, is it?

It's not, until you sync the portage tree and install the latest version and are no longer able to play MP for about a week.

what are you talking about?
Maybe you should read the documentation again - especially the parts about unmasking a single version or unmasking all versions.

I got on just now and there were only 3 or 4 others on the server. I am basically left with a useless Wesnoth installation; I can either downgrade to 1.2.8 or go through the hassle of downloading the tarball and installing manually. To me, it makes a lot more sense to maintain the best MP functionality

and what is the 'best MP functionality' when the 1.3.14 server is shut down in a couple of days?

(which isn't really "beta" at all... only the campaigns are,

a lot of people play campaigns. I am playing ONLY campaigns and I am stumbling over problems every time. So from my POV 1.3.X is unstable. And look: the gentoo devs think the same and put it into package.mask so the people who know about the latest versions can unmask it, if they want.


And something else: nobody forces you to upgrade. If you want to stay at 1.3.13, 1.3.14 or 1.3.15 and you see a wesnoth update coming in your emerge -au world output (you check before updating, don't you?), copy the ebuild (even if it is removed from the tree it is still in /var/db/) into your local overlay and/or mask the version you don't want. Problem solved.

really) in some version which is in the portage tree. At the moment, that is not possible. My suggestion would change that so that the best MP version would be the ~arch version and the latest version would be the masked version, while the best campaign version would be stable. Is that sensible?

no. Which is the 'best MP' version? This can change in a matter of hours. And ~arch is simply not for unstable stuff. It is for testing stable candidates. And no 1.3.X version is a stable candidate. Everybody playing campaigns can tell you that. Why hurt ~arch users, just because you can't work with package.unmask?

I understand that with most software, beta is a clear separation from stable. In Wesnoth, however, what you are calling beta actually contains a quite stable element which represents a huge portion of its functionality, and that is MP.

if you want play MP, unmask the version you want. End of story. But everybody else should not be hurt, just because you can't use an editor. btw, have a look at the deps of 1.2.X and 1.3.X. See the difference?

When 40%+ of users are using the masked version of a program, that is a good indication that it should at the least be ~arch instead of masked.

100% of all gentoo KDE4.0 users use a hardmask version. Oh shock!

My only suggestion would be to add an ewarn to the "best MP" ~arch version which says, "It is not recommended to start a campaign on this version. Use stable instead."

again, the 'best MP' version can change on an hourly base. And what about the people who like to play the latest campaigns? Or the people who want stable versions AND MP?

My suggestion: everybody who wants a certain version can unmask it themselves in package.unmask. If the ebuild is gone, fetch it from /var/db or copy/rename the existing 1.3.X one.

This would lead to a case where campaigners would run stable, MPers would run ~arch, and developers/hardcore helpers would unmask it. How else can someone who wants to play the best MP version follow the right version of Wesnoth? It's impossible at the moment.

and what happens when 1.2.9 is released? Or 1.3.16 removes all files in /usr/share/games because of a bug?

[BMintern]

Wow, you sound really upset, and for some reason you even found the need to flame me. Thank you for taking my input into consideration.

at the moment there is no ~arch wesnoth package. 1.2.8 is out for a while and stable, and 1.3.X is development and permanently hardmasked - because that is gentoo policy.

This was my main observation. I observed three groups of users and three ebuild classifications, and yet only two classifications are really being fully utilized, stable and masked. A substantial group of users (those who want to play MP on the development branch) have no version they can track.

if you want to play 1.3.X or '1.4 beta' you can always unmask it. A single one line entry in package.unmask is enough. And it might be a surprise for you, but WHY should people try unstable, testing, beta software when the stable branch works well?

Yes, and I do have a line in package.unmask, that is easy enough. My problem is that I can either unmask games-strategy/wesnoth or =games-strategy/wesnoth-1.3.14. In the first case, I am upgraded to a version with no MP play for about a week. In the latter case, I am downgraded to a version which has a completely different gameplay and group of players.

If you don't care about stability, you can unmask the development version.

That is called 'choice'. The default is safe, but if you want to, you can play with the bleeding edge.

This choice is almost gone, if you force the 1.3.X versions unto the masses.

But the development version is basically stable, and I have never heard anyone refer to ~arch as "the masses".

what are you talking about?
Maybe you should read the documentation again - especially the parts about unmasking a single version or unmasking all versions.

I know how to do this. I've been running Gentoo for some time, and I obviously had the wherewithal to unmask the package in the first place. I'm trying to improve things here, not start an argument about my experience with Gentoo.

and what is the 'best MP functionality' when the 1.3.14 server is shut down in a couple of days?

It would then precisely be 1.3.15. Isn't that what I said?

a lot of people play campaigns. I am playing ONLY campaigns and I am stumbling over problems every time. So from my POV 1.3.X is unstable. And look: the gentoo devs think the same and put it into package.mask so the people who know about the latest versions can unmask it, if they want.

So if you want to play campaigns and not lose your saves, you could run stable. That is the case now, and that would remain the case with my proposal. So 1.3.X doesn't fit your needs... at least you have the option of playing stable and staying with 1.2.8. As far as 1.3.X being unstable, I have quite often heard ~arch referred to as "unstable".

And something else: nobody forces you to upgrade. If you want to stay at 1.3.13, 1.3.14 or 1.3.15 and you see a wesnoth update coming in your emerge -au world output (you check before updating, don't you?), copy the ebuild (even if it is removed from the tree it is still in /var/db/) into your local overlay and/or mask the version you don't want. Problem solved.

Of course I check before updating. I typically use "emerge -uDNav world", actually. The problem is the need to copy into an overlay for a week only to have to go back and delete it later. I don't like to spend my time with stupid administrative tasks like this. Even if things don't go "my way" and the "best MP version" remains masked, I would hope that it could at least remain in the portage tree until the server is shut down. That way, I could unmask the right version and no longer have the need to maintain an overlay.

no. Which is the 'best MP' version? This can change in a matter of hours. And ~arch is simply not for unstable stuff. It is for testing stable candidates. And no 1.3.X version is a stable candidate. Everybody playing campaigns can tell you that. Why hurt ~arch users, just because you can't work with package.unmask?

The "best MP" version is the one that most good players are playing on. It's usually the latest one with all of its binaries on the download page. Why not allow MP players a way to track the version they should be using? And thank you for the snide comment.

if you want play MP, unmask the version you want. End of story.

If it comes down to that, I will gladly do it. I would just prefer for the second-to-last dev version to remain in the portage tree at least until its MP server is shut down. Is that too much to ask?

But everybody else should not be hurt, just because you can't use an editor.

Thanks, again, for discounting my ideas with a pointless insult. I love meaningful, constructive discussions.

100% of all gentoo KDE4.0 users use a hardmask version. Oh shock!

My mistake, I was not aware of this. Then again, KDE relies on certain libraries which would affect a ton of other programs, resulting in build errors, etc. From what I have seen, this is not the case with wesnoth. Insulting sarcasm noted.

My suggestion: everybody who wants a certain version can unmask it themselves in package.unmask. If the ebuild is gone, fetch it from /var/db or copy/rename the existing 1.3.X one.

I am fine with the unmask suggestion if it must remain that way. Just please allow the old dev version to remain in the tree until the MP server is shut down.

Regardless of how this turns out, I am not exactly enamored with your reception of my ideas. I will gladly listen to facts, policy, and your own opinions, but when you decide to start questioning my ability to use a text editor or my OS of choice, I don't appreciate that. I'm not attacking you here, I'm just offering up my own (perhaps misguided) suggestion for how my experience (and by extension, hopefully others) could be smoother and more enjoyable. Why the need to attack me because of that?

Honestly, this discussion has opened my eyes to what people are talking about when they say they feel unwelcome in certain open source communities or when trying to offer help. I have never before been made to feel low for offering ideas and suggestions. My idea may have been misguided, but with a little bit of convincing, I will gladly change my suggestion to simply please keep the second-to-latest dev version in the portage tree until the server is shut down. Instead, I am left defending my intelligence and considering whether further contributions (bug reports, suggestions, code) are worth my time.

[energyman76c]

Wow, you sound really upset, and for some reason you even found the need to flame me. Thank you for taking my input into consideration.

I didn't intend to flame you. Sorry.

if you want to play 1.3.X or '1.4 beta' you can always unmask it. A single one line entry in package.unmask is enough. And it might be a surprise for you, but WHY should people try unstable, testing, beta software when the stable branch works well?

Yes, and I do have a line in package.unmask, that is easy enough. My problem is that I can either unmask games-strategy/wesnoth or =games-strategy/wesnoth-1.3.14. In the first case, I am upgraded to a version with no MP play for about a week. In the latter case, I am downgraded to a version which has a completely different gameplay and group of players.

>=games-strategy/wesnoth-1.3.14

and tadaa... the latest version is installed, if I want to.

But really, I don't understand your problem. Or how gentoo could help you. 'the best version for MP' is a fast moving target - and the best persons to know about it are the MP players. So they should unmask the versions they want to. It is not that hard.

If you don't care about stability, you can unmask the development version.

That is called 'choice'. The default is safe, but if you want to, you can play with the bleeding edge.

This choice is almost gone, if you force the 1.3.X versions unto the masses.

But the development version is basically stable, and I have never heard anyone refer to ~arch as "the masses".

there are a lot more ~arch users and package.keyword users then you migh texpect?

what are you talking about?
Maybe you should read the documentation again - especially the parts about unmasking a single version or unmasking all versions.

I know how to do this. I've been running Gentoo for some time, and I obviously had the wherewithal to unmask the package in the first place. I'm trying to improve things here, not start an argument about my experience with Gentoo.

ok, but you did not sound like you understand the differences between arch, ~arch and package.mask.

and what is the 'best MP functionality' when the 1.3.14 server is shut down in a couple of days?

It would then precisely be 1.3.15. Isn't that what I said?

so put >=games-strategy/wesnoth-1.3.14
into package.unmask.

a lot of people play campaigns. I am playing ONLY campaigns and I am stumbling over problems every time. So from my POV 1.3.X is unstable. And look: the gentoo devs think the same and put it into package.mask so the people who know about the latest versions can unmask it, if they want.

So if you want to play campaigns and not lose your saves, you could run stable. That is the case now, and that would remain the case with my proposal. So 1.3.X doesn't fit your needs... at least you have the option of playing stable and staying with 1.2.8. As far as 1.3.X being unstable, I have quite often heard ~arch referred to as "unstable".

~arch is unstable, not 'testing development versions' or 'known broken stuff'.

And something else: nobody forces you to upgrade. If you want to stay at 1.3.13, 1.3.14 or 1.3.15 and you see a wesnoth update coming in your emerge -au world output (you check before updating, don't you?), copy the ebuild (even if it is removed from the tree it is still in /var/db/) into your local overlay and/or mask the version you don't want. Problem solved.

Of course I check before updating. I typically use "emerge -uDNav world", actually. The problem is the need to copy into an overlay for a week only to have to go back and delete it later. I don't like to spend my time with stupid administrative tasks like this. Even if things don't go "my way" and the "best MP version" remains masked, I would hope that it could at least remain in the portage tree until the server is shut down. That way, I could unmask the right version and no longer have the need to maintain an overlay.

now we get somewhere. You could ask the maintainer of the ebuild to keep the elderly versions around for a while. Maybe he does?

no. Which is the 'best MP' version? This can change in a matter of hours. And ~arch is simply not for unstable stuff. It is for testing stable candidates. And no 1.3.X version is a stable candidate. Everybody playing campaigns can tell you that. Why hurt ~arch users, just because you can't work with package.unmask?

The "best MP" version is the one that most good players are playing on. It's usually the latest one with all of its binaries on the download page. Why not allow MP players a way to track the version they should be using? And thank you for the snide comment.

the snide comments are coming, because the whole thing is very tiresome. The 'best mp' version is the latest? So what is your problem? Latest is already in portage.

if you want play MP, unmask the version you want. End of story.

If it comes down to that, I will gladly do it. I would just prefer for the second-to-last dev version to remain in the portage tree at least until its MP server is shut down. Is that too much to ask?

as I wrote above, ask the Maintainer.

But everybody else should not be hurt, just because you can't use an editor.

Thanks, again, for discounting my ideas with a pointless insult. I love meaningful, constructive discussions.

100% of all gentoo KDE4.0 users use a hardmask version. Oh shock!

My mistake, I was not aware of this. Then again, KDE relies on certain libraries which would affect a ton of other programs, resulting in build errors, etc. From what I have seen, this is not the case with wesnoth. Insulting sarcasm noted.

the last wesnoth update 'forced' the update of three libs. Hmmm...

My suggestion: everybody who wants a certain version can unmask it themselves in package.unmask. If the ebuild is gone, fetch it from /var/db or copy/rename the existing 1.3.X one.

I am fine with the unmask suggestion if it must remain that way. Just please allow the old dev version to remain in the tree until the MP server is shut down.

Regardless of how this turns out, I am not exactly enamored with your reception of my ideas. I will gladly listen to facts, policy, and your own opinions, but when you decide to start questioning my ability to use a text editor or my OS of choice, I don't appreciate that. I'm not attacking you here, I'm just offering up my own (perhaps misguided) suggestion for how my experience (and by extension, hopefully others) could be smoother and more enjoyable. Why the need to attack me because of that?

Look at the thread. When did I start to become unfriendly?

When you still did not accept, that ~arch is usually not for beta stuff and just repeated yourself. I got tired and unfriendly.
Yes. I should not have done that. I am deeply sorry.

Honestly, this discussion has opened my eyes to what people are talking about when they say they feel unwelcome in certain open source communities or when trying to offer help. I have never before been made to feel low for offering ideas and suggestions. My idea may have been misguided, but with a little bit of convincing, I will gladly change my suggestion to simply please keep the second-to-latest dev version in the portage tree until the server is shut down. Instead, I am left defending my intelligence and considering whether further contributions (bug reports, suggestions, code) are worth my time.

when it comes to 'help the people' my track record is a lot better

Your 'keep the two latest versions' idea is not bad. Just ask the right person

[ivanovic]

Just to enlighten those who think "why is package XYZ not updated/changed/whatever" right aways:

You should think about how many people are currently maintaining the ~900 game related packages. Currently there are mainly two persons working on it. So there is no way for them to keep track with every release and yes, "just one extra step" for each of those packages would result in a *hell* of extra work. That is basically one very good reason not to have every development release of every game listed in portage included in the main tree (and even if it is as a hardmasked package). It would simply be by far too much work.

Regarding the "best version to use":
It is *impossible* to tell when the best time is to switch to the new version, since it does mainly depend on the date of release for the big binaries (OSX and Windows). As stated above, it is impossible for the games maintainers in the main tree to keep track with the development of all the games all the time, especially something this specific is impossible to keep track of.

Yes, I think your idea "please keep the last two releases in the tree" might be a good approach. Since this "just" means to delay deletion of content by one release.

@energyman76c
If you find any real bugs in campaigns in the dev version, please do post them in the bug tracker at http://bugs.wesnoth.org. I think currently the campaigns are even more stable in the development version than they are in the old stable version. The new version is especially better for the "campaigns only" players due to the huge amount of campaigns that are now shipped and due to the improved quality of the old ones.

[energyman76c]

I posted them in the forum

http://www.wesnoth.org/forum/viewtopic.php?t=19450

and

http://www.wesnoth.org/forum/viewtopic.php?t=19552

is just stuff I never saw in 1.2

but the first one is solved, the second one obscure...

[BMintern]

Thank you for your both for your explanations and (in energyman's case) for your apology. I understand where you are coming from and that I may have seemed noobish in wanting to come in and change things. I also understand now that the dev branch should remain hard masked.

As I said in my latest post, I don't have a problem with updating my package.unmask file to indicate which version to install. The real problem is when the version I "should" be playing is not in the portage tree. This was the case this last time when 1.3.15 was added and 1.3.14 removed, even though hardly anyone had moved from the .14 to the .15 MP server. Using >= in package.mask would still not fix this problem: it would install 1.3.15 prematurely (at least in terms of my wants).

What I really need to do is to just have an = entry in package.unmask which represents which version I think has the best MP play in it. To make my (and others') life easier, it would be nice if this version would remain in the portage tree. Clearly, once the MP server for an old version has been shut down, the version no longer has any utility and can safely be removed from the tree. My only request, then, is to not remove old dev versions from the portage tree until the MP server for that version has been shut down. Everything else about Gentoo maintenance can remain the same.

Thank you for this discussion; I would be quite grateful if this change in policy would be implemented. Is there a certain individual I should contact to make this request, or is ivanovic the Gentoo maintainer?

[energyman76c]

Thank you for your both for your explanations and (in energyman's case) for your apology. I understand where you are coming from and that I may have seemed noobish in wanting to come in and change things. I also understand now that the dev branch should remain hard masked.

As I said in my latest post, I don't have a problem with updating my package.unmask file to indicate which version to install. The real problem is when the version I "should" be playing is not in the portage tree. This was the case this last time when 1.3.15 was added and 1.3.14 removed, even though hardly anyone had moved from the .14 to the .15 MP server. Using >= in package.mask would still not fix this problem: it would install 1.3.15 prematurely (at least in terms of my wants).

What I really need to do is to just have an = entry in package.unmask which represents which version I think has the best MP play in it. To make my (and others') life easier, it would be nice if this version would remain in the portage tree. Clearly, once the MP server for an old version has been shut down, the version no longer has any utility and can safely be removed from the tree. My only request, then, is to not remove old dev versions from the portage tree until the MP server for that version has been shut down. Everything else about Gentoo maintenance can remain the same.

Thank you for this discussion; I would be quite grateful if this change in policy would be implemented. Is there a certain individual I should contact to make this request, or is ivanovic the Gentoo maintainer?

as ivanovic said your 'idea' amounts to more work. The devs would have to track which versions are the 'mp players' favorite and which could be removed.
There are lots of ebuilds and very view devs.

You can open a feature request with portage: ebuild versions in /etc/portage/package.unmask are not removed. But I don't think that this will happen (because it screws around with rsync).

The easiest way for all parties involved: copy the ebuild from /var/db//var/db/pkg/games-strategy/wesnoth-VERSION/ to your local overlay. Problem solved. No work for the devs.