Gentoo Archives: gentoo-dev

From: Peter <pete4abw@×××××××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Date: Fri, 09 Jun 2006 18:50:19
Message-Id: pan.2006.06.09.18.42.46.17779@comcast.net
In Reply to: Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay by Chris Gianelloni
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

Replies

Subject Author
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay Ryan Hill <dirtyepic.sk@×××××.com>