Re: packages in games team SVN where Maintainer != games team
2008/3/7, Gerfried Fuchs <rhonda@deb.at>:
> > In this way: http://qa.debian.org/developer.php?login=pkg-games-devel%40lists.alioth.debian.org&comaint=yes
>
> Alright. Just wondering, does comaint=yes gain anything in here?
Oh, it was just an example, don't be so picky :P
> With the ammount of things that fly around and the increasing of
> packages it gets pretty tedious to track things here. It just doesn't
> scale and I can't really blame people only following the one or two
> packages they care about and ignore the others ...
Yup, that makes sense, but what do you propose? We might have
different sub-groups with the games sharing similar packaging matters?
I mean, probably the current system doesn't scale, but having everyone
managing the packages on their own just, well, it's not a Team
anymore, I guess :P So if you think scaling is a problem, we might
start to think about how to handle it properly.
> Yes, but wesnoth is the package I feel most strongly attached to and
> have a pretty strong opinion about. It was just the one of those listed
> with not the team as maintainer address that I am attached to, so I
> mentioned it.
>
> The rest is more a generic thing indeed, but it might be a reason for
> people to /not/ wanting to sent the maintaiiner field to the team and
> thus have the bugs get sent to the list if such queries about how bugs
> are addressed by certain people get unanswered and that there is no
> general concensus on how the BTS should get used, how things are tracked
> and in what way we communicate with our users.
There might be a reason for that, I know, that's why I ask. We might
have different directories, one for co-maintained games and another
one for restricted ones who don't want the Team to take care of but
want to just use our SVN for it? That way, anyone would know if they
can help managing a game package without getting worried about whether
the maintainer will be offended or not.
> > In any case, that doesn't have much to do with the maintainer label in
> > control, but more with SVN access and the Team coordination, doesn't
> > it?
>
> If it goes about bug reports, it has mainly to do with the maintainer
> label of the package and not at all with SVN access, the bts doesn't has
> any access control. About team coordination, I'm all for it but to be
> honest I only se a little bit happening - which I'm totally thankful
> for, but I would have hoped in some areas for a bit of more
> coordination; though I have to admit, I lack some in that area myself.
OK, then we have to decide what kind of cooperation and collaborative
maintenance we want to have, then set up the infrastructure
accordingly. Discussion is open, ideas are welcome :)
Miry
Reply to: