1 |
On Fri, 09 Jun 2006 14:15:01 -0400, Chris Gianelloni wrote: |
2 |
|
3 |
Chris, I am not familiar enough about gentoo's hierarchy, politics, or |
4 |
team responsibilities to question your sincerity or authority to say |
5 |
something like: Sorry, but if it isn't supported, it doesn't belong on |
6 |
Gentoo infrastructure. |
7 |
|
8 |
I do think that is a pretty heavy-handed statement though. However, |
9 |
authority issues aside, I would like to respond to your comments. |
10 |
>> Secondly, my bias against a third party repository is perhaps |
11 |
>> unwarranted. I am sure the bmg site is excellent and the people running |
12 |
>> it are well-intentioned and experienced. However, that said, as a user, |
13 |
>> I have a higher comfort level staying in the gentoo.realm. |
14 |
> |
15 |
> Again, you are *proving* the point on why this would be bad. It would |
16 |
> be not nearly as well maintained, yet users such as yourself will have |
17 |
> this rose-colored perception that "it's from Gentoo, so it must be |
18 |
> good." This is the *exact* thing that I am trying to avoid. This will |
19 |
> *not* be from Gentoo and it will *not* be good. |
20 |
> |
21 |
|
22 |
I do not understand how ebuilds created by gentoo developers or interested |
23 |
users who may have contributed via bugzilla that are hosted on o.g.o would |
24 |
not be good? My perspective is primarily as a user. However, there are |
25 |
several ebuilds in portage, and one eclass with my name on it. So, I feel |
26 |
that I have the ability to discern between good and bad. I choose to |
27 |
contribute to gentoo because I want to. Some projects will never see the |
28 |
light of day. Others will. However, some bugs have a large following. And |
29 |
to keep those ebuilds in limbo is unfair to those users who are interested. |
30 |
|
31 |
>> Thirdly, the opportunity to be able to publish ebuilds that would |
32 |
>> otherwise languish in bugzilla is very exciting. I think it also gives |
33 |
>> the bugday people an opportunity to close out bugs. Despite what others |
34 |
>> have written, having multi-year old bugs is very counter productive. If |
35 |
>> something has not been fixed in so long, it probably either can't be |
36 |
>> fixed, or may not even apply anymore. I know this is a generalization, |
37 |
>> but if a bug was filed against gentoo 2004.3, who knows if it still |
38 |
>> applies with gentoo 2006.0. Especially if there has been little or no |
39 |
>> activity. |
40 |
> |
41 |
> Perhaps there is no activity because the interest is not there? Nobody |
42 |
> seems to be taking this into account. |
43 |
> |
44 |
|
45 |
That's a fair point. However, if there is no activity and no interest, |
46 |
then nuke the bug. Post an announcement like they do periodically on |
47 |
-devel saying "Last rites for....." and see who comes forward. |
48 |
|
49 |
> If you really think your package should be added to the tree, then add |
50 |
> yourself to CC, get your friends on CC, drum up some support in the |
51 |
> forums, find yourself a developer to proxy maintain for you. We don't |
52 |
> need a dumping ground for abandoned or little-use ebuilds. |
53 |
> |
54 |
|
55 |
Done that. However, there are some packages that won't ever make it. Like |
56 |
some kernel sources, java and gcc hacks, etc. I don't think the process of |
57 |
committing and ebuild should be a popularity contest. I do not infer that |
58 |
sunrise would be a dumping ground at all. I think that it's a very low |
59 |
chance that every maintainer-wanted bug will get there, don't you? |
60 |
|
61 |
>> Personally, I don't see the conflict, or the risk, or the additional |
62 |
>> work for devs. In fact, I see the opposite. Removing maintainer-wanted |
63 |
>> bugs is a net positive. If that means the proposed ebuild lives in |
64 |
>> o.g.o that's fine. Just point users who see the bug over to it. And, if |
65 |
>> an ebuild proves to be useful, or popular, it's conceivable that it |
66 |
>> could ultimately find its way over to the main tree. |
67 |
> |
68 |
> Well, I've done about as good as I can do to point out how it would be |
69 |
> additional work and a major risk. If you cannot see it, there's not |
70 |
> much else I can do. Luckily, a growing number of official developers |
71 |
> *do* see the risks and are taking a stand against this egregious waste |
72 |
> of time. |
73 |
> |
74 |
|
75 |
I've had some conversations with devs personally and on irc. Most complain |
76 |
about how overworked they are or how little time they have. Something like |
77 |
this will remove a burden from their plates. The "risk" aspect has been |
78 |
covered in other posts far more eloquently than I could (see Christel's |
79 |
post for example). What WOULD be a risk is adding a profile to the main |
80 |
tree with this overlay. |
81 |
|
82 |
snip... |
83 |
> |
84 |
>> Again, I think you need to consider your audience for o.g.o. The newbie |
85 |
>> won't be there or be syncing to o.g.o. The server admin probably would |
86 |
>> not be there either for updating a production machine. I think the main |
87 |
>> audience for o.g.o. would be the power user, or the wannabe power user |
88 |
>> or certain project teams, or people with a particular interest or need |
89 |
>> in a project not hosted on the main tree -- that is people who actively |
90 |
>> need sunrise's services. |
91 |
> |
92 |
> You're absolutely right. We need to think of the audience. The |
93 |
> overlays.gentoo.org project was touted as a way to foster the community |
94 |
> and to help *developers* develop things that might be intrusive to the |
95 |
> portage tree, as well as allow for easier non-developer contributions. |
96 |
> It was *never* touted as a place where we would allow dumping of |
97 |
> half-correct, unsupported, and only marginally quality ebuilds for mass |
98 |
> user consumption. |
99 |
> |
100 |
|
101 |
I never inferred this to be the case and I think were you to be a little |
102 |
less constrictive in your thinking, or chatted with the leads, you may |
103 |
see things differently. I think you read much more into this that there |
104 |
really is. |
105 |
|
106 |
>> And, looking at this from a broader perspective, I see this as a real |
107 |
>> enhancement to gentoo. Offering an experimental tree for packages not |
108 |
>> intended or not wanted in the main tree. This is an added benefit, it |
109 |
>> demonstrates a policy of inclusion, not exclusion. It shows a |
110 |
>> willingness to push the envelope and give certain packages a home where |
111 |
>> they would not normally get one. |
112 |
> |
113 |
> It also shows that we're not concerned with quality or providing a |
114 |
> consistent experience where things are meant to work together. It shows |
115 |
> our complete lack of commitment to the safety of our users. It shows |
116 |
> that we really are nothing more than a bunch of ricers that will take |
117 |
> the quick and easy approach, rather than doing things right. |
118 |
> |
119 |
|
120 |
I disagree. I think another user commented that gentoo has a reputation |
121 |
for not being current. I see how this is the case. Part of it has to do |
122 |
with being a source based distro. Part of it has to do with the |
123 |
stabilization process. However, part of it has to do with some projects |
124 |
just not getting in. I think sunrise will help that and show a concern for |
125 |
the user community and a desire to embrace and include. |
126 |
|
127 |
> No thanks... |
128 |
|
129 |
Well, I respect your opinions, though I think it is a bit tight. |
130 |
-- |
131 |
Peter |
132 |
|
133 |
|
134 |
-- |
135 |
gentoo-dev@g.o mailing list |