1 |
On 12:38 Wed 28 Nov , Duncan wrote: |
2 |
> Donnie, I'm sure you have the scope of what you intend to apply this to |
3 |
> firmly in your mind, but it's not at all clear from your post what it |
4 |
> is. Ebuilds? Doesn't make sense with changelog already there and |
5 |
> generally used (when folks don't forget or screw the format and therefore |
6 |
> the parsing thereof). Eclasses? OK, that makes more sense, but is that |
7 |
> what you intended? Gentoo sponsored projects such as portage? Isn't |
8 |
> that stepping on the various project's toes and don't most of them have |
9 |
> such requirements in place formally or not as it is? Something else? |
10 |
> Some combination of the above? |
11 |
> |
12 |
> It's kinda hard to discuss such a proposal without knowing where it is |
13 |
> going to be applied, or to read such discussion without being sure |
14 |
> everybody has the same target in mind (maybe it was discussed on IRC and |
15 |
> since I don't normally do that I missed it... seems I'm not the only one, |
16 |
> tho), and what it may be. |
17 |
|
18 |
Many of the replies keep asking for details -- details that don't exist. |
19 |
Apply the concept abstractly: things that need to be documented must |
20 |
have documentation available in the appropriate form at the time they're |
21 |
committed. |
22 |
|
23 |
Some of these things are already documented fairly well, generally, such |
24 |
as changes to single ebuilds and eclasses. Others, such as global |
25 |
features, are not always. At this level of change, a GLEP is one form of |
26 |
documentation; the handbook or devmanual is another. |
27 |
|
28 |
What remains unclear about this principle? |
29 |
|
30 |
Thanks, |
31 |
Donnie |
32 |
-- |
33 |
gentoo-dev@g.o mailing list |