| 1 |
On Thu, Oct 27, 2016 at 3:01 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> Please review the following draft: |
| 4 |
> |
| 5 |
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:TPC |
| 6 |
> |
| 7 |
|
| 8 |
Regarding this paragraph: "Gentoo project provides a specific set of |
| 9 |
official channels of contribution in which all project members are |
| 10 |
required to participate. The exact list of these channels is outside |
| 11 |
the scope of this specification." |
| 12 |
|
| 13 |
i'm not actually certain that the first sentence is true. I think the |
| 14 |
only "official channel" of any kind that project members are required |
| 15 |
to participate in is gentoo-dev-announce, and maybe gentoo-core. I |
| 16 |
don't think devs are actually required to either file or look at or |
| 17 |
resolve bugs, for example. Obviously it is encouraged. |
| 18 |
|
| 19 |
I'd suggest just rewording this section to something like: |
| 20 |
"Contributions can be accepted via any channel (whether official or |
| 21 |
unofficial), as long as there is at least one project member willing |
| 22 |
to support the particular channel and either commit or proxy the |
| 23 |
contributions appropriately." |
| 24 |
|
| 25 |
I think this reflects reality. You can submit all the patches you |
| 26 |
want via bugzilla but it isn't like we punish developers for not |
| 27 |
getting around to accepting them, unless they're completely inactive |
| 28 |
Gentoo-wide. |
| 29 |
|
| 30 |
I do think the copyright issues belong in their own policy for the most part. |
| 31 |
|
| 32 |
Part of me wonders if this really needs to be a GLEP (a mostly |
| 33 |
inward-facing policy document) when it mostly documents existing |
| 34 |
practices and policies. Maybe what is needed is a more outward-facing |
| 35 |
document, or some workflow documents? The motivation states "Multiple |
| 36 |
developers have noted various suggestions on Gentoo git workflow but |
| 37 |
it never became an official policy," but I don't see any kind of |
| 38 |
workflow really being solidified here either. |
| 39 |
|
| 40 |
I guess my question on that front is what is the actual gap today, and |
| 41 |
does this GLEP close it, and if not, is there either a better way, or |
| 42 |
can we make the GLEP stronger to actually close the gap? Just because |
| 43 |
a workflow is optional doesn't mean that we can't standardize how it |
| 44 |
is done. |
| 45 |
|
| 46 |
-- |
| 47 |
Rich |
Archives