| 1 |
Hi! |
| 2 |
|
| 3 |
> > I will do it if I can get some kind of assurance from our developers |
| 4 |
> >that the gentoo-ebuild and especially the gentoo-user mailing lists |
| 5 |
> >will be moderated by at least some of the developers. Dan Armak can |
| 6 |
> >handle a good amount of gentoo-ebuild, but I really need someone |
| 7 |
> >who's willing to moderate gentoo-user. A moderator for gentoo-dev |
| 8 |
> >would be nice too :) |
| 9 |
|
| 10 |
What do you mean by moderate the list? |
| 11 |
I think that all developers should listen to all three lists, perhaps |
| 12 |
not everyone has to listen to -ebuild (would probably be enough with |
| 13 |
one developer for each team). |
| 14 |
|
| 15 |
> > Also, I'll be creating team mailing lists and the # Author: comment |
| 16 |
> >in all new ebuilds will specify the team, i.e.: system@g.o, |
| 17 |
> >infrastructure@g.o, etc. It's too hard to track the specifc |
| 18 |
> >author anyway; we'll just track the team. It'll be up to the team to |
| 19 |
> >keep their own internal organization for all the ebuilds that belong |
| 20 |
> >to them. We'll probably change the # Author: comment to # |
| 21 |
> >Maintainer: system@g.o, for example. This'll work for me. |
| 22 |
|
| 23 |
This split is going to be needed in the future, but I don't see why it |
| 24 |
needs to happend right now, this split can happend when it's needed. |
| 25 |
I think that for now the -dev, -user and -ebuild will be enough. |
| 26 |
|
| 27 |
> How does this combine with the ebuild categories? After all it makes |
| 28 |
> sense that e.g. the desktop team is resposible for kde-* and |
| 29 |
> gnome-*. If a developer from another team adds an ebuild to these |
| 30 |
> categories, should his team be named as maintainer? Should he transfer |
| 31 |
> maintanence to a desktop developer? What about developers who are part |
| 32 |
> of more than one team? |
| 33 |
|
| 34 |
We have to write down somewhere which teams will handle what |
| 35 |
packages. |
| 36 |
|
| 37 |
But the maintaining team shouldn't have anything todo with who's |
| 38 |
creating the ebuild. It should be the team into which the package |
| 39 |
falls. This also solves the question about a developer part of more |
| 40 |
then one team. |
| 41 |
|
| 42 |
After all it's the team that is responsible to make the ebuild working |
| 43 |
before a release. I also think that (as stated by pm in another |
| 44 |
thread) when a developer is creating an ebuild that goes into another |
| 45 |
team he should put it into incoming for the correct team to include |
| 46 |
into the CVS tree. |
| 47 |
|
| 48 |
Regards, |
| 49 |
Mikael Hallendal |
| 50 |
|
| 51 |
-- |
| 52 |
Mikael Hallendal micke@×××××××××××.se |
| 53 |
CodeFactory AB http://www.codefactory.se/ |
| 54 |
Office: +46 (0)8 587 583 05 Cell: +46 (0)709 718 918 |
Archives