1 |
On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: |
2 |
> > You don't need a subversion client, you perhaps notice the http in front |
3 |
> > of the url.. just open it up in your browser and you get the source |
4 |
> > immediately. |
5 |
> |
6 |
> Umm... so now I need to go and instead of clicking a nice link in |
7 |
> bugzilla, trawl through the subversion repository and find what I'm |
8 |
> looking for? How exactly is downloading things via http any different |
9 |
> than downloading them from bugzilla, which is also http? |
10 |
just my point of view - |
11 |
|
12 |
bugzilla sucks. Ever had to download 10 attachments for one ebuild? |
13 |
It is a good tool for discussion, but I would prefer a simple tool (like |
14 |
layman) that can automatically update things. You obviously don't like |
15 |
overlays, but that shouldn't be a reason to stop us from using it. |
16 |
|
17 |
> > Or, if you want some history like sources.g.o, you can do so as well here: |
18 |
> > http://overlays.gentoo.org/proj/sunrise/browser/ |
19 |
> |
20 |
> Excellent. So we're moving the history from being in a single location |
21 |
> (the bug) to being in multiple locations. That will definitely improve |
22 |
> the development process. |
23 |
Yes, now it is easier to check out the ebuilds. More users ==> better |
24 |
testing. |
25 |
;-) |
26 |
|
27 |
> No offense, but everything I have seen looks |
28 |
> as if it will add even *more* overhead to actually getting packages into |
29 |
> the tree. The only thing this seems to provide is a half-baked |
30 |
> repository for the users to get marginally-tested ebuilds for software |
31 |
> that wasn't interesting enough for inclusion in the tree. |
32 |
That differs from the 20 or so overlays maintained by users how? |
33 |
Honestly I'd prefer an overlay where I can marginally trust the content |
34 |
over a "foreign" repository maintained by people I don't know. |
35 |
And the quality of some of the overlays ... better have that supervised |
36 |
by devs, they should know how to handle b0rkage. |
37 |
|
38 |
> > > Except that I can *look* at an ebuild without having to break out a |
39 |
> > > subversion client currently. |
40 |
> > See my answer in 3) |
41 |
> See mine. ;] |
42 |
Hmmm ... bugzilla. |
43 |
Instead of a simple cvs up; cd /usr/local/portage/category/package I |
44 |
need to search for ALL bugs with $name in it, look which one it is, |
45 |
curse bugzilla for falling asleep again, see which attachments are |
46 |
relevant, download them, curse bugzilla for falling asleep again, copy |
47 |
them to my overlay, read the bugcomments to see if any special renaming |
48 |
or directory structure is needed ... |
49 |
|
50 |
Hmmm. I think an overlay does have some advantages there ... |
51 |
|
52 |
> |
53 |
> Again, read what I wrote. I said that the developer would see "sunrise" |
54 |
> in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated |
55 |
> without considering. This is a login bug. At no point did they make |
56 |
> mention of having installed pam_skey from this overlay. This means that |
57 |
> I, as the developer getting this bug, am now responsible for looking at |
58 |
> *every package* in the sunrise overlay to determine if *any* of them |
59 |
> could *possibly* be affecting this package or causing this bug, then |
60 |
> asking the user if they have any of them installed. |
61 |
This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ... |
62 |
|
63 |
> Wouldn't this process be *infinitely* easier if instead of "sunrise" |
64 |
> there was a "pam" overlay with *only* the pam stuff? |
65 |
Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-) |
66 |
|
67 |
Having one overlay with a focus on not-in-portage ebuilds should not |
68 |
cause the scenario you described and will most likely cause less weird |
69 |
bugs because of intra-overlay dependencies. |
70 |
</opinion> |
71 |
|
72 |
> That is *exactly* what we get with the other overlays like php and |
73 |
> vmware. I *know* that if I'm looking at a glibc bug and the user has |
74 |
> "php" as an overlay, that it isn't going to be a concern. |
75 |
... and if we control the overlay we can exclude things like system |
76 |
packages easily. |
77 |
Could be part of the policy to not touch existing ebuilds. |
78 |
|
79 |
> This is a prime example of totally glossing over any discussion to make |
80 |
> it sound promising for you. |
81 |
If bugzilla wasn't so sucky people wouldn't try to use other methods of |
82 |
communication ;-) |
83 |
|
84 |
And again, one svn repo vs. 113 hard-to-find bugs ... |
85 |
|
86 |
> Even better, if I am the proxy |
87 |
> maintainer for a particular set of ebuilds for one or more |
88 |
> user/maintainers, why do I need it in your big, bloated, and completely |
89 |
> inappropriately-named "sunshine" overlay versus a developer overlay of |
90 |
> my own? |
91 |
You don't. Please use your developer overlay. Please don't try to take |
92 |
away our more open overlay. |
93 |
|
94 |
> After all, I am the *only* proxy maintainer. Why should there |
95 |
> be the added *insecurity* of allowing any number of people that *I* |
96 |
> might not trust complete access to the small number of packages where I |
97 |
> am the proxy? |
98 |
It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay. |
99 |
|
100 |
And the users could just create their own overlay, get it added to |
101 |
layman and we'd have the same without supervision. From where I'm |
102 |
standing it's better to have the possibility to nuke a bad ebuild in the |
103 |
overlay instead of asking some random user to change this in that |
104 |
overlay because of $problem. |
105 |
|
106 |
Maybe we even find some motivated new ebuild monkeys that have the |
107 |
motivation to become devs ... one can always hope :-) |
108 |
|
109 |
|
110 |
Patrick |
111 |
-- |
112 |
Stand still, and let the rest of the universe move |