| 1 |
Bryan Østergaard wrote: |
| 2 |
> A. ~arch keywords are supposed to be carried over to new versions unless |
| 3 |
> we're talking about big rewrites or similar (so old versions doesn't |
| 4 |
> have to linger around in portage tree at all). |
| 5 |
right, we all agree :) |
| 6 |
|
| 7 |
> B. If we're complaining about MIPS team not being able to ~mips kde-meta |
| 8 |
> on time we need to remove all the arch teams that falls behind from |
| 9 |
> time. I think that leaves us with maybe x86, amd64, sparc as *the only* |
| 10 |
> arch teams allowed to keyword kde-meta which is completely insane and an |
| 11 |
> insult to our users. |
| 12 |
every arch team is allowed to keyword kde-meta, just they should not |
| 13 |
complain about their keywords not being on bumps when they are late. |
| 14 |
|
| 15 |
Keyword<->ebuild separation allows to clearly show the arch teams that |
| 16 |
they are responsible and allows the developers not to get into conflict |
| 17 |
here. It clearly would have avoided the recent conflict. |
| 18 |
|
| 19 |
The problem is with ebuild developers like me having no means to get |
| 20 |
arch teams to keyword stuff yet we are responsible if something fails |
| 21 |
and we get bugs assigned. |
| 22 |
|
| 23 |
> [remove kde-meta talk] |
| 24 |
> |
| 25 |
> Besides that splitting keywords out from ebuilds doesn't solve |
| 26 |
> *anything* at all related to this as the ebuilds *still* have to stay |
| 27 |
> around as long as they have keywords. Just like current policy says. |
| 28 |
> Moving metadata to another place doesn't change that at all. |
| 29 |
|
| 30 |
yeah. A script for removing all ebuilds that are allowed to be removed |
| 31 |
by policy would be cool. Sadly I don't have one currently :( |
| 32 |
|
| 33 |
We can for example also offer x86-only sync trees without all the |
| 34 |
ebuilds that are only relevant to the other arches. |
| 35 |
|
| 36 |
Best regards, |
| 37 |
Stefan |
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-dev@g.o mailing list |
Archives