[PATCH 02/14] email-test-patchset: move project configuration parsing down a bit

[Artem Bityutskiy]

On Tue, 2014-02-04 at 17:46 +0000, Keller, Jacob E wrote:
> On Tue, 2014-02-04 at 19:27 +0200, Artem Bityutskiy wrote:
> > From: Artem Bityutskiy <artem.bityutskiy at linux.intel.com>
> > 
> > This patch is a little clean-up which makes the code a bit more consistent. It
> > makes sure we first check if the user specified the project, and only then try
> > to parse project configuration, not vice-versa.
> > 
> > Signed-off-by: Artem Bityutskiy <artem.bityutskiy at linux.intel.com>
> > ---
> >  email/aiaiai-email-test-patchset | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/email/aiaiai-email-test-patchset b/email/aiaiai-email-test-patchset
> > index b32ab16..694e008 100755
> > --- a/email/aiaiai-email-test-patchset
> > +++ b/email/aiaiai-email-test-patchset
> > @@ -198,9 +198,6 @@ prj="$(fetch_project_name "$to" "$cfg_ownmail")"
> >  
> >  verbose "Project \"$prj\""
> >  
> > -# Fetch project configuration
> > -parse_prj_config "$cfgfile" "$prj"
> > -
> >  # Reject the e-mail if the project has not been specified
> >  if [ -z "$prj" ]; then
> >  	to=
> > @@ -217,6 +214,9 @@ EOF
> >  	exit 0
> >  fi
> >  
> > +# Fetch project configuration
> > +parse_prj_config "$cfgfile" "$prj"
> > +
> >  # Check if we have this project in our config file
> >  if [ -z "$cfg_name" ]; then
> >  	to=
> 
> Hmm. I am pretty sure I posted a patch about this in my list. Either
> way, if I have I can remove it since you've done this one.

May be you did. I did not went though all of your patches yet. I just go
one-by-one, and once I spot something which I'd like to change, I either
change that right away or put to the TODO list. So I could easily change
something which you change in your patches too. But I am committed to
amend your patches as necessary.

My thinking is also that once I process your patches, I'd do some docs
improvements and release Aiaiai version 1.0. And after this I'd start
doing normal software development with releases, but-fix releases,
development branch, etc. Users would use 1.0 while 2.0 being cooked. I'd
release 1.1 if there are important bug-fixes. Etc. I am thinking to
document the process too.

I'd also like to put this stuff to 01.org, but dunno if I have enough
time. Any help is of course appreciated :=)

And may be I need to give active people push rights to the repo at some
point. So far the project did not see too many active people, though :-)
It was more like personal set of script for the kernel trees I've been
maintaining.

-- 
Best Regards,
Artem Bityutskiy