On Monday 13 January 2014 22:23:01 Tom Wijsman wrote:
> On Mon, 13 Jan 2014 19:50:44 -0500 Mike Frysinger wrote:
> > On Monday 13 January 2014 19:08:30 creffett@gentoo.org wrote:
> > > From: Chris Reffett <creffett@gentoo.org>
> > > Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if
> > > src_prepare/src_configure are used in EAPI 0/1
> 
> Well, I was planning to cover these bugs; seems we really need to
> organize with regards to avoiding double work, as two others have got
> the same happen to them. Let's synchronize it.

we have a bugzilla workflow doc posted which we'll merge once git is back up.  
please do not reassign portage bugs to yourself.  instead, set the status to 
INPROGRESS.

> While vapier's case could be considered as valid; I think we should
> consider that as a bad practice, as one could just as well put the if
> inside a phase which is the much more common practice.

certainly, but we need to notify the dev community first

> As a note, my WIP work is at the next url; there you can see the bug
> numbers I've been working on (still need to revise them, properly
> document the added check errors [eg. in `man repoman`] and so on).
> 
> https://github.com/TomWij/gentoo-portage-next/branches

we probably should just use dev branches in the main repo, at least for people 
who have write access to the repo
	dev/$USERNAME/<whatever you want>

> > you might want to set ~/.gitconfig to have your name/email so that
> > git sendemail uses the right info in the actual e-mail From: field
> 
> Then what is the From: field that it puts separately into the e-mail
> itself?

the Author field of the git commit

> Seems quite odd for these to differ; or, is the latter an
> attempt to mark the author? Then why does the e-mail From: field need
> to be correct? Afaik it would only use one of both, so only one of both
> needs to be correct. But that would make the actual question: Which one?

if they differ, git will post the From: as the first line of the body so that 
`git am` can do the right thing.  if they're the same, then git omits it.

they don't *need* to be the same for patches to be merged correctly, but they 
should be the same to cut down on extraneous noise.  the focus is the commit 
message/code, not other random junk that takes 3 seconds to fix with a 
configuration tweak.

> > i'd suggest merging the regex a little:
> > 	r'^\ssrc_(configure|prepare)\s*\(\)'
> 
> Note that the * behind the first \s was lost; so, with the redundant ^
> removed and the * put back it would be:

yes, typo when i hand wrote it

>         r'\s*src_(configure|prepare)\s*\(\)'
> 
> You can then proceed further and move the re outside:

the idea was to walk a balance between simplicity and maintainability.  imo, 
the fixed version above is the best.

> > the regex is naive and can match valid ebuilds.  consider ones that
> > handle $EAPI itself and will call the right funcs as necessary.
> 
> From a QA point of view it seems more preferable to move away from old
> EAPIs, than to conditionally support them. The common case is that
> ebuilds move from older to newer EAPI and thus would get these
> functions as they get to a newer EAPI.
> 
> Is there an actual case for downgrading back to an older EAPI?
> 
> If not, conditional code that checks $EAPI has no purpose.

and yet it exists today.  as long as portage supports an EAPI, i see no reason 
to omit useful checks like this.
-mike