1 |
On Sat, May 21, 2016 at 10:09:04AM +0800, Ian Delaney wrote: |
2 |
> On Fri, 20 May 2016 16:00:02 +0200 |
3 |
> Jeroen Roovers <jer@g.o> wrote: |
4 |
> |
5 |
> > On Thu, 19 May 2016 18:36:22 -0700 |
6 |
> > Daniel Campbell <zlg@g.o> wrote: |
7 |
> > |
8 |
> > > To make sure I understand what you're getting at, are you saying |
9 |
> > > some devs get on board and then request to add keywords to packages |
10 |
> > > that they already maintain? If said arches are already supported in |
11 |
> > > Gentoo I see little problem with that, especially if they intend on |
12 |
> > > being part of the arch testing team for that arch or have access to |
13 |
> > > the hardware. |
14 |
> > |
15 |
> > I am not talking about adding architecture keywords to profiles/. |
16 |
> > I am talking about adding architecture keywords to ebuilds. |
17 |
> > |
18 |
> > |
19 |
> > Regards, |
20 |
> > jer |
21 |
> > |
22 |
> |
23 |
> Firstly I think previous replies have been de-railed on talking about |
24 |
> new alternate arches, which personally I think is the last thing we |
25 |
> need. If there is any confusion it is because the term keyword, like |
26 |
> most terms in I.T. gets pushed and pulled and stretched until it breaks. |
27 |
> To my understanding, KEYWORDS are arches. But being told to 'keyword' a |
28 |
> package could mean perhaps, well, Hu knows. |
29 |
|
30 |
I don't know of any other usages of "KEYWORDS" within Gentoo - to my |
31 |
knowledge the only definition is a list of which architectures a package |
32 |
is known to work or not work on, and an indication of the level of |
33 |
testing and expected usability on that architecture. |
34 |
|
35 |
Is there some other definition that I'm missing? |
36 |
|
37 |
> Supporting users doing just this lately, I have come across this a few |
38 |
> times. Users and new devs are expected to be very ignorant of minor |
39 |
> arches, and despite having docs already informing them that they are |
40 |
> short staffed and have enough to do, the practicalities of how and why |
41 |
> to keyword request or not are still veiled in mystery. Users want to |
42 |
> keyword according to what they see supported upstream just because |
43 |
> they can. They appear to need it made manually clear to them that there |
44 |
> are qualifiers and conditions for putting something up for keywording. |
45 |
> These also I believe are as much as mystery to users as they are to |
46 |
> devs. |
47 |
|
48 |
Appropriate use of KEYWORDS is actually covered in the Developer |
49 |
quizzes, so I would have instead expected new developers to be more |
50 |
acutely aware of the fact that keywording on minor arches should be |
51 |
generally reserved for an as-needed basis. |
52 |
|
53 |
> How to establish a level of desire form userland to have gentoo |
54 |
> support the arch in the package?? |
55 |
> How to establish sane rationale for it being put up for stable?? |
56 |
> The last I heard was along the lines of, well, only put it up if it has |
57 |
> already been put up in the past.(someone in the past had a check list?) |
58 |
> |
59 |
> If anyone, the members of the arch teams might have some insights based |
60 |
> upon first hand dealing with packages and their categories. Frankly, |
61 |
> how you can expect or achieve users and new devs to assess these is |
62 |
> more the issue, and I do not see there is any obvious path of becoming |
63 |
> informed of the interest of an invisible audience; userland |
64 |
|
65 |
As far as I know, users (as in non-maintainers - those out "in the wild") |
66 |
can file keyword request bugs and it's up to the maintainer to then |
67 |
determine relevancy and CC appropriate arch teams; and Bugzilla has a |
68 |
voting feature[0] allowing users to indicate the strength of community |
69 |
demand by voting on those bugs (which I have seen done previously). |
70 |
|
71 |
[0] https://bugs.gentoo.org/page.cgi?id=fields.html#votes |
72 |
|
73 |
-- |
74 |
Sam Jorna |
75 |
GnuPG Key: D6180C26 |