1 |
On Sun, 2003-05-11 at 23:01, David Nielsen wrote: |
2 |
|
3 |
> Okay, our guidelines clearly state that when a fixed ebuild has been |
4 |
> confirmed by two other people as working, we submit it to bugzilla. All |
5 |
> the ebuild janitors do is make sure that the ebuilds use the USE flags |
6 |
> to the maximum of their potential, and of course generally clean them up |
7 |
> as there's a lot of stuff in some older ebuilds that is no longer valid. |
8 |
> Your mail clearly showed that you had not read those guidelines.. |
9 |
|
10 |
Why should we read every emerging sub projects documents? That's not |
11 |
very realistic. Anyway, what defines an ebuild as working (this is a |
12 |
problem in general) : does it build, does it build on a clean install |
13 |
with any possible combination of USE flags, does it run fine for 1 month |
14 |
on someones production server ? |
15 |
|
16 |
Older ebuilds usually get phased out with time and cleaning is done on |
17 |
new releases. Sure there will slip stuff trough now and then, nothing |
18 |
major. |
19 |
|
20 |
I had a quick peek at your ebuilds btw and i can tell you your |
21 |
developers clearly do not read ChangeLog's for one, cause some things |
22 |
that you do are certainly gonna give trouble. |
23 |
|
24 |
What i'm afraid of here is that you and your project will give more |
25 |
maintenance type of bugs which correct insignificant stuff, pressuring |
26 |
an already pressured group of devs. And you guys happily define new USE |
27 |
flags allover, which also isn't a good thing if you want to see your |
28 |
changes integrated. |
29 |
|
30 |
> The plan is NOT to fork portage, the plan is NOT to stage a coup, the |
31 |
> plan is NOT to start a pissing contest with the developers... the plan |
32 |
> is quite simple, to make portage even better. |
33 |
|
34 |
A few ebuild corrections and a fork are whole different things. You have |
35 |
obviously no idea what it takes to handle a full tree of ebuilds, |
36 |
otherwise you wouldn't even have mentioned forking here in the first |
37 |
place. |
38 |
|
39 |
> Should we be so unlucky as to hit a major problem that we can't handle |
40 |
> within the project, we will of course take contact to the person in |
41 |
> charge, or mail gentoo-dev for input depending on the situation. |
42 |
|
43 |
I'm not sure -dev is the right place for your problems with correcting |
44 |
ebuild XYZ, it is already too high traffic for the general dev to keep |
45 |
up with. Bugzilla or direct contact is probably best. |
46 |
|
47 |
> We have already hit some cases that could be viewed as imperfections in |
48 |
> the way flags are handled in Portage, and we have yet to receive any |
49 |
> technical feedback on these issues. |
50 |
|
51 |
Portage isn't perfect and there's a large TODO for it and i think we are |
52 |
well aware of that. Developers have limited time, please take that in |
53 |
mind when you want clarification about the feature you really need right |
54 |
now/bug you encountered. |
55 |
|
56 |
- foser |
57 |
|
58 |
|
59 |
-- |
60 |
gentoo-dev@g.o mailing list |