1 |
On 05/20/2016 05:38 AM, Kristian Fiskerstrand wrote: |
2 |
> On 05/20/2016 03:36 AM, Daniel Campbell wrote: |
3 |
>> On 05/19/2016 07:51 AM, Jeroen Roovers wrote: |
4 |
> |
5 |
> .. |
6 |
> |
7 |
>>> |
8 |
>> To make sure I understand what you're getting at, are you saying some |
9 |
>> devs get on board and then request to add keywords to packages that they |
10 |
>> already maintain? If said arches are already supported in Gentoo I see |
11 |
>> little problem with that, especially if they intend on being part of the |
12 |
>> arch testing team for that arch or have access to the hardware. |
13 |
> |
14 |
> Can you elaborate on your definition of supported in this case? does it |
15 |
> deviate from stable arches (alpha, amd64, arm, hppa, ia64, ppc, ppc64, |
16 |
> sparc, x86)? |
17 |
|
18 |
I would say yes, if Gentoo has the manpower to maintain a stable branch |
19 |
for an arch, it's supported. How *well* it's supported is a separate |
20 |
concern and equally important. |
21 |
> |
22 |
>> |
23 |
>> But if this is a case of developers asking for arch keywords to be added |
24 |
>> for arches that aren't (yet) supported in Gentoo, I agree that we need |
25 |
>> some sort of formal requirements, much like we do for stabilization (30 |
26 |
>> days no bugs, etc). Covering it in the devmanual is a great idea. |
27 |
> |
28 |
> keywording for a new arch should normally only be done when necessary, |
29 |
> mainly if it is a direct dependency of another package. There is no need |
30 |
> to keywor it for an arch until it has been tested on that arch by some |
31 |
> user / developer ... certainly not because some committing developer |
32 |
> think it is nice to have all arches listed just in case. |
33 |
> |
34 |
> It is actually already [covered in the devmanual]; " It's important to |
35 |
> note that alternative arches (like alpha, ia64, s390, sh, sparc, hppa, |
36 |
> ppc*) are mainly undermanned arches, some of them are slow, they have |
37 |
> more basic problems and have a small userbase. Just file bugs for these |
38 |
> architectures when a package is going to be a dependency of a package |
39 |
> already keyworded. " |
40 |
|
41 |
Nice citation, I remember reading that last year. :) I agree: a new arch |
42 |
should have users and testing backing it up so it doesn't get added and |
43 |
later disappears or is left to sit and rot. As far as I understand, we |
44 |
have the arches that we do because there are developers and users |
45 |
willing to build it, submit bugs, and maintain it. New arches should be |
46 |
held to the same standard. |
47 |
> |
48 |
>> |
49 |
>> But adding keywords, as we know, comes with maintenance burden. New |
50 |
> |
51 |
> Indeed, more people should think of this. Adding packages in itself adds |
52 |
> maintenance burdens for other teams and the usefulness should be |
53 |
> considered accordingly before doing so |
54 |
> |
55 |
>> arches can't get supported without people active in the community and |
56 |
>> actually using the hardware. If that interest isn't there, why should we |
57 |
>> add the keywords to the main repo? Overlays may be a fine alternative. |
58 |
>> |
59 |
>> Just my 2ยข. Thanks for bringing this up, it's a topic I didn't know was |
60 |
>> a concern. |
61 |
>> |
62 |
> |
63 |
> References: |
64 |
> [covered in the devmanual] |
65 |
> https://devmanual.gentoo.org/keywording/index.html |
66 |
> |
67 |
> |
68 |
> |
69 |
|
70 |
|
71 |
-- |
72 |
Daniel Campbell - Gentoo Developer |
73 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
74 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |