1 |
The problem is, trying to fix ebuilds in tree is a lot more |
2 |
complicated.. You have to fight with multiple herds, and multiple |
3 |
developers, and explain to them why it should occur, in order to get |
4 |
anything to happen.. In addition, even a global gigantic one liner to |
5 |
add quotes to $D and $S would cause huge rsync loads... which makes |
6 |
the mirror admins hate you... Combine this with the first issue, and |
7 |
just improving the incoming ebuilds and hoping that the devs watching |
8 |
this list pay attention, and make some of these changes in newly added |
9 |
ebuilds, will improve the quality of the tree slowly. |
10 |
|
11 |
If a user submits an ebuild, they should be prepared to make fixes to |
12 |
bring it up to a standard. Many of the ebuilds do not even follow |
13 |
ebuild-submit.xml, and the maintainer fixing them only causes more |
14 |
problems for other maintainers further down, assuming the user submits |
15 |
multiple ebuilds. Once they learn the rules, later ebuilds will |
16 |
hopefully be up to the same standards. |
17 |
|
18 |
On 9/12/05, Carsten Lohrke <carlo@g.o> wrote: |
19 |
> On Monday 12 September 2005 19:56, Jakub Moc wrote: |
20 |
> > Since you said above, that you really don't care if those user-submitted |
21 |
> > ebuilds will ever get into portage or will stay in maintainer-wanted |
22 |
> queue |
23 |
> > forever and that's the stuff in portage that actually matters QA-wise, |
24 |
> I'm |
25 |
> > missing why are you worried about people not submitting their ebuilds any |
26 |
> > more. |
27 |
> |
28 |
> Two points: |
29 |
> |
30 |
> 1. The biggest share of maintenance isn't getting an ebuild right, but the |
31 |
> ongoing effort keeping it up to date, applying patches, interact with |
32 |
> upstream developers, test, stabilize,... To me it absolutely doesn't matter, |
33 |
> |
34 |
> if an ebuild is broken or not before taking into account to maintain it. |
35 |
> |
36 |
> 2. People are interested in applications, but may not have the skills or |
37 |
> interest to get an ebuild 100% perfect. WONTFIX will look like PISSOFF for |
38 |
> them. I think we just look a bit petty-minded. |
39 |
> |
40 |
> |
41 |
> > At the very least, reviewing user-submitted ebuilds and marking things |
42 |
> > WONTFIX/CANTFIX/REVIEWED makes it possible to filter out the outdated and |
43 |
> > dead-upstream crap, as well as things about which those people who filed |
44 |
> > the bugs don't care any more. And, if someone picks those ebuilds up and |
45 |
> > decides to maintain them, he can focus more on testing the actual app |
46 |
> then |
47 |
> > fixing a broken ebuild (or even committing a broken ebuild into the |
48 |
> tree). |
49 |
> |
50 |
> As I said: Ebuilds in Portage should be reviewed before you think about |
51 |
> those |
52 |
> in bugzilla. |
53 |
> |
54 |
> |
55 |
> Carsten |
56 |
> |
57 |
> |
58 |
|
59 |
-- |
60 |
gentoo-dev@g.o mailing list |