Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=4V5KGT+2eCFsW38rMX5RJWzIZ8kNS0RVWZNNpMrrkllMsJWfHbCnCSgpbzIAV93u93lxLwu1y7mg9b3E3oS4ImLMWhOtR9JP6v5UKYVZYdgk8WItn1RTWCf+uoAXmjuCDKx7gb5uP/j5JlTm/cOd9RM+h7ZYbInK8FbdgV5EDuQ=;
References: 
 <CAOFYJNYH-0rd_ZXqAx97ZkA9sk_mxuiOs4Jj5LTbnzSK6SNwvA@mail.gmail.com>
 <CAAS6=7jGVt7Axp=t5MbaEK_RqZknZMOkBytczpZOkEwHV-u-_w@mail.gmail.com>
 <1343338667.29171.140661107102377.5008EBD6@webmail.messagingengine.com>
 <1343340444.55796.YahooMailNeo@web124702.mail.ne1.yahoo.com>
 <173AE540-AF4A-47F2-ABC2-422C56FF1BAE@comcast.net>
Message-ID: <1343342661.94778.YahooMailNeo@web124704.mail.ne1.yahoo.com>
Date: Thu, 26 Jul 2012 15:44:21 -0700 (PDT)
From: Joe Schaefer <joe_schaefer@yahoo.com>
Reply-To: Joe Schaefer <joe_schaefer@yahoo.com>
Subject: Re: Incubator release task force
To: "general@incubator.apache.org" <general@incubator.apache.org>
In-Reply-To: <173AE540-AF4A-47F2-ABC2-422C56FF1BAE@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

----- Original Message -----=0A=0A> From: Dave Fisher <dave2wave@comcast.ne=
t>=0A> To: general@incubator.apache.org=0A> Cc: =0A> Sent: Thursday, July 2=
6, 2012 6:33 PM=0A> Subject: Re: Incubator release task force=0A> =0A> =0A>=
 On Jul 26, 2012, at 3:07 PM, Joe Schaefer wrote:=0A> =0A>>>  _____________=
___________________=0A>>>  From: Upayavira <uv@odoko.co.uk>=0A>>>  To: gene=
ral@incubator.apache.org =0A>>>  Sent: Thursday, July 26, 2012 5:37 PM=0A>>=
>  Subject: Re: Incubator release task force=0A>>> =0A>>>  Marvin,=0A>>> =
=0A>>>  While I (think I) can understand your concern (that it should be th=
e=0A>>>  mentors who are reviewing releases, not yet another group), I'd =
=0A> suggest=0A>>>  that Jukka's approach might be a way to get there.=0A>>=
 =0A>> =0A>>  Not for me- it is the podling's PPMC that needs to vet them p=
roperly,=0A>>  and we need to ensure that people who do a good job at that =
are suitably=0A>>  empowered to cast binding votes on release candidates.=
=A0 I can see why=0A>>  podlings will be challenged for IPMC votes the firs=
t time thru, but=0A>>  by the third release they should have enough IPMC pa=
rticipation in their=0A>>  podling that the thought of coming to general@ a=
nd begging for votes=0A>>  won't ever occur to them.=0A>> =0A>> =0A>>  The =
reasons why we don't do this have nothing to do with the release =0A> proce=
ss=0A>>  or its documentation- it's just social norms colliding from differ=
ent=0A>>  areas of the ASF.=0A>> =0A>> =0A>>> =0A>>>  The incubator release=
 process is, at the moment, pretty fraught, and I=0A>>>  suspect there are =
only a handful of people who really get it. I would=0A>> =0A>> =0A>>  It su=
cks for the same old tired rationale behind excluding competent=0A>>  peer =
reviewers from the halls of power here.=A0 Some of us think this=0A>>  is a=
 core failing of the IPMC, others disagree.=A0 If Jukka can satisfy=0A>>  t=
he anti-progressives and bring in more people willing to do a competent=0A>=
>  job of reviewing candidates simply because these people are trying to=0A=
>>  review other-podling candidates, more power to him.=A0 Again I will say=
=0A>>  that this is slightly missing the point about *competent* review ver=
sus=0A>>  a casual glance at licensing issues that someone unskilled in a c=
odebase=0A>>  might AT-BEST provide.=0A>> =0A>> =0A>>>  posit that one outc=
ome of Jukka's suggestion is a simplified =0A> release=0A>>>  process, whic=
h is likely to be understandable to a larger number of=0A>>>  mentors, mean=
ing you address your core issue.=0A>> =0A>> =0A>>  The release process *is*=
 simple but laborious- it's supposed to be that =0A> way.=0A>>  But if you'=
ve done one successful release iterating on those learnings=0A>>  is consid=
erably easier than trying to do it from scratch with just our=0A>>  bloated=
 process docs.=0A> =0A> I think that the problem is navigating the document=
ation. Most IP and packaging =0A> questions have specific circumstances. It=
 should be possible to look for answers =0A> using this data.=0A> =0A> As a=
 mentor I would really like to be able to point to either a decision tree o=
r =0A> matrix for how to include, produce and consume binary artifacts, bui=
ld =0A> dependencies, and source license categories in svn, source releases=
, and =0A> unofficial binary artifacts.=0A=0AI'm sure I speak for Marvin wh=
en I say I would love to participate on a task=0Aforce dedicated to produci=
ng such documentation, but I am also weary about=0Awriting about a whole bu=
nch of hypotheticals that nobody (other than Roy)=0Ahas a really good handl=
e on anyway.=A0 Yes, it's far easier for podlings to repeat=0Awhat some exi=
sting project has done than to recognize their situation as belonging=0Ato =
an abstract category we have addressed somehow here.=A0 I worry about armin=
g=0Athe people who fuss about such stuff as if it were critical to address =
everything=0Ain *this* release instead of simply accepting a promise to fix=
 certain things in=0Athe next.=0A=0A> =0A> Podlings can then lookup the ans=
wer according to the circumstance. The answer =0A> can reference the bloate=
d docs for the reasoning.=0A> =0A> To avoid creating meta-bloat these trees=
 and matrices would need to be kept to =0A> an absolute minimum with broad =
categories.=0A> =0A> Regards,=0A> Dave=0A> =0A>> =0A> =0A> =0A> =0A>> =0A>>=
  ---------------------------------------------------------------------=0A>=
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org=0A>>  F=
or additional commands, e-mail: general-help@incubator.apache.org=0A>> =0A>=
 =0A> =0A> ----------------------------------------------------------------=
-----=0A> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org=
=0A> For additional commands, e-mail: general-help@incubator.apache.org=0A>=
 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org