1 |
On Fri, Mar 14, 2003 at 03:12:04PM -0800, Matt Tucker wrote: |
2 |
> -- Spider <spider@g.o> spake thusly: |
3 |
> |
4 |
> > begin quote |
5 |
> > On Fri, 14 Mar 2003 06:19:17 -0700 |
6 |
> > Alain Penders <alain@g.o> wrote: |
7 |
> > |
8 |
> >> > I'm forced to proofread the new builds completely as to avoid |
9 |
> >> > getting messed over. |
10 |
> > |
11 |
> >> Maybe because they trust that all our developers know how to diff a |
12 |
> >> submitted ebuild against the last approved one? |
13 |
> > |
14 |
> > What do you think I mean with proofread, really? |
15 |
> > (vimdiff and gtkdiff are both quite handy on larger stuff , gdm comes |
16 |
> > to mind as more or less a nightmareish example) |
17 |
> > |
18 |
> >> Even with a changelog entry, I would never add a user-submitted |
19 |
> >> ebuild without diffing it and making sure I know what changed and |
20 |
> >> why. |
21 |
> > |
22 |
> > of course not, I'm not inclined to have my or others systems |
23 |
> > compromised or messed over, But my point is: adding a ChangeLog or |
24 |
> > stating what is done difference does make a change when submitting a |
25 |
> > build for something thats already in the tree. |
26 |
> |
27 |
> While it's an excellent point that users should submit Changelogs, it |
28 |
> doesn't really address the original issue. To summarize, I believe the |
29 |
> conversation went like this: |
30 |
> |
31 |
> user> I submitted a new ebuild with some changes, but the developer |
32 |
> simply copied the old ebuild instead of using my new one. |
33 |
> |
34 |
> dev> We have problems with users simply copying old builds to create |
35 |
> the new one without submitting a Changelog. This makes it hard |
36 |
> for us to figure out what's been changed. |
37 |
> |
38 |
> I fail to see how this justifies using the old build instead of the new |
39 |
> one. I fail, in fact, to see how the reply is even related to initial |
40 |
> complaint.. If it's a problem for users to do "cp old.build new.build", |
41 |
> why is it okay for a dev to do it _when a new build has been supplied_? |
42 |
> |
43 |
> And if there's not sufficient information to determine what's changed |
44 |
> in the ebuild (and you don't have the time to review a diff), wouldn't |
45 |
> it be better to kick it back to the submitter rather than ignoring what |
46 |
> they've submitted and using the old build for the new version? A diff |
47 |
> -q doesn't take any longer than a cp, and submitting changes without |
48 |
> submitting a changelog seems ample justification for refusing to commit |
49 |
> them. |
50 |
> |
51 |
> |
52 |
|
53 |
My opinion here is: if you don't have the time to take a look at the |
54 |
diff, don't accept the bug containing the ebuild. Pass it on to someone |
55 |
who does have the time rather than risk borkage by just copying the old |
56 |
ebuild. |
57 |
|
58 |
-- |
59 |
Jon Portnoy |
60 |
|
61 |
-- |
62 |
gentoo-dev@g.o mailing list |