| 1 |
Dnia 2014-07-31, o godz. 06:53:50 |
| 2 |
Rich Freeman <rich0@g.o> napisał(a): |
| 3 |
|
| 4 |
> On Wed, Jul 30, 2014 at 2:15 PM, Andreas K. Huettel |
| 5 |
> <dilfridge@g.o> wrote: |
| 6 |
> >> I didn't bother replying before because I think my assumption was that |
| 7 |
> >> the council was clever enough to recognize silly when they saw it. |
| 8 |
> >> There never was a compelling argument for dispelling policy set by |
| 9 |
> >> groups in the general case and I'm not sure why the games group would |
| 10 |
> >> be considered to have lesser status in that regard. |
| 11 |
> > |
| 12 |
> > That actually doesn't address any of the issues brought up. |
| 13 |
> > |
| 14 |
> > The main question is, why should the games team have more status than other |
| 15 |
> > projects? |
| 16 |
> |
| 17 |
> ++ |
| 18 |
> |
| 19 |
> Generally I am in favor of giving projects that adhere to GLEP39 more |
| 20 |
> of a say in things than individual maintainers, but setting aside |
| 21 |
> QA/Comrel/Infra there aren't really any projects out there which claim |
| 22 |
> the same kind of scope as games. Amd64 might have a say over your |
| 23 |
> KEYWORDS, or systemd might want to install a text file you don't have |
| 24 |
> to look at, but none of them are going to basically rewrite your |
| 25 |
> ebuild, rename it, or tell you to get it out of the tree. The |
| 26 |
> Gnome/KDE projects don't care if you install an application that uses |
| 27 |
> libkde/etc, though you'd do well to coordinate if you don't want |
| 28 |
> random breakage on the next big change. |
| 29 |
|
| 30 |
Well, just to be clear, I don't mind GNOME/KDE claiming maintainership |
| 31 |
over core components of both DEs. Much like I don't even mind games |
| 32 |
team maintaining core components necessary for gaming like SDL. |
| 33 |
|
| 34 |
> If this were just an issue about games not accepting new members I |
| 35 |
> think that would be pretty trivial to fix, but I haven't gotten any |
| 36 |
> replies to my solicitation. So, this is more than whether the lead |
| 37 |
> responds to member requests. |
| 38 |
|
| 39 |
I'm afraid that games team is a bit like upside-down compared to other |
| 40 |
teams, and that is a social issue. While pretty much every other team |
| 41 |
is happy to accept contributors, games team feels -- lightly said -- |
| 42 |
unwelcome. I don't think you can really resolve it via jamming it new |
| 43 |
members by force. |
| 44 |
|
| 45 |
While I can't speak for the specific people, I think they are pretty |
| 46 |
much afraid that such an attempt would result in they feeling |
| 47 |
unwelcome, and possibly having no real status. |
| 48 |
|
| 49 |
> Some options open to the council are: |
| 50 |
> 1. Let the games project keep its policy, and anybody who wants to |
| 51 |
> change this has to join the project and call for elections (the |
| 52 |
> council can shoe-horn members onto the project if necessary). |
| 53 |
|
| 54 |
As I see it, this can have two results: |
| 55 |
|
| 56 |
a. games team elects new lead from current members, nothing changes, |
| 57 |
|
| 58 |
b. you shoe-horn enough new members to force a new lead amongst them, |
| 59 |
and existing members likely leave the project because of this. |
| 60 |
|
| 61 |
> 2. Directly tweak games policy but preserve the project and its |
| 62 |
> scope. So, games would still have to adhere to games project policy, |
| 63 |
> but the Council might change specific policies (use of eclass, group, |
| 64 |
> etc). |
| 65 |
|
| 66 |
This doesn't feel correct to have team policies set by Council, |
| 67 |
and again, the games team is likely to either ignore the decision or |
| 68 |
disband itself because of it. |
| 69 |
|
| 70 |
> 3. Restrict the games project scope, such as giving it authority if |
| 71 |
> the package maintainer elects to put it in the games herd. |
| 72 |
|
| 73 |
I'd dare say this is not something the Council needs to do but only to |
| 74 |
confirm. I'd be really happy to drop <herd>games</herd> from my game |
| 75 |
packages as soon as Council confirms that the games team isn't allowed |
| 76 |
to use that as an excuse to remove them or take over the maintainership. |
| 77 |
|
| 78 |
> Do we really have a sense for how much demand there is for change? #4 |
| 79 |
> (or something equivalent like nicely asking games to deal with this) |
| 80 |
> might make sense if we think this is really just 2-3 devs with an |
| 81 |
> opinion, and that there isn't a larger demand out there. |
| 82 |
|
| 83 |
It's not as simple as some people disliking how things are. I believe |
| 84 |
that the policies and behavior of the games team is the reason why |
| 85 |
people are getting discouraged from contributing. |
| 86 |
|
| 87 |
As a result, we have games team which can't handle the workload, few |
| 88 |
contributors which have patience to work with games team and a lot of |
| 89 |
people who would be happy to improve gaming experience in Gentoo but |
| 90 |
simply lost the will to or otherwise lost the ability to improve their |
| 91 |
ebuild skills. |
| 92 |
|
| 93 |
-- |
| 94 |
Best regards, |
| 95 |
Michał Górny |
Archives