1 |
On Mon, Feb 19, 2007 at 03:13:00PM +0100, Stefan Schweizer wrote: |
2 |
> Bryan Østergaard wrote: |
3 |
> >A. ~arch keywords are supposed to be carried over to new versions unless |
4 |
> >we're talking about big rewrites or similar (so old versions doesn't |
5 |
> >have to linger around in portage tree at all). |
6 |
> right, we all agree :) |
7 |
> |
8 |
> >B. If we're complaining about MIPS team not being able to ~mips kde-meta |
9 |
> >on time we need to remove all the arch teams that falls behind from |
10 |
> >time. I think that leaves us with maybe x86, amd64, sparc as *the only* |
11 |
> >arch teams allowed to keyword kde-meta which is completely insane and an |
12 |
> >insult to our users. |
13 |
> every arch team is allowed to keyword kde-meta, just they should not |
14 |
> complain about their keywords not being on bumps when they are late. |
15 |
Of course they should complain about dropped keywords. Policy says to |
16 |
keep ~arch keywords when doing bumps unless there's a very good reason |
17 |
not to (like a complete rewrite or whatever). |
18 |
|
19 |
> |
20 |
> Keyword<->ebuild separation allows to clearly show the arch teams that |
21 |
> they are responsible and allows the developers not to get into conflict |
22 |
> here. It clearly would have avoided the recent conflict. |
23 |
Arch teams already know what they're responsible for - moving metadata |
24 |
about isn't going to change that at all and it most certainly wouldn't |
25 |
fix flameeyes complaint about having an extra 300 ebuilds in the tree |
26 |
because some arch team are late regarding keywording. The ebuilds would |
27 |
*still* need to be in the tree no matter where we store keyword |
28 |
information so it wouldn't solve it at all. |
29 |
|
30 |
> |
31 |
> The problem is with ebuild developers like me having no means to get |
32 |
> arch teams to keyword stuff yet we are responsible if something fails |
33 |
> and we get bugs assigned. |
34 |
Many arch team members have repeatedly stated that ebuild maintainers |
35 |
are free to reassign bugs about old versions to them if you've given the |
36 |
arch team reasonable time to keyword a newer version first so I don't |
37 |
think that argument has much merit to it at all. |
38 |
|
39 |
> |
40 |
> >[remove kde-meta talk] |
41 |
> > |
42 |
> >Besides that splitting keywords out from ebuilds doesn't solve |
43 |
> >*anything* at all related to this as the ebuilds *still* have to stay |
44 |
> >around as long as they have keywords. Just like current policy says. |
45 |
> >Moving metadata to another place doesn't change that at all. |
46 |
> |
47 |
> yeah. A script for removing all ebuilds that are allowed to be removed |
48 |
> by policy would be cool. Sadly I don't have one currently :( |
49 |
> |
50 |
I'm all for removing old junk from the tree but I don't think that can |
51 |
be entirely automated - there's lots of reasons that we might want to |
52 |
keep an older package around even when a newer package is keyworded on |
53 |
all archs. Sometimes we need to test against the older version and |
54 |
sometimes we need to allow people a transition period for config changes |
55 |
for example. |
56 |
|
57 |
So I think a tool listing versions that could possibly be removed would |
58 |
be much better than an automated tool just removing it all without |
59 |
further concerns. |
60 |
|
61 |
> We can for example also offer x86-only sync trees without all the |
62 |
> ebuilds that are only relevant to the other arches. |
63 |
> |
64 |
As an arch team member I think that's a horrible idea tbh. I don't want |
65 |
to waste any time on keeping all the changes from various arch trees in |
66 |
sync with my own arch tree. And from an ebuild maintainers point of view |
67 |
I'd like to know that when I fix a bug it's fixed on all archs. |
68 |
|
69 |
Both things would be broken if we seperate the tree imo and we would |
70 |
also drastically increase the space requirements for rsync mirrors which |
71 |
is quite bad. Having to keep 12 (or however many archs we support) |
72 |
portage trees instead of just one on rsync servers doesn't sound like a |
73 |
good idea imo. |
74 |
|
75 |
Regards, |
76 |
Bryan Østergaard |
77 |
-- |
78 |
gentoo-dev@g.o mailing list |