1 |
On Monday 13 January 2014 22:23:01 Tom Wijsman wrote: |
2 |
> On Mon, 13 Jan 2014 19:50:44 -0500 Mike Frysinger wrote: |
3 |
> > On Monday 13 January 2014 19:08:30 creffett@g.o wrote: |
4 |
> > > From: Chris Reffett <creffett@g.o> |
5 |
> > > Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if |
6 |
> > > src_prepare/src_configure are used in EAPI 0/1 |
7 |
> |
8 |
> Well, I was planning to cover these bugs; seems we really need to |
9 |
> organize with regards to avoiding double work, as two others have got |
10 |
> the same happen to them. Let's synchronize it. |
11 |
|
12 |
we have a bugzilla workflow doc posted which we'll merge once git is back up. |
13 |
please do not reassign portage bugs to yourself. instead, set the status to |
14 |
INPROGRESS. |
15 |
|
16 |
> While vapier's case could be considered as valid; I think we should |
17 |
> consider that as a bad practice, as one could just as well put the if |
18 |
> inside a phase which is the much more common practice. |
19 |
|
20 |
certainly, but we need to notify the dev community first |
21 |
|
22 |
> As a note, my WIP work is at the next url; there you can see the bug |
23 |
> numbers I've been working on (still need to revise them, properly |
24 |
> document the added check errors [eg. in `man repoman`] and so on). |
25 |
> |
26 |
> https://github.com/TomWij/gentoo-portage-next/branches |
27 |
|
28 |
we probably should just use dev branches in the main repo, at least for people |
29 |
who have write access to the repo |
30 |
dev/$USERNAME/<whatever you want> |
31 |
|
32 |
> > you might want to set ~/.gitconfig to have your name/email so that |
33 |
> > git sendemail uses the right info in the actual e-mail From: field |
34 |
> |
35 |
> Then what is the From: field that it puts separately into the e-mail |
36 |
> itself? |
37 |
|
38 |
the Author field of the git commit |
39 |
|
40 |
> Seems quite odd for these to differ; or, is the latter an |
41 |
> attempt to mark the author? Then why does the e-mail From: field need |
42 |
> to be correct? Afaik it would only use one of both, so only one of both |
43 |
> needs to be correct. But that would make the actual question: Which one? |
44 |
|
45 |
if they differ, git will post the From: as the first line of the body so that |
46 |
`git am` can do the right thing. if they're the same, then git omits it. |
47 |
|
48 |
they don't *need* to be the same for patches to be merged correctly, but they |
49 |
should be the same to cut down on extraneous noise. the focus is the commit |
50 |
message/code, not other random junk that takes 3 seconds to fix with a |
51 |
configuration tweak. |
52 |
|
53 |
> > i'd suggest merging the regex a little: |
54 |
> > r'^\ssrc_(configure|prepare)\s*\(\)' |
55 |
> |
56 |
> Note that the * behind the first \s was lost; so, with the redundant ^ |
57 |
> removed and the * put back it would be: |
58 |
|
59 |
yes, typo when i hand wrote it |
60 |
|
61 |
> r'\s*src_(configure|prepare)\s*\(\)' |
62 |
> |
63 |
> You can then proceed further and move the re outside: |
64 |
|
65 |
the idea was to walk a balance between simplicity and maintainability. imo, |
66 |
the fixed version above is the best. |
67 |
|
68 |
> > the regex is naive and can match valid ebuilds. consider ones that |
69 |
> > handle $EAPI itself and will call the right funcs as necessary. |
70 |
> |
71 |
> From a QA point of view it seems more preferable to move away from old |
72 |
> EAPIs, than to conditionally support them. The common case is that |
73 |
> ebuilds move from older to newer EAPI and thus would get these |
74 |
> functions as they get to a newer EAPI. |
75 |
> |
76 |
> Is there an actual case for downgrading back to an older EAPI? |
77 |
> |
78 |
> If not, conditional code that checks $EAPI has no purpose. |
79 |
|
80 |
and yet it exists today. as long as portage supports an EAPI, i see no reason |
81 |
to omit useful checks like this. |
82 |
-mike |