| 1 |
On Thu, 2006-03-23 at 14:41 +0000, Stuart Herbert wrote: |
| 2 |
> Hi Chris, |
| 3 |
> |
| 4 |
> On 3/23/06, Chris Gianelloni <wolf31o2@g.o> wrote: |
| 5 |
> > If some random developer goes out there and creates his own fork of |
| 6 |
> > catalyst in his overlay, I sure don't want to receive a *single* bug on |
| 7 |
> > it. Ever. |
| 8 |
> |
| 9 |
> Your nightmare scenario seems unavoidable. Enabling per-overlay bug |
| 10 |
> tracking doesn't stop users posting bugs in bugzilla. It just causes |
| 11 |
> confusion for users, because they're not sure where to go. Normally, |
| 12 |
> it's not a problem - because the overlay contributors are normally the |
| 13 |
> owners of the real package. |
| 14 |
|
| 15 |
No, it does not stop them, but it sure will curb the number of users |
| 16 |
posting their bugs to the wrong place. Remember that only more advanced |
| 17 |
users are the ones using overlays. We won't have Joe Sixpack using an |
| 18 |
overlay. Instead it'll be Bob Developer-to-be. |
| 19 |
|
| 20 |
How is that confusing? I went to http://overlays.gentoo.org/catalyst-ng |
| 21 |
and saw the overlay. I also saw the link the the bug tracker. |
| 22 |
|
| 23 |
> A hostile fork of Catalyst is very much a special case. |
| 24 |
|
| 25 |
No. It isn't. Look in many developer overlays and you'll see packages |
| 26 |
that they have made that work how *they* want them to, even if it is |
| 27 |
*very* different from what is in the tree. This is the case for |
| 28 |
packages that are not maintained by them, too. Any ebuild that is done |
| 29 |
by someone that isn't the maintainer is a fork. There's nothing |
| 30 |
"hostile" about it. |
| 31 |
|
| 32 |
> What we could do is say that overlays are for package trees only; ie |
| 33 |
> they are not general-purpose repositories for holding source trees. |
| 34 |
> That would ensure that your nightmare scenario is even less likely to |
| 35 |
> happen, and that if it does, it's through no fault of the overlays |
| 36 |
> project :) |
| 37 |
|
| 38 |
It has nothing to do with a source tree. I could store the source tree, |
| 39 |
and tarball, anywhere. The ebuilds to use these tarballs would be just |
| 40 |
as dangerous. |
| 41 |
|
| 42 |
I see no problem with overlays in concept, such as the php overlay that |
| 43 |
is very successful. The main reason that it is successful is because |
| 44 |
the same people that maintain php maintain the overlay. Yes, there are |
| 45 |
other contributors, but the maintainers of the overlay are still the |
| 46 |
developers. I see no problem with providing these sorts of overlays to |
| 47 |
bridge the gap between contributing users and developers. I *do* see a |
| 48 |
problem with simply allowing random overlays from any developer for |
| 49 |
anything. |
| 50 |
|
| 51 |
-- |
| 52 |
Chris Gianelloni |
| 53 |
Release Engineering - Strategic Lead |
| 54 |
x86 Architecture Team |
| 55 |
Games - Developer |
| 56 |
Gentoo Linux |
Archives