| 1 |
On Mon, Feb 4, 2019 at 1:32 PM Mike <mpagano@g.o> wrote: |
| 2 |
> |
| 3 |
> I guess we should figure out the level of support users can expect to |
| 4 |
> receive from using this GURU repo. If someone forks a package I |
| 5 |
> maintain and then a user has issues I'm not sure how much 'official' |
| 6 |
> support they can expect. Certainly for complicated ebuilds, with |
| 7 |
> 'multiple right' ways of doing things, this could result in an |
| 8 |
> 'official' maintainer being at odds with the 'unoffical' one. Maybe we |
| 9 |
> have that now? |
| 10 |
|
| 11 |
The original proposal raised that question. IMO we shouldn't allow |
| 12 |
namespace conflicts with the main repo. If the main repo has |
| 13 |
courier-imap then no package can use that name in GURU. Now, if |
| 14 |
somebody wants to maintain some fork of the package under a different |
| 15 |
name that is fine. |
| 16 |
|
| 17 |
And again I don't think we want to make it so that when a user |
| 18 |
installs one random GURU package that they automatically start pulling |
| 19 |
in every other package in that repo like they would a regular overlay. |
| 20 |
That will make it much harder for them to stay aware of potential |
| 21 |
issues. |
| 22 |
|
| 23 |
That problem can actually exist in the main repo, but in practice it |
| 24 |
doesn't come up much. If somebody wanted to stick a renamed chromium |
| 25 |
ebuild in the main repo that just defaults to duckduckgo or whatever |
| 26 |
that would technically be allowed by policy I believe. However, most |
| 27 |
devs are just going to use user patch support to do this sort of |
| 28 |
thing, especially considering the effort required to maintain a |
| 29 |
parallel package like that. There have been similar arguments over |
| 30 |
default USE flags (and associated patches) for stuff like openssh and |
| 31 |
bitcoin as well. At least within the main repo we have a pretty |
| 32 |
well-defined escalation path for QA/Council/etc. |
| 33 |
|
| 34 |
-- |
| 35 |
Rich |
Archives