Re: Digests in releases

[Joe Schaefer]

Henk's scripting does that and much more.

On Thu, Aug 31, 2017 at 5:09 PM Ted Dunning  wrote:

> I thought that gpg does that.
>
> On Thu, Aug 31, 2017 at 1:35 PM, Dave Fisher 
> wrote:
>
> > Regardless of what Jane User knows, and we have 200 million Jane Users of
> > Apache OpenOffice, I think it would be helpful to have an Apache Download
> > checker program/script that could be run to confirm the bonafides.
> >
> > An idea.
> >
> > Regards,
> > Dave
> >
> > > On Aug 31, 2017, at 1:22 PM, Julian Hyde 
> wrote:
> > >
> > > I know this. You know this. Joe User does not know this. I am trying to
> > make Joe User’s life easier.
> > >
> > > Since SHA256 is sufficient for both purposes why does release policy
> > MANDATE that projects include an MD5?
> > >
> > > Julian
> > >b
> > >
> > >> On Aug 31, 2017, at 1:17 PM, Ted Dunning 
> wrote:
> > >>
> > >> The checksum is not a tampering countermeasure.
> > >>
> > >> It is a "mirror ran out of diskpace" or "IP checksums are only 32
> bits"
> > >> countermeasure.
> > >>
> > >>
> > >>
> > >> On Thu, Aug 31, 2017 at 11:35 AM, Julian Hyde 
> wrote:
> > >>
> > >>> As security experts, you and I know that. But Joe User maybe only
> > checks
> > >>> one digest.
> > >>>
> > >>> (Aren’t we all Joe User sometimes?)
> > >>>
> > >>> Julian
> > >>>
> >  On Aug 31, 2017, at 11:30 AM, Mike Jumper  >
> > >>> wrote:
> > 
> >  On Aug 31, 2017 11:21, "Julian Hyde"  wrote:
> > 
> >  After downloading artifacts, there are 3 things to check: (1) the
> > >>> download
> >  is successful; (2) the artifacts were indeed created by the named
> > author;
> >  and (3) the artifacts have not been tampered with.
> > 
> >  A security expert would know to use the .md5 for (1), the .asc for
> > (2),
> > >>> and
> >  the .sha256 or .sha512 for (3).
> > 
> > 
> >  If there is a danger that the artifacts may be tampered with, there
> > is an
> >  equivalent danger that the checksum files will be tampered with, as
> > well.
> >  Checksums alone cannot be relied upon to verify an artifact hasn't
> > been
> >  altered.
> > 
> >  Only the signature allows verification of authorship and integrity
> ...
> >  assuming users have secure access to the corresponding public keys,
> > and
> >  that those keys are linked into the web of trust.
> > 
> >  - Mike
> > >>>
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >>> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>>
> > >>>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
>

Re: Emailing images.

[Joe Schaefer]

The attachment stripping feature in ezmlm is configurable by the
infrastructure team on a per list basis.  I believe the -x flag governs
that feature.

On Wed, May 31, 2017 at 12:57 PM James Bognar 
wrote:

> Since images are lost on apache emails, what have other teams done if they
> want to include images on messages to their dev list account?
>
> What are our options?  Upload to Imgur and attach URL?  Other ideas?
>

Re: Incubator Governance Change

[Joe Schaefer]

What exactly are we trying to achieve here?  There is a record number of
podlings in incubation and the best ideas so far are to shame more labor
out of the people that are already overloaded.  Sure that will work, as if
burnout wasn't already a problem for mentors.

What is the lesson for the podling?  That the only votes Apache cares about
are those performed by people who have never vetted a single commit to the
codebase?  Is this what community based development is all about, where
overworked bureaucrats put their fingers in various dykes pretending that
only they can function as the true gatekeepers to the arcane secrets of the
org?  Is it any wonder where animosity towards the org by those being
subjected to this mindset comes from, or that in the end what it breeds is
more harmful to the overall mission to graduate healthy projects than any
policy imperfections in podling releases overlooked by actual engineers
trying to get shit out the door?  Isn't that what the disclaimer is
supposed to be there for, instead of yet another imposition on the victims
of this nonsense?

Grow up folks.


On Wed, Apr 26, 2017 at 2:04 AM, Niclas Hedhman  wrote:

> Either you draw the parallels to the TLPs or you don't.
>
> If you do, TLPs don't have Mentors, but they do have a PMC, typically with
> engaged members and a 'phone line" to the board in forms of a Chair. If the
> "Chair" goes AWOL, then either the PMC members request help from the board
> to appoint a new Chair, typically by submission of a resolution, or the
> board notices that the phone is no longer ringing, in which case the PMC is
> asked if it has died or not.
>
> Translate;
> PMC -> Podling committers
> PMC Chair -> Mentor
> Board -> Incubator PMC
>
> Now, we have the complication that there are 3 mentors, sometimes all
> assuming that the "others" will handle it, and podlings are unwise about
> what is expected.
>
> I have argued before for a single Mentor, with responsibilities just like
> the PMC Chairs and if failing the duties, duly replaced by IPMC. The
> counter-argument to single Mentor is that podlings need 3 binding votes,
> and I suggest to change the role names here to perhaps "Supporter" and the
> Mentor simply emeritus any Supporter that is absent too long, and come to
> IPMC to request more help.
>
> Hopefully, we can get to a position where podlings are not asking for IPMC
> release votes, just like TLPs are not asking for Board's approval of
> releases.
>
> And I think that if the Mentors are then keeping a up-to-date rooster on
> Supporters, we have a pretty good overview of podlings' health.
>
>
> Cheers
> Niclas
>
>
>
> On Wed, Apr 26, 2017 at 1:37 PM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz 
> > wrote:
> > > ...I mostly agree, but would hesitate with the idea that a podling be
> > responsible for raising a red flag
> > > when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on
> > us, not the projects we incubate
> >
> > The IPMC will typically not know before it's too late, so it's good
> > for the podlings to raise those red flags - and ask the IPMC for help.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: Incubator Governance Change

[Joe Schaefer]

Continuing down the road of blaming each other for the problem is stupid.
Look the personnel is already ready, willing, and available to do the real
vetting.
All the IPMC has to do is recognize them and integrate them.

On Wed, Apr 26, 2017 at 1:37 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz 
> wrote:
> > ...I mostly agree, but would hesitate with the idea that a podling be
> responsible for raising a red flag
> > when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on
> us, not the projects we incubate
>
> The IPMC will typically not know before it's too late, so it's good
> for the podlings to raise those red flags - and ask the IPMC for help.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache PredictionIO 0.11.0 (incubating) RC2

[Joe Schaefer]

How many binding votes do you need at this point?
On Wed, Apr 19, 2017 at 12:34 PM Pat Ferrel  wrote:

> +1 non-binding
>
> Next release we could exclude the doc site. Do build files like .sbt
> require licenses? I suppose it can be done in comments. But again can we
> push to next release?
>
> Can other binding voters have a look? I know everyone is busy but hey, tax
> day is past ;-)
>
>
> On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
>
> Hi Luciano,
>
> Thanks for your review. I will file JIRAs regarding these files. They are
> project build files and documentation.
>
> Regards,
> Donald
>
> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
> wrote:
>
> > On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
> wrote:
> >
> >> Hi all,
> >>
> >> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
> > good
> >> for a source-only release. This thread is to facilitate a voting for the
> >> IPMC before a final official source-only release.
> >>
> >> Vote result on dev@:
> >> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> >> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> >>
> >> The original vote thread on dev@:
> >> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> >> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> >>
> >> The release candidate Git commit is:
> >> e34a853d0e89baed09b3d3b0c25b244162a3bdea
> >>
> >> The release candidate Git tag is:
> >> v0.11.0-incubating-rc2
> >>
> >> The source-only release candidate artifacts can be downloaded here:
> >> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> >> incubating-rc2/
> >>
> >> Test results of RC2 can be found here:
> >> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> >>
> >> Build instructions of previous versions can be used on this RC:
> >> http://predictionio.incubator.apache.org/install/install-sourcecode/
> >>
> >> Maven artifacts are built from the release candidate artifacts above,
> and
> >> are provided as convenience for testing with PredictionIO engine
> > templates.
> >> The Maven artifacts are provided at the Maven staging repo here:
> >> https://repository.apache.org/content/repositories/
> >> orgapachepredictionio-1016/
> >>
> >> All JIRAs completed for this release are tagged with 'FixVersion =
> >> 0.11.0-incubating'. You can view them here:
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >> projectId=12320420=12338381
> >>
> >> The artifacts have been signed with Key : 8BF4ABEB
> >>
> >> Please vote accordingly:
> >>
> >> [ ] +1, accept RC as the official 0.11.0 release
> >> [ ] 0, neutral because...
> >> [ ] -1, do not accept RC as the official 0.11.0 release because...
> >>
> >> The vote will be open for 72 hours and close at 12pm PDT 4/16/2016.
> >>
> >> Regards,
> >> Donald
> >>
> >
> >
> > I was running RAT on the source distribution and there are a lot of
> unknown
> > licenses, some might be ok, but many are not, such as:
> >
> > *.sbt in projects and sub-projects
> > *.css in docs
> >
> > Other things like signatures, etc seems ok
> >
> >
> >
> > --
> > Luciano Resende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Incubator Governance Change

[Joe Schaefer]

Your proposal violates foundation policy on releases and is therefore a
nonstarter.  The ipmc isn't empowered to restructure release policy.

That said, talk to your project mentors about nominating competent release
managers and others participating constructively in the vetting process at
the podling level to the ipmc.  It seems we've dropped the ball again on a
problem we solved years ago by not keeping up with the pace of growth.


On Sat, Apr 22, 2017 at 1:47 PM Pat Ferrel <p...@occamsmachete.com> wrote:

> While I agree, asking is not enforcing. This would add enforcement that
> would allow the IPMC to function but have an enforceable clause that also
> does not allow it to roadblock by neglect.
>
> Plus about 1/2 the reason I bring this up is trying to get more votes on
> PredictionIO :-)
>
>
> On Apr 22, 2017, at 10:41 AM, Julian Hyde <jh...@apache.org> wrote:
>
> Growing the IPMC is of no use if the members don’t show up and vote.
>
> The IPMC performs an important gatekeeper role, ensuring that podling
> releases are of sufficient quality to bear the “Apache (Incubating)” stamp.
> In my view, all IPMC members have a duty to help with that gatekeeping
> role. If they don’t, the extra burden falls on other IPMC members, and
> podlings have a crappy experience.
>
> I don’t think two votes per year is too much to ask. If you’re not up to
> it, resign from the IPMC.
>
> Julian
>
>
>
> > On Apr 22, 2017, at 10:15 AM, Joe Schaefer <joes...@gmail.com> wrote:
> >
> > The traditional response to this issue is to grow the ipmc to incorporate
> > more podling committers.
> >
> > On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde <jh...@apache.org> wrote:
> >
> >> I agree that lack of IPMC votes is a problem. I don’t think that
> lowering
> >> the bar to making a release is the solution.
> >>
> >> I wish that each IPMC member would personally commit to voting on two
> >> release candidates per year. There are so many members of the IPMC that
> >> this would easily cover all of the votes that come up.
> >>
> >> Julian
> >>
> >>
> >>> On Apr 22, 2017, at 8:46 AM, Pat Ferrel <p...@occamsmachete.com> wrote:
> >>>
> >>> Probably the wrong place for this but…
> >>>
> >>> What do people think about a governance change for approving releases
> >> through the IPMC to wit:
> >>>
> >>> A week of no vote activity over the release proposal of a podling
> should
> >> be considered a passing vote. In other words the IPMC is to become a
> >> vetoing group.
> >>>
> >>> I propose this for 2 reasons: 1) lack of votes or attention from the
> >> IPMC seems all too prevalent and puts an undo drag on the energy and
> >> velocity of community involvement. 2) the release has already been
> voted on
> >> and checked by at least 3 PMC members of the podling (which has ASF
> mentors
> >> in most all cases) so a veto role by the IPMC seems to have minimum
> danger
> >> to the ASF system of checks and balances.
> >>>
> >>>
> >>>
> >>>
> >>> On Apr 19, 2017, at 9:33 AM, Pat Ferrel <p...@occamsmachete.com> wrote:
> >>>
> >>> +1 non-binding
> >>>
> >>> Next release we could exclude the doc site. Do build files like .sbt
> >> require licenses? I suppose it can be done in comments. But again can we
> >> push to next release
> >>>
> >>> Can other binding voters have a look? I know everyone is busy but hey,
> >> tax day is past ;-)
> >>>
> >>>
> >>> On Apr 18, 2017, at 1:00 PM, Donald Szeto <don...@apache.org> wrote:
> >>>
> >>> Hi Luciano,
> >>>
> >>> Thanks for your review. I will file JIRAs regarding these files. They
> are
> >>> project build files and documentation.
> >>>
> >>> Regards,
> >>> Donald
> >>>
> >>> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende <luckbr1...@gmail.com
> >
> >>> wrote:
> >>>
> >>>> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto <don...@apache.org>
> >> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
> >>>> good
> >>>>> for a source-only release. This thread is to facilitate a voting for
> >> the
> >>>>> IPMC befor

Re: Weex release needs votes, vetting, ++

[Joe Schaefer]

How many binding votes do you lack?

On Sat, Apr 22, 2017 at 3:40 AM Niclas Hedhman  wrote:

> The third RC is placed before the Incubator and hoping to get through the
> door.
>
> Any takers?
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: Incubator Governance Change

[Joe Schaefer]

Incorrect.  These people I'm talking about are already voting on (their
own) releases, we just fail to count their votes as binding because we are
anally retentitive about our own status.

On Sat, Apr 22, 2017 at 1:41 PM Julian Hyde <jh...@apache.org> wrote:

> Growing the IPMC is of no use if the members don’t show up and vote.
>
> The IPMC performs an important gatekeeper role, ensuring that podling
> releases are of sufficient quality to bear the “Apache (Incubating)” stamp.
> In my view, all IPMC members have a duty to help with that gatekeeping
> role. If they don’t, the extra burden falls on other IPMC members, and
> podlings have a crappy experience.
>
> I don’t think two votes per year is too much to ask. If you’re not up to
> it, resign from the IPMC.
>
> Julian
>
>
>
> > On Apr 22, 2017, at 10:15 AM, Joe Schaefer <joes...@gmail.com> wrote:
> >
> > The traditional response to this issue is to grow the ipmc to incorporate
> > more podling committers.
> >
> > On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde <jh...@apache.org> wrote:
> >
> >> I agree that lack of IPMC votes is a problem. I don’t think that
> lowering
> >> the bar to making a release is the solution.
> >>
> >> I wish that each IPMC member would personally commit to voting on two
> >> release candidates per year. There are so many members of the IPMC that
> >> this would easily cover all of the votes that come up.
> >>
> >> Julian
> >>
> >>
> >>> On Apr 22, 2017, at 8:46 AM, Pat Ferrel <p...@occamsmachete.com> wrote:
> >>>
> >>> Probably the wrong place for this but…
> >>>
> >>> What do people think about a governance change for approving releases
> >> through the IPMC to wit:
> >>>
> >>> A week of no vote activity over the release proposal of a podling
> should
> >> be considered a passing vote. In other words the IPMC is to become a
> >> vetoing group.
> >>>
> >>> I propose this for 2 reasons: 1) lack of votes or attention from the
> >> IPMC seems all too prevalent and puts an undo drag on the energy and
> >> velocity of community involvement. 2) the release has already been
> voted on
> >> and checked by at least 3 PMC members of the podling (which has ASF
> mentors
> >> in most all cases) so a veto role by the IPMC seems to have minimum
> danger
> >> to the ASF system of checks and balances.
> >>>
> >>>
> >>>
> >>>
> >>> On Apr 19, 2017, at 9:33 AM, Pat Ferrel <p...@occamsmachete.com> wrote:
> >>>
> >>> +1 non-binding
> >>>
> >>> Next release we could exclude the doc site. Do build files like .sbt
> >> require licenses? I suppose it can be done in comments. But again can we
> >> push to next release
> >>>
> >>> Can other binding voters have a look? I know everyone is busy but hey,
> >> tax day is past ;-)
> >>>
> >>>
> >>> On Apr 18, 2017, at 1:00 PM, Donald Szeto <don...@apache.org> wrote:
> >>>
> >>> Hi Luciano,
> >>>
> >>> Thanks for your review. I will file JIRAs regarding these files. They
> are
> >>> project build files and documentation.
> >>>
> >>> Regards,
> >>> Donald
> >>>
> >>> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende <luckbr1...@gmail.com
> >
> >>> wrote:
> >>>
> >>>> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto <don...@apache.org>
> >> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
> >>>> good
> >>>>> for a source-only release. This thread is to facilitate a voting for
> >> the
> >>>>> IPMC before a final official source-only release.
> >>>>>
> >>>>> Vote result on dev@:
> >>>>> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> >>>>> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> >>>>>
> >>>>> The original vote thread on dev@:
> >>>>> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> >>>>> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> >>>>>
> >>>>> The release candidate Git commit i

Re: Incubator Governance Change

[Joe Schaefer]

The traditional response to this issue is to grow the ipmc to incorporate
more podling committers.

On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde  wrote:

> I agree that lack of IPMC votes is a problem. I don’t think that lowering
> the bar to making a release is the solution.
>
> I wish that each IPMC member would personally commit to voting on two
> release candidates per year. There are so many members of the IPMC that
> this would easily cover all of the votes that come up.
>
> Julian
>
>
> > On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> >
> > Probably the wrong place for this but…
> >
> > What do people think about a governance change for approving releases
> through the IPMC to wit:
> >
> > A week of no vote activity over the release proposal of a podling should
> be considered a passing vote. In other words the IPMC is to become a
> vetoing group.
> >
> > I propose this for 2 reasons: 1) lack of votes or attention from the
> IPMC seems all too prevalent and puts an undo drag on the energy and
> velocity of community involvement. 2) the release has already been voted on
> and checked by at least 3 PMC members of the podling (which has ASF mentors
> in most all cases) so a veto role by the IPMC seems to have minimum danger
> to the ASF system of checks and balances.
> >
> >
> >
> >
> > On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> >
> > +1 non-binding
> >
> > Next release we could exclude the doc site. Do build files like .sbt
> require licenses? I suppose it can be done in comments. But again can we
> push to next release
> >
> > Can other binding voters have a look? I know everyone is busy but hey,
> tax day is past ;-)
> >
> >
> > On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> >
> > Hi Luciano,
> >
> > Thanks for your review. I will file JIRAs regarding these files. They are
> > project build files and documentation.
> >
> > Regards,
> > Donald
> >
> > On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
> > wrote:
> >
> >> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
> >> good
> >>> for a source-only release. This thread is to facilitate a voting for
> the
> >>> IPMC before a final official source-only release.
> >>>
> >>> Vote result on dev@:
> >>> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> >>> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> >>>
> >>> The original vote thread on dev@:
> >>> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> >>> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> >>>
> >>> The release candidate Git commit is:
> >>> e34a853d0e89baed09b3d3b0c25b244162a3bdea
> >>>
> >>> The release candidate Git tag is:
> >>> v0.11.0-incubating-rc2
> >>>
> >>> The source-only release candidate artifacts can be downloaded here:
> >>> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> >>> incubating-rc2/
> >>>
> >>> Test results of RC2 can be found here:
> >>> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> >>>
> >>> Build instructions of previous versions can be used on this RC:
> >>> http://predictionio.incubator.apache.org/install/install-sourcecode/
> >>>
> >>> Maven artifacts are built from the release candidate artifacts above,
> and
> >>> are provided as convenience for testing with PredictionIO engine
> >> templates.
> >>> The Maven artifacts are provided at the Maven staging repo here:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapachepredictionio-1016/
> >>>
> >>> All JIRAs completed for this release are tagged with 'FixVersion =
> >>> 0.11.0-incubating'. You can view them here:
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >>> projectId=12320420=12338381
> >>>
> >>> The artifacts have been signed with Key : 8BF4ABEB
> >>>
> >>> Please vote accordingly:
> >>>
> >>> [ ] +1, accept RC as the official 0.11.0 release
> >>> [ ] 0, neutral because...
> >>> [ ] -1, do not accept RC as the official 0.11.0 release because...
> >>>
> >>> The vote will be open for 72 hours and close at 12pm PDT 4/16/2016.
> >>>
> >>> Regards,
> >>> Donald
> >>>
> >>
> >>
> >> I was running RAT on the source distribution and there are a lot of
> unknown
> >> licenses, some might be ok, but many are not, such as:
> >>
> >> *.sbt in projects and sub-projects
> >> *.css in docs
> >>
> >> Other things like signatures, etc seems ok
> >>
> >>
> >>
> >> --
> >> Luciano Resende
> >> http://twitter.com/lresende1975
> >> http://lresende.blogspot.com/
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> 

Re: [DISCUSS] Policy Question: GA for GitHub for Podlings

[Joe Schaefer]

With regard to the second question I hope the ultimate decision still rests
with Greg.  This idea is fairly new and some baby steps are in order before
opening the floodgates.

IMO

On Monday, November 7, 2016, Chris Mattmann  wrote:

> Hi,
>
> As some of you may have seen the OpenWhisk podling being discussed now has
> requested to use GitHub as its primary master. Greg Stein our ASF Infra
> Admin
> has OK’ed this for OpenWhisk iff the IPMC is OK with it.
>
> I ask now:
>
> 1. Is the IPMC OK with this for OpenWhisk?
> 2. Is the IPMC OK with this in general availability for Podlings?
>
> I am +1 on both (IPMC hat on).
>
> Thanks.
>
> Cheers,
> Chris
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Joe Schaefer]

This saga jumped the shark right about the time Mary the sonnetor weighted
in.

On Thursday, November 26, 2015, Ralph Goers 
wrote:

> Sorry Jim. As an attempt to shut down a thread, this wasn't a very good
> one.  Not a single poster in this thread has a problem with the word, or
> the concept of, "review". It is the process that is the issue and what the
> impact of that process is upon a community.
>
> Ralph
>
> > On Nov 26, 2015, at 6:50 AM, Jim Jagielski  wrote:
> >
> > OK, ok... we are at diminishing returns here with people
> > no longer, imo, listening to what others are saying...
> >
> > We have, as a foundation, and HAVE HAD RTC and CTR for years
> > and decades. There are times when one or the other are Good
> > and when they are Bad. Those exact times will, generally,
> > vary depending on a lot of factors.
> >
> > We use the right process when it is Good.
> >
> > We don't use it when it is Bad.
> >
> > Just as 'meritocracy' is not a bad word, as much as
> > some people wish to re-define it as such, neither is the
> > word 'Review'.
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> > For additional commands, e-mail: general-h...@incubator.apache.org
> 
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

Re: [VOTE] TinkerPop 3.1.0-incubating Release

[Joe Schaefer]

Thank you Mary, and welcome aboard!  You are an inspiration to others!

On Sun, Nov 22, 2015 at 10:10 AM, Mary the sonnetor <
marywantsalittlelamb...@gmail.com> wrote:

> And another thing..it has no names so I do have a right for legal issues
> and publication.
>
> inspirational laison
> On 22 Nov 2015 09:02, marywantsalittlelamb...@gmail.com wrote:
>
> That's OK. I have it saved for a higher authority.
>
> inspirational laison
> On 22 Nov 2015 08:45, "Stephen Mallette"  wrote:
>
> tbh, I've never found that licensing how-to document terribly clear - i
> feel like i get a different read of it every time i go through it.  maybe
> it's just me.
>
> anyway, I've read it again, in the context of what you've said here, and it
> seems like we should not have included the Apache licensed dependencies in
> the binary LICENSE file, so that has been removed:
>
>
> https://github.com/apache/incubator-tinkerpop/blob/6e08d186850457bab4e15ddf603f50fd16728f41/gremlin-console/src/main/LICENSE
>
> https://github.com/apache/incubator-tinkerpop/blob/6e08d186850457bab4e15ddf603f50fd16728f41/gremlin-server/src/main/LICENSE
>
> I didn't change the binary NOTICE files as I believe that their contents
> are just Apache licensed stuff that themselves have NOTICE so given [1] I
> think I have this right.
>
> I also adjusted the source LICENSE/NOTICE given your recent feedback on
> Activiti:
>
>
> https://github.com/apache/incubator-tinkerpop/blob/6e08d186850457bab4e15ddf603f50fd16728f41/LICENSE
>
> https://github.com/apache/incubator-tinkerpop/blob/6e08d186850457bab4e15ddf603f50fd16728f41/NOTICE
>
> how's that looking?
>
> 1. http://www.apache.org/dev/licensing-howto.html#mod-notice
>
> On Sun, Nov 22, 2015 at 2:36 AM, Justin Mclean 
> wrote:
>
> > HI,
> >
> > > Maybe we did something wrong here, but those classes are here:
> > >
> > >
> >
>
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphml/GraphMLWriterHelper.java
> > >
> > > The are basically just recreated as inner classes in that java file.
> >
> > Nothing "wrong" as they are Apache licensed however you may need to
> change
> > NOTICE as described in the previous mail.
> >
> > > The link you posted was for 3.0.0-incubating,
> >
> > Yes that where the issue was originally brought up and it’s not been
> > corrected in this release.
> >
> > > I something amiss in our current version that you still see wrong
> > somehow?
> >
> > Yes the LICENSE and NOTICE are not correct in the binary files, most of
> > what what's in NOTICE should be in LICENSE or not included at all. The
> > assembling license and notice page spells it out quite clearly [1]. In
> > particular look at the section on adding permissive software and what
> > doesn’t go in NOTICE.
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/dev/licensing-howto.html
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Joe Schaefer]

Thank you Mary and welcome aboard!  You are an inspiration
for others!

On Sun, Nov 22, 2015 at 8:08 AM, Mary the sonnetor <
marywantsalittlelamb...@gmail.com> wrote:

> I'm am in the process of learning all this fascinating tech things. That's
> why I was looking at the different outputs.  I'm so not hurting or meddling
> in anybody's life nor I ever want to. Just like the opposing people
> received a chance. I too deserve 1. I'm sorry someone feels that way about
> me but I have a lot of enriching knowledge to give with a warm heart and
> great care for people.
>
> inspirational laison
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Joe Schaefer]

Completely agreed Todd about the irrelevance of these ad hoc assessments
of something nobody actually questions.

On Tue, Nov 17, 2015 at 7:45 PM, Todd Lipcon  wrote:

> On Tue, Nov 17, 2015 at 4:37 PM, Konstantin Boudnik 
> wrote:
>
> > On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> > > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning 
> > wrote:
> > > > ...RTC can be framed as "I don't trust you to do things right"...
> > >
> > > Or also "I don't trust myself 100% to do things right here and would
> > > like systematic reviews of my commits".
> >
> > This sounds like "if I don't trust myself then no-one has to have this
> > freedom/choice/ability", eh?
> >
>
> I'd never advocate that the ASF _mandate_ RTC on other projects. But if a
> project community decides to set up their process as such, I don't see why
> the foundation should have any issues with it. That's all I've been arguing
> in this thread: this whole discussion has pretty much no business in the
> incubator.
>
> -Todd
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Joe Schaefer]

Come on folks it's not cut and dry.  Httpd uses both without fuss about
roles, trust, etc.  This is a process issue much like the choice of version
control tool you select, it really is not a big deal.

On Wednesday, November 18, 2015, Dave Fisher  wrote:

> I see the essence of what it means to be a committer. Being trusted to
> both do the correct action and be willing to listen objectively to
> criticism. In an CTR project it is clear to me that the point where a
> project grants Committership should be the point where the PMC wants to
> treat an individual's contribution as CTR rather than RTC. How does an RTC
> project make THAT important decision?
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Nov 17, 2015, at 3:53 PM, Upayavira >
> wrote:
> >
> >
> >
> >> On Tue, Nov 17, 2015, at 06:01 PM, Rob Vesse wrote:
> >>> On 17/11/2015 16:50, "Steve Loughran"  > wrote:
> >>>
> >>> If someone were to have some metrics of projects, the state of
> >>> patches/pull requests would be a key issue.
> >>
> >> https://github.com/rvesse/gh-pr-stats
> >>
> >> Given a GitHub project generates statistics about the state of the Pull
> >> Requests in the project e.g.
> >>
> >> ./pr-stats apache hadoop
> >>
> >> Fairly basic tool but should give you enough to gauge where things are
> >
> > One of the things that this conversation seems to miss, to me, is
> > defining what "C" is.
> >
> > In some sense, C is simply the act of publishing a change. The change
> > MUST be published before the review, otherwise review is, obviously,
> > impossible (how can you review something you cannot see?)
> >
> > What's important, as I think Greg was saying earlier, is *how we relate
> > to each other*. Do I need to ask for PERMISSION to finally push a change
> > through, or do my colleagues trust me to do the right thing, knowing
> > that I'll listen to their feedback, whether the review mechanism is a
> > commit mailing list, a JIRA ticket or a pull request.
> >
> > Please define what you mean by CTR or RTC before diving into further
> > discussions about their relative merit. Otherwise we'll get locked into
> > yet another ongoing discussion that leads nowhere!
> >
> > Upayavira
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> > For additional commands, e-mail: general-h...@incubator.apache.org
> 
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

Re: Releases during incubation?

[Joe Schaefer]

Subversion cut a release while in incubation on their old system.
Shouldn't pose a problem for others.

On Mon, Nov 9, 2015 at 8:03 PM, Todd Lipcon  wrote:

> Hey folks,
>
> Hopefully quick policy question here:
>
> Once a project is under proposal for incubation, what is the foundation
> policy on that project making releases outside of Apache from its current
> home?
>
> For example, suppose there's an open source project FooBar, with a public
> release FooBar 1.0.0 in use by various people out in the world. FooBar is
> then proposed to the incubator. During the discussion/voting timeframe,
> someone discovers a bug in FooBar 1.0.0, and the team would like to release
> FooBar 1.0.1 from the project's current home (eg github). Would this be an
> issue?
>
> More controversial variant:
>
> How about early during the incubation period, while the project is still in
> the process of transitioning the necessary infrastructure, etc, into the
> ASF repositories? Assuming that the project is making good faith efforts
> towards making a release compatible with ASF guidelines, would it be
> allowed to make "external" releases during this initial period of
> incubation, for the purposes of bug fixes?
>
> Thanks
> Todd
>

maturity guidelines (was Re: Concerning Sentry: A disagreement over the Apache Way and graduation)

[Joe Schaefer]

I don't think anybody is pining to make compliance with Bertrand's very nice
document into a policy document.  Rather, some people are finding it a
useful
guide to gauging project maturity, which is great and should be encouraged.


On Thu, Nov 5, 2015 at 1:35 PM, larry mccay  wrote:

> Hi Caleb -
>
> I am glad that it is useful for your projects.
>
> I think that the use of it that you describe is valuable.
> It should be used as guidance and interpreted by the mentors for each
> podling.
>
> "These sort of metrics can be used to indicate health in this way or that"
> - this is different from "these specific metrics must be met".
>
> We can certainly articulate requirements but they should be more specific
> to behaving in accordance to "the apache way" then dictating very specific
> community decisions or milestones.
>
> As mentor training, guidelines, etc - this is quite valuable and should
> help in guiding podlings to graduation rather than deciding whether they
> graduate or not.
>
> thanks,
>
> --larry
>
> On Thu, Nov 5, 2015 at 1:12 PM, Caleb Welton  wrote:
>
> > I am not in favor of bureaucracy, However...
> >
> > Having reviewed the maturity model and speaking as a member of a newly
> > incubating podling I would like to chime in to say that I find it very
> > useful.  It helps frame discussions around what we can be doing as a
> > community to embrace the apache way, move towards more inclusive
> > development and communication models, and gives a sense of direction we
> > need to be moving towards.
> >
> > Especially starting with an established team working on close source
> > project and bringing it into Apache requires some cultural change and
> > entering into a newly incubating podling can feel a bit like diving into
> > the unknown. Having some structured recommendations on what we can do to
> > help move things in the right direction is useful and helps provide
> > guidance.  For the communities that I'm engaged with I'm actively
> > encouraging us to voluntarily use this tool because I think it provides
> > useful guidance.
> >
> > If you think the tool as expressed enforces "rote learning" how would you
> > suggest improving it to account for differences in communities?  Are
> there
> > particular points within the tool that you find less useful, or things
> that
> > are missing?
> >
> > Regards,
> >   Caleb
> >
> > On Thu, Nov 5, 2015 at 9:49 AM, larry mccay  wrote:
> >
> > > +1 - I am concerned by the trend that I see developing here.
> > >
> > > A set of interview questions for evaluation is one thing but criteria
> > > checkboxes that will encourage behaviors by rote will not actually
> > develop
> > > more healthy communities just communities that can get the boxes
> checked.
> > >
> > > While certain metrics like adding PMC members may be indicators of
> > natural
> > > growth they should not be required otherwise they will be done
> > > artificially.
> > >
> > > On Thu, Nov 5, 2015 at 7:30 AM, Justin Erenkrantz <
> jus...@erenkrantz.com
> > >
> > > wrote:
> > >
> > > > On Wed, Nov 4, 2015 at 12:50 PM, Roman Shaposhnik <
> > ro...@shaposhnik.org>
> > > > wrote:
> > > > > Correct. It is a tool, but not a requirement (at least not yet).
> > > > > And since I repeatedly suggested this tool on this thread let me
> > > explain
> > > > why.
> > > >
> > > > And, this is the root of my concern expressed in the other general@
> > > > thread: I fear that this is going to quickly evolve to yet another
> > > > bureaucratic form that the IPMC is going to quickly require all
> > > > projects to complete.
> > > >
> > > > We should not be trying to force rote learning.  Every community is
> > > > different.
> > > >
> > > > Trust the mentors or don't - but, I am very much opposed to more
> > > > overhead.  Forcing projects to feel like they have to report monthly
> > > > is against what we should be about.  I believe that the IPMC should
> be
> > > > imposing the barest amount of overhead to what the Board requires
> from
> > > > the full projects.  To that end, having mentors explicitly sign-off
> is
> > > > fair - but, additional paperwork is not.  -- justin
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > >
> > >
> >
>

Re: maturity guidelines (was Re: Concerning Sentry: A disagreement over the Apache Way and graduation)

[Joe Schaefer]

IIRC you Roman were on the list of "undersigned" ;-).
It got shot down for many, many reasons.

On Thu, Nov 5, 2015 at 4:37 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> On Thu, Nov 5, 2015 at 1:33 PM, Joe Schaefer <joes...@gmail.com> wrote:
> > I don't think anybody is pining to make compliance with Bertrand's very
> nice
> > document into a policy document.
>
> To be fair, one offshoot of the 'undersigned' epic had that implication.
> It got shot down with 'trust the mentors' argument. And..
>
> > Rather, some people are finding it a useful
> > guide to gauging project maturity, which is great and should be
> encouraged.
>
> ...that brought us to our current, much less forceful, treatment
> of the maturity model. Which is what I (and a few others including
> it seems yourself) have been advocating on *this* thread.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Just to contrast this with the IPMC itself, we discuss everything here,
including past decisions.
Almost everything that happens here is a community decision, and we try to
move with near
unanimous consent.  It is generally hard to figure out what roles people
have without some formal
VOTE where people indicate a binding status on it.

That is what you should aspire to on your dev list- it really shouldn't
matter what roles people have
unless we need to be looking at a release.



On Wed, Nov 4, 2015 at 11:37 PM, Joe Schaefer <joes...@gmail.com> wrote:

> This may sound a bit pedantic, but the "Sentry project" isn't capable of
> considering anything.
> Either you are referring to a decision of the committers or the PPMC or
> the community, all
> of which requires some discussion over time about any position being
> taken.  I would consider
> it unusual for the project participants to be unanimous on a situation
> like this or other related
> matters, and certainly opinions evolve over time.
>
> Nobody should put themselves in a position of speaking on behalf of the
> project.  That is why
> we have communication channels in the first place and generally refer to
> on list decisions.
> The individual positions of the participants should be reflected in any
> consensus-based decision
> making.  Not to say everything must be voted on, but collective decision
> making requires
> open communication, preferably on public channels.
>
>
>
> On Wed, Nov 4, 2015 at 8:26 PM, Lenni Kuff <lsk...@cloudera.com> wrote:
>
>> I think there is some confusion here. The Sentry project has never
>> considered Committer == PMC. The recent website change was only to help
>> clarify the roles of each of the members of the project, it was not the
>> result of any decision being made.
>>
>> Thanks,
>> Lenni
>>
>> On Wed, Nov 4, 2015 at 3:03 PM, P. Taylor Goetz <ptgo...@gmail.com>
>> wrote:
>>
>> >
>> >
>> > On Nov 4, 2015, at 2:05 PM, Lenni Kuff <lsk...@cloudera.com> wrote:
>> >
>> > >> On Wed, Nov 4, 2015 at 10:05 AM, P. Taylor Goetz <ptgo...@gmail.com>
>> > >> wrote:
>> > >>
>> > >>>
>> > >>> On Nov 4, 2015, at 11:32 AM, Joe Brockmeier <j...@zonker.net> wrote:
>> > >>>
>> > >>> * I would invite folks with access to go to Sentry's private list
>> and
>> > >>> look over discussions about adding new contributors, and discussions
>> > >>> about the project in general.
>> > >>>
>> > >>>
>> > >>> I took a look.
>> > >>>
>> > >>> From a community growth perspective, I see them adding new
>> committers,
>> > >>> which is a good thing. What I don’t see is any discussion at all
>> about
>> > >>> adding PPMC members, nor any discussion about why they chose to go
>> the
>> > >>> Committer != PPMC route.
>> > >>>
>> > >>> In a thread related to the first new committer being added [1], it
>> is
>> > >>> pointed out that the podling website stated that Sentry was
>> Committer
>> > ==
>> > >>> PMC, but that the new member vote was only for Committer. At that
>> point
>> > >> it
>> > >>> looks like the website was updated to reflect Committer != PMC. From
>> > that
>> > >>> point on, all new member votes were for Committer only, and there
>> were
>> > no
>> > >>> discussions regarding adding new PMC members or promoting
>> committers to
>> > >> the
>> > >>> PMC role.
>> > >>>
>> > >>> What I find slightly disconcerting is that there doesn’t seem to be
>> any
>> > >>> consideration or discussion around growing the PPMC and why that’s
>> > >>> important. Sure they have 20-odd PPMC members from the initial
>> > committers
>> > >>> list, so it would take a pretty large exodus to render the project
>> > unable
>> > >>> to function, but I don’t see anything to indicate that they
>> understand
>> > >> the
>> > >>> function and importance of growing the PPMC.
>> > >
>> > > Background: I am a Sentry community member.
>> > >
>> > > I would have to disagree with this. We have identified lack of new
>> PPMC
>> > > m

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Thanks Chris.  So what I'm saying is, instead of adopting the position
that "we" have made up our minds on this matter well before joining the
incubator, why not recognize that at this point your community now includes
new committers and new community members following along for which their
voices have not been heard from on this matter.  Once you recognize that the
community has changed a bit, it makes sense to revisit a chestnut like this
on-
list.



On Thu, Nov 5, 2015 at 12:26 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> +1 to the below.
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++
>
>
>
>
>
> -Original Message-
> From: Joe Schaefer <joes...@gmail.com>
> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org>
> Date: Wednesday, November 4, 2015 at 8:49 PM
> To: "general@incubator.apache.org" <general@incubator.apache.org>
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
>
> >Just to contrast this with the IPMC itself, we discuss everything here,
> >including past decisions.
> >Almost everything that happens here is a community decision, and we try to
> >move with near
> >unanimous consent.  It is generally hard to figure out what roles people
> >have without some formal
> >VOTE where people indicate a binding status on it.
> >
> >That is what you should aspire to on your dev list- it really shouldn't
> >matter what roles people have
> >unless we need to be looking at a release.
> >
> >
> >
> >On Wed, Nov 4, 2015 at 11:37 PM, Joe Schaefer <joes...@gmail.com> wrote:
> >
> >> This may sound a bit pedantic, but the "Sentry project" isn't capable of
> >> considering anything.
> >> Either you are referring to a decision of the committers or the PPMC or
> >> the community, all
> >> of which requires some discussion over time about any position being
> >> taken.  I would consider
> >> it unusual for the project participants to be unanimous on a situation
> >> like this or other related
> >> matters, and certainly opinions evolve over time.
> >>
> >> Nobody should put themselves in a position of speaking on behalf of the
> >> project.  That is why
> >> we have communication channels in the first place and generally refer to
> >> on list decisions.
> >> The individual positions of the participants should be reflected in any
> >> consensus-based decision
> >> making.  Not to say everything must be voted on, but collective decision
> >> making requires
> >> open communication, preferably on public channels.
> >>
> >>
> >>
> >> On Wed, Nov 4, 2015 at 8:26 PM, Lenni Kuff <lsk...@cloudera.com> wrote:
> >>
> >>> I think there is some confusion here. The Sentry project has never
> >>> considered Committer == PMC. The recent website change was only to help
> >>> clarify the roles of each of the members of the project, it was not the
> >>> result of any decision being made.
> >>>
> >>> Thanks,
> >>> Lenni
> >>>
> >>> On Wed, Nov 4, 2015 at 3:03 PM, P. Taylor Goetz <ptgo...@gmail.com>
> >>> wrote:
> >>>
> >>> >
> >>> >
> >>> > On Nov 4, 2015, at 2:05 PM, Lenni Kuff <lsk...@cloudera.com> wrote:
> >>> >
> >>> > >> On Wed, Nov 4, 2015 at 10:05 AM, P. Taylor Goetz
> >>><ptgo...@gmail.com>
> >>> > >> wrote:
> >>> > >>
> >>> > >>>
> >>> > >>> On Nov 4, 2015, at 11:32 AM, Joe Brockmeier <j...@zonker.net>
> >>>wrote:
> >>> > >>>
> >>> > >>> * I would invite folks with access to go to Sentry's private list
> >>> and
> >>> > >>> look over discussions about adding new contributors, and
> >>>discu

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Committership is the right to do work on the project. PMC membership is the
right to participate in governance.  People left in the nebulous state
between
committership and PMC membership for long periods of time more than likely
will give up in frustration for not being trusted enough to govern their
own work.


On Wed, Nov 4, 2015 at 11:49 PM, Joe Schaefer <joes...@gmail.com> wrote:

> Just to contrast this with the IPMC itself, we discuss everything here,
> including past decisions.
> Almost everything that happens here is a community decision, and we try to
> move with near
> unanimous consent.  It is generally hard to figure out what roles people
> have without some formal
> VOTE where people indicate a binding status on it.
>
> That is what you should aspire to on your dev list- it really shouldn't
> matter what roles people have
> unless we need to be looking at a release.
>
>
>
> On Wed, Nov 4, 2015 at 11:37 PM, Joe Schaefer <joes...@gmail.com> wrote:
>
>> This may sound a bit pedantic, but the "Sentry project" isn't capable of
>> considering anything.
>> Either you are referring to a decision of the committers or the PPMC or
>> the community, all
>> of which requires some discussion over time about any position being
>> taken.  I would consider
>> it unusual for the project participants to be unanimous on a situation
>> like this or other related
>> matters, and certainly opinions evolve over time.
>>
>> Nobody should put themselves in a position of speaking on behalf of the
>> project.  That is why
>> we have communication channels in the first place and generally refer to
>> on list decisions.
>> The individual positions of the participants should be reflected in any
>> consensus-based decision
>> making.  Not to say everything must be voted on, but collective decision
>> making requires
>> open communication, preferably on public channels.
>>
>>
>>
>> On Wed, Nov 4, 2015 at 8:26 PM, Lenni Kuff <lsk...@cloudera.com> wrote:
>>
>>> I think there is some confusion here. The Sentry project has never
>>> considered Committer == PMC. The recent website change was only to help
>>> clarify the roles of each of the members of the project, it was not the
>>> result of any decision being made.
>>>
>>> Thanks,
>>> Lenni
>>>
>>> On Wed, Nov 4, 2015 at 3:03 PM, P. Taylor Goetz <ptgo...@gmail.com>
>>> wrote:
>>>
>>> >
>>> >
>>> > On Nov 4, 2015, at 2:05 PM, Lenni Kuff <lsk...@cloudera.com> wrote:
>>> >
>>> > >> On Wed, Nov 4, 2015 at 10:05 AM, P. Taylor Goetz <ptgo...@gmail.com
>>> >
>>> > >> wrote:
>>> > >>
>>> > >>>
>>> > >>> On Nov 4, 2015, at 11:32 AM, Joe Brockmeier <j...@zonker.net>
>>> wrote:
>>> > >>>
>>> > >>> * I would invite folks with access to go to Sentry's private list
>>> and
>>> > >>> look over discussions about adding new contributors, and
>>> discussions
>>> > >>> about the project in general.
>>> > >>>
>>> > >>>
>>> > >>> I took a look.
>>> > >>>
>>> > >>> From a community growth perspective, I see them adding new
>>> committers,
>>> > >>> which is a good thing. What I don’t see is any discussion at all
>>> about
>>> > >>> adding PPMC members, nor any discussion about why they chose to go
>>> the
>>> > >>> Committer != PPMC route.
>>> > >>>
>>> > >>> In a thread related to the first new committer being added [1], it
>>> is
>>> > >>> pointed out that the podling website stated that Sentry was
>>> Committer
>>> > ==
>>> > >>> PMC, but that the new member vote was only for Committer. At that
>>> point
>>> > >> it
>>> > >>> looks like the website was updated to reflect Committer != PMC.
>>> From
>>> > that
>>> > >>> point on, all new member votes were for Committer only, and there
>>> were
>>> > no
>>> > >>> discussions regarding adding new PMC members or promoting
>>> committers to
>>> > >> the
>>> > >>> PMC role.
>>> > >>>
>>> > >>> What I find slightly disconcerting is tha

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Thanks Lenni.  If Joe will permit me to put some words in his mouth,
he seems to be focused on how the project is solving coordination problems.
Coming to agreement on things like what to include in a release for
instance,
which jiras get punted to which release schedules, etc, it's hard to see
the rhyme
or reason why these things are happening with the timing you are using.

I'm perfectly personally satisfied with the manner in which tickets are
being resolved,
but am inclined to trust Joe's instincts that more prior discussion about
planning and
such should be taking place on-list.  David has echoed these concerns as
well.



On Thu, Nov 5, 2015 at 1:28 AM, Lenni Kuff <lsk...@cloudera.com> wrote:

> Thanks Joe. That was a powerful read and very inspiring. This should be
> posted on a wiki someplace.
>
> I agree. This seems like an important topic to revisit on our list to see
> how the community feels - and more generally, discuss more topics (big,
> small, new, old) more frequently moving forward.
>
> Thanks,
> Lenni
>
> On Wed, Nov 4, 2015 at 9:44 PM, Joe Schaefer <joes...@gmail.com> wrote:
>
> > Thanks Chris.  So what I'm saying is, instead of adopting the position
> > that "we" have made up our minds on this matter well before joining the
> > incubator, why not recognize that at this point your community now
> includes
> > new committers and new community members following along for which their
> > voices have not been heard from on this matter.  Once you recognize that
> > the
> > community has changed a bit, it makes sense to revisit a chestnut like
> this
> > on-
> > list.
> >
> >
> >
> > On Thu, Nov 5, 2015 at 12:26 AM, Mattmann, Chris A (3980) <
> > chris.a.mattm...@jpl.nasa.gov> wrote:
> >
> > > +1 to the below.
> > >
> > > ++
> > > Chris Mattmann, Ph.D.
> > > Chief Architect
> > > Instrument Software and Science Data Systems Section (398)
> > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > > Office: 168-519, Mailstop: 168-527
> > > Email: chris.a.mattm...@nasa.gov
> > > WWW:  http://sunset.usc.edu/~mattmann/
> > > ++
> > > Adjunct Associate Professor, Computer Science Department
> > > University of Southern California, Los Angeles, CA 90089 USA
> > > ++
> > >
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Joe Schaefer <joes...@gmail.com>
> > > Reply-To: "general@incubator.apache.org" <general@incubator.apache.org
> >
> > > Date: Wednesday, November 4, 2015 at 8:49 PM
> > > To: "general@incubator.apache.org" <general@incubator.apache.org>
> > > Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> > > graduation
> > >
> > > >Just to contrast this with the IPMC itself, we discuss everything
> here,
> > > >including past decisions.
> > > >Almost everything that happens here is a community decision, and we
> try
> > to
> > > >move with near
> > > >unanimous consent.  It is generally hard to figure out what roles
> people
> > > >have without some formal
> > > >VOTE where people indicate a binding status on it.
> > > >
> > > >That is what you should aspire to on your dev list- it really
> shouldn't
> > > >matter what roles people have
> > > >unless we need to be looking at a release.
> > > >
> > > >
> > > >
> > > >On Wed, Nov 4, 2015 at 11:37 PM, Joe Schaefer <joes...@gmail.com>
> > wrote:
> > > >
> > > >> This may sound a bit pedantic, but the "Sentry project" isn't
> capable
> > of
> > > >> considering anything.
> > > >> Either you are referring to a decision of the committers or the PPMC
> > or
> > > >> the community, all
> > > >> of which requires some discussion over time about any position being
> > > >> taken.  I would consider
> > > >> it unusual for the project participants to be unanimous on a
> situation
> > > >> like this or other related
> > > >> matters, and certainly opinions evolve over time.
> > > >>
> > > >> Nobody should put themselves in a position of speaking on behalf of

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

This may sound a bit pedantic, but the "Sentry project" isn't capable of
considering anything.
Either you are referring to a decision of the committers or the PPMC or the
community, all
of which requires some discussion over time about any position being
taken.  I would consider
it unusual for the project participants to be unanimous on a situation like
this or other related
matters, and certainly opinions evolve over time.

Nobody should put themselves in a position of speaking on behalf of the
project.  That is why
we have communication channels in the first place and generally refer to on
list decisions.
The individual positions of the participants should be reflected in any
consensus-based decision
making.  Not to say everything must be voted on, but collective decision
making requires
open communication, preferably on public channels.



On Wed, Nov 4, 2015 at 8:26 PM, Lenni Kuff  wrote:

> I think there is some confusion here. The Sentry project has never
> considered Committer == PMC. The recent website change was only to help
> clarify the roles of each of the members of the project, it was not the
> result of any decision being made.
>
> Thanks,
> Lenni
>
> On Wed, Nov 4, 2015 at 3:03 PM, P. Taylor Goetz  wrote:
>
> >
> >
> > On Nov 4, 2015, at 2:05 PM, Lenni Kuff  wrote:
> >
> > >> On Wed, Nov 4, 2015 at 10:05 AM, P. Taylor Goetz 
> > >> wrote:
> > >>
> > >>>
> > >>> On Nov 4, 2015, at 11:32 AM, Joe Brockmeier  wrote:
> > >>>
> > >>> * I would invite folks with access to go to Sentry's private list and
> > >>> look over discussions about adding new contributors, and discussions
> > >>> about the project in general.
> > >>>
> > >>>
> > >>> I took a look.
> > >>>
> > >>> From a community growth perspective, I see them adding new
> committers,
> > >>> which is a good thing. What I don’t see is any discussion at all
> about
> > >>> adding PPMC members, nor any discussion about why they chose to go
> the
> > >>> Committer != PPMC route.
> > >>>
> > >>> In a thread related to the first new committer being added [1], it is
> > >>> pointed out that the podling website stated that Sentry was Committer
> > ==
> > >>> PMC, but that the new member vote was only for Committer. At that
> point
> > >> it
> > >>> looks like the website was updated to reflect Committer != PMC. From
> > that
> > >>> point on, all new member votes were for Committer only, and there
> were
> > no
> > >>> discussions regarding adding new PMC members or promoting committers
> to
> > >> the
> > >>> PMC role.
> > >>>
> > >>> What I find slightly disconcerting is that there doesn’t seem to be
> any
> > >>> consideration or discussion around growing the PPMC and why that’s
> > >>> important. Sure they have 20-odd PPMC members from the initial
> > committers
> > >>> list, so it would take a pretty large exodus to render the project
> > unable
> > >>> to function, but I don’t see anything to indicate that they
> understand
> > >> the
> > >>> function and importance of growing the PPMC.
> > >
> > > Background: I am a Sentry community member.
> > >
> > > I would have to disagree with this. We have identified lack of new PPMC
> > > members as an issue and called out in our board reports. We are also
> > > encouraging non-PPMC members to get involved in ways they can become
> PPMC
> > > members - for example, we have had non-PPMC members run two of the last
> > > Sentry releases. As mentioned earlier, it's not like there is no
> progress
> > > here, we have people who are very close (and I agree that we can do a
> > > better job discussing this on or private@ list). We are  also
> > encouraging
> > > others in the community to step up, giving them opportunities, and
> really
> > > striving to build a community around the project.
> >
> > Fair enough.
> >
> > Can you point me to the discussion where the project decided to go with
> > Committer != PMC over Committer == PMC?
> >
> > From an outsider's perspective, that decision just looks like a single
> > commit, without any public discussion, which speaks to the concerns
> others
> > have raised about decisions being made in private.
> >
> > -Taylor
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Also, I'm not quite clear on what is meant by "running" a release.
Do you mean a committer not on the PMC functioned as Release Manager?
Normally someone who does that is sending a clear-cut signal that they
belong on the PMC, because all that work they are doing is being done on
behalf of
the PMC.  I consider it a highly awkward situation when a Release Manager
does
not have a binding vote on their own damned release (well for a normal PMC).


On Thu, Nov 5, 2015 at 12:44 AM, Joe Schaefer <joes...@gmail.com> wrote:

> Thanks Chris.  So what I'm saying is, instead of adopting the position
> that "we" have made up our minds on this matter well before joining the
> incubator, why not recognize that at this point your community now includes
> new committers and new community members following along for which their
> voices have not been heard from on this matter.  Once you recognize that
> the
> community has changed a bit, it makes sense to revisit a chestnut like
> this on-
> list.
>
>
>
> On Thu, Nov 5, 2015 at 12:26 AM, Mattmann, Chris A (3980) <
> chris.a.mattm...@jpl.nasa.gov> wrote:
>
>> +1 to the below.
>>
>> ++
>> Chris Mattmann, Ph.D.
>> Chief Architect
>> Instrument Software and Science Data Systems Section (398)
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 168-519, Mailstop: 168-527
>> Email: chris.a.mattm...@nasa.gov
>> WWW:  http://sunset.usc.edu/~mattmann/
>> ++
>> Adjunct Associate Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++
>>
>>
>>
>>
>>
>> -Original Message-
>> From: Joe Schaefer <joes...@gmail.com>
>> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org>
>> Date: Wednesday, November 4, 2015 at 8:49 PM
>> To: "general@incubator.apache.org" <general@incubator.apache.org>
>> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
>> graduation
>>
>> >Just to contrast this with the IPMC itself, we discuss everything here,
>> >including past decisions.
>> >Almost everything that happens here is a community decision, and we try
>> to
>> >move with near
>> >unanimous consent.  It is generally hard to figure out what roles people
>> >have without some formal
>> >VOTE where people indicate a binding status on it.
>> >
>> >That is what you should aspire to on your dev list- it really shouldn't
>> >matter what roles people have
>> >unless we need to be looking at a release.
>> >
>> >
>> >
>> >On Wed, Nov 4, 2015 at 11:37 PM, Joe Schaefer <joes...@gmail.com> wrote:
>> >
>> >> This may sound a bit pedantic, but the "Sentry project" isn't capable
>> of
>> >> considering anything.
>> >> Either you are referring to a decision of the committers or the PPMC or
>> >> the community, all
>> >> of which requires some discussion over time about any position being
>> >> taken.  I would consider
>> >> it unusual for the project participants to be unanimous on a situation
>> >> like this or other related
>> >> matters, and certainly opinions evolve over time.
>> >>
>> >> Nobody should put themselves in a position of speaking on behalf of the
>> >> project.  That is why
>> >> we have communication channels in the first place and generally refer
>> to
>> >> on list decisions.
>> >> The individual positions of the participants should be reflected in any
>> >> consensus-based decision
>> >> making.  Not to say everything must be voted on, but collective
>> decision
>> >> making requires
>> >> open communication, preferably on public channels.
>> >>
>> >>
>> >>
>> >> On Wed, Nov 4, 2015 at 8:26 PM, Lenni Kuff <lsk...@cloudera.com>
>> wrote:
>> >>
>> >>> I think there is some confusion here. The Sentry project has never
>> >>> considered Committer == PMC. The recent website change was only to
>> help
>> >>> clarify the roles of each of the members of the project, it was not
>> the
>> >>> result of any decision being made.
>> >>>
>> >>> Thanks,
>> >

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

PMC membership has nothing to do with technical mastery of the codebase,
which
is why I cringe every time I see people talking about what "the bar" should
be.
It's about trust.  If you trust someone to work the gears on a release,
that has
considerable impact on the well-being of a project, and personally meets my
definition of "belongs on the PMC".



On Thu, Nov 5, 2015 at 1:34 AM, Joe Schaefer <joes...@gmail.com> wrote:

> Thanks Lenni.  If Joe will permit me to put some words in his mouth,
> he seems to be focused on how the project is solving coordination problems.
> Coming to agreement on things like what to include in a release for
> instance,
> which jiras get punted to which release schedules, etc, it's hard to see
> the rhyme
> or reason why these things are happening with the timing you are using.
>
> I'm perfectly personally satisfied with the manner in which tickets are
> being resolved,
> but am inclined to trust Joe's instincts that more prior discussion about
> planning and
> such should be taking place on-list.  David has echoed these concerns as
> well.
>
>
>
> On Thu, Nov 5, 2015 at 1:28 AM, Lenni Kuff <lsk...@cloudera.com> wrote:
>
>> Thanks Joe. That was a powerful read and very inspiring. This should be
>> posted on a wiki someplace.
>>
>> I agree. This seems like an important topic to revisit on our list to see
>> how the community feels - and more generally, discuss more topics (big,
>> small, new, old) more frequently moving forward.
>>
>> Thanks,
>> Lenni
>>
>> On Wed, Nov 4, 2015 at 9:44 PM, Joe Schaefer <joes...@gmail.com> wrote:
>>
>> > Thanks Chris.  So what I'm saying is, instead of adopting the position
>> > that "we" have made up our minds on this matter well before joining the
>> > incubator, why not recognize that at this point your community now
>> includes
>> > new committers and new community members following along for which their
>> > voices have not been heard from on this matter.  Once you recognize that
>> > the
>> > community has changed a bit, it makes sense to revisit a chestnut like
>> this
>> > on-
>> > list.
>> >
>> >
>> >
>> > On Thu, Nov 5, 2015 at 12:26 AM, Mattmann, Chris A (3980) <
>> > chris.a.mattm...@jpl.nasa.gov> wrote:
>> >
>> > > +1 to the below.
>> > >
>> > > ++
>> > > Chris Mattmann, Ph.D.
>> > > Chief Architect
>> > > Instrument Software and Science Data Systems Section (398)
>> > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> > > Office: 168-519, Mailstop: 168-527
>> > > Email: chris.a.mattm...@nasa.gov
>> > > WWW:  http://sunset.usc.edu/~mattmann/
>> > > ++
>> > > Adjunct Associate Professor, Computer Science Department
>> > > University of Southern California, Los Angeles, CA 90089 USA
>> > > ++
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > -Original Message-
>> > > From: Joe Schaefer <joes...@gmail.com>
>> > > Reply-To: "general@incubator.apache.org" <
>> general@incubator.apache.org>
>> > > Date: Wednesday, November 4, 2015 at 8:49 PM
>> > > To: "general@incubator.apache.org" <general@incubator.apache.org>
>> > > Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
>> > > graduation
>> > >
>> > > >Just to contrast this with the IPMC itself, we discuss everything
>> here,
>> > > >including past decisions.
>> > > >Almost everything that happens here is a community decision, and we
>> try
>> > to
>> > > >move with near
>> > > >unanimous consent.  It is generally hard to figure out what roles
>> people
>> > > >have without some formal
>> > > >VOTE where people indicate a binding status on it.
>> > > >
>> > > >That is what you should aspire to on your dev list- it really
>> shouldn't
>> > > >matter what roles people have
>> > > >unless we need to be looking at a release.
>> > > >
>> > > >
>> > > >
>> > > >On Wed, Nov 4, 2015 at 11:37 PM, Joe Schaefer <joes...@gmail.com>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Joe, has any of this conversation put your mind at ease about the podling?
I certainly think you've done the right thing by raising your concerns here
and
asking for a sanity check.

On Wed, Nov 4, 2015 at 4:17 AM, Greg Stein  wrote:

> On Nov 4, 2015 2:47 AM, "Bertrand Delacretaz" 
> wrote:
> >
> > On Tue, Nov 3, 2015 at 10:42 PM, Patrick Hunt  wrote:
> > > ...what would the action item the community should take away from
> > > this? As their mentor I'm not sure what advice i can give them. "add
> more
> > > ppmc members"? Sounds like that's in the pipeline. Seems artificial to
> me
> >
> > If it's in the pipeline that's fine, what's important IMO is that the
> > podling demonstrates that it can grow/renew its (p)PMC, during
> > incubation.
>
> And note the Board also wants to see PMC growth over the years (for TLPs).
> This is why we mandate reporting requirements of "last date of PMC
> addition"
>
> Cheers,
> -g
>

Re: podlings and github

[Joe Schaefer]

As Ted points out, so long as the prior github presence is effectively
mothballed I don't see any problem with leaving it up for the foreseeable
future.

The main concern of mine and the membership involves podlings making
active use of a github repo not under Apache's direct control.  This doesn't
necessarily mean there's a problem, it just means we should have a look
to see if everything is happening according to policy.



On Mon, Nov 2, 2015 at 8:08 PM, Ted Dunning  wrote:

> On Mon, Nov 2, 2015 at 2:08 PM, Peter Ansell 
> wrote:
>
> > Does Apache use GitHub's "move" repository functionality that adds a
> > redirect if the name changes once? If not, is it viable for the
> > Commons RDF group to keep their original project (which contains
> > directions on how to get to the current repository) until they
> > graduate get a permanent location in the /apache/ namespace to
> > minimise the number of broken links around the internet to this
> > project?
> >
>
> As long as the old project is frozen and has a bold warning that it
> represents the past, I doubt that it is a problem that it exists at
> graduation.
>
>
> > This project, and others, may be concerned about both their likelihood
> > of graduating from the incubator (requiring them to go back to their
> > previous Github organisation), and the Apache policy on having two
> > renames for their project, which damages their brand if people find
> > broken links on the internet.
> >
>
> Whether or not they graduate is largely up to them.  Recent non-graduations
> have fallen into two categories:
>
> a) projects which just didn't continue
>
> b) projects which insisted on things like GPL mandatory dependencies
>
> Basically, neither kind of project *wanted* to be Apache projects. The
> first kind didn't want anything enough to continue (I simplify, of course)
> and the second kind didn't want to follow through on the Apache IP
> requirements.
>
> Pretty much any project that continues to be vital, produces clean Apache
> style releases, is willing to be careful about where their code comes from
> and be open, friendly and inclusive can become an Apache project.
>
> Maybe this project needs a long talk with somebody who has been around the
> circuit a few times.  On the other hand, any project that has the mentors
> that Commons RDF has should have ready access to Apache expertise.
>
> Looking at the email archives just now, it looks to me like commons RDF is
> finding it difficult to build a community and maintain any serious
> momentum.  Seeing only a few emails or commits for months on end raises red
> flags to me.  A project that peters out at Apache is likely to have petered
> out anyway, however, so I don't see much for the original folks to worry
> about.
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

The whole point of the ASF's archiving policy is to ensure these types of
concerns can
be examined objectively by others.  With jira we have the ability to drill
down in considerably
more detail than we do trawling the email archives, but in either case any
objective attempts
to discover inappropriate conduct will fail to yield much fruit.  The
committers do work fast
when it comes to repairing bugs they discover, but that doesn't mean they
are doing things
in the wrong order.  I have yet to see a large patch prematurely applied to
the repo: the bulk
of the patches are minor changes that certainly can be worked out hours
after discovering the
problem and filing the ticket.

On Tue, Nov 3, 2015 at 8:25 PM, Joe Schaefer <joes...@gmail.com> wrote:

> Look at what we don't see- signs of dysfunction.  Even with this thread,
> with serious consequences for the podling,
> nobody is behaving in a territorial or defensive way about the project.
> The feedback has been very reasonable,
> respectful of Joe's concerns, and direct.
>
> I have a strong suspicion that the core problem here is that the mentors
> aren't following the commit list, which is
> where the jira email trail gets sent.  Looking there you will see a
> plethora of examples where tickets, many filed by
> non-project participants, are being discussed by several project members,
> far from the presentation that discussions
> are happening off-Apache-infra and tickets are being "shut down" without
> public review.
>
>
> On Tue, Nov 3, 2015 at 8:17 PM, Joe Schaefer <joes...@gmail.com> wrote:
>
>> The only thing I might recommend of the podling is to try to leave
>> low-hanging fruit in jira unpatched for a longer period of time to allow
>> outside contributors the ability to participate.  Coupled with identifying
>> these tickets on the mailing list, that might lead to more outside
>> contributions.
>>
>> I do share the concern that we have several elected committers that
>> haven't yet advanced to the ppmc level.
>> Perhaps there's not enough project-level mentoring (as opposed to IMPC
>> mentoring) going on to bring these newer people along.
>>
>>
>> On Tue, Nov 3, 2015 at 7:59 PM, Joe Schaefer <joes...@gmail.com> wrote:
>>
>>> I still consider that hearsay evidence.  If you bother to actually look
>>> at their Jira you will see the vast majority of tickets opened in the past
>>> month remain open.  I've spent an hour or so myself investigating this in
>>> some detail and turned up nothing- I invite you and others to do the same.
>>>
>>>
>>> On Tuesday, November 3, 2015, Rich Bowen <rbo...@rcbowen.com> wrote:
>>>
>>>> On Nov 3, 2015 11:34 AM, "Joe Schaefer" <joes...@gmail.com> wrote:
>>>> >
>>>> > David,
>>>> >
>>>> > The problem with Rich's commentary is that we don't have any solid
>>>> evidence
>>>> > to that effect.  Certainly not on a systematic level.
>>>> > All I see is a lot of responsiveness from the team about
>>>> repair-oriented
>>>> > tickets, or some mundane task like updating dependencies.
>>>> > I don't find credible evidence to support the claim that development
>>>> is
>>>> > happening prior to filing a ticket about it.
>>>>
>>>> Sure. I'm not involved in the community, but have had the above scenario
>>>> described to me by two different people.
>>>>
>>>
>>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

I still consider that hearsay evidence.  If you bother to actually look at
their Jira you will see the vast majority of tickets opened in the past
month remain open.  I've spent an hour or so myself investigating this in
some detail and turned up nothing- I invite you and others to do the same.

On Tuesday, November 3, 2015, Rich Bowen <rbo...@rcbowen.com> wrote:

> On Nov 3, 2015 11:34 AM, "Joe Schaefer" <joes...@gmail.com <javascript:;>>
> wrote:
> >
> > David,
> >
> > The problem with Rich's commentary is that we don't have any solid
> evidence
> > to that effect.  Certainly not on a systematic level.
> > All I see is a lot of responsiveness from the team about repair-oriented
> > tickets, or some mundane task like updating dependencies.
> > I don't find credible evidence to support the claim that development is
> > happening prior to filing a ticket about it.
>
> Sure. I'm not involved in the community, but have had the above scenario
> described to me by two different people.
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Look at what we don't see- signs of dysfunction.  Even with this thread,
with serious consequences for the podling,
nobody is behaving in a territorial or defensive way about the project.
The feedback has been very reasonable,
respectful of Joe's concerns, and direct.

I have a strong suspicion that the core problem here is that the mentors
aren't following the commit list, which is
where the jira email trail gets sent.  Looking there you will see a
plethora of examples where tickets, many filed by
non-project participants, are being discussed by several project members,
far from the presentation that discussions
are happening off-Apache-infra and tickets are being "shut down" without
public review.


On Tue, Nov 3, 2015 at 8:17 PM, Joe Schaefer <joes...@gmail.com> wrote:

> The only thing I might recommend of the podling is to try to leave
> low-hanging fruit in jira unpatched for a longer period of time to allow
> outside contributors the ability to participate.  Coupled with identifying
> these tickets on the mailing list, that might lead to more outside
> contributions.
>
> I do share the concern that we have several elected committers that
> haven't yet advanced to the ppmc level.
> Perhaps there's not enough project-level mentoring (as opposed to IMPC
> mentoring) going on to bring these newer people along.
>
>
> On Tue, Nov 3, 2015 at 7:59 PM, Joe Schaefer <joes...@gmail.com> wrote:
>
>> I still consider that hearsay evidence.  If you bother to actually look
>> at their Jira you will see the vast majority of tickets opened in the past
>> month remain open.  I've spent an hour or so myself investigating this in
>> some detail and turned up nothing- I invite you and others to do the same.
>>
>>
>> On Tuesday, November 3, 2015, Rich Bowen <rbo...@rcbowen.com> wrote:
>>
>>> On Nov 3, 2015 11:34 AM, "Joe Schaefer" <joes...@gmail.com> wrote:
>>> >
>>> > David,
>>> >
>>> > The problem with Rich's commentary is that we don't have any solid
>>> evidence
>>> > to that effect.  Certainly not on a systematic level.
>>> > All I see is a lot of responsiveness from the team about
>>> repair-oriented
>>> > tickets, or some mundane task like updating dependencies.
>>> > I don't find credible evidence to support the claim that development is
>>> > happening prior to filing a ticket about it.
>>>
>>> Sure. I'm not involved in the community, but have had the above scenario
>>> described to me by two different people.
>>>
>>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

The point I'm making about project dysfunction is something I've learned to
expect from projects
that are using inappropriate means to control the project.  Any time you
challenge their means of
control, the response you get will indicate whether or not you are barking
up the wrong tree.
The absence of inappropriate feedback is in fact a sign that we are not
gauging things such
as they actually are, but are projecting our own perceptions onto the
project.


On Tue, Nov 3, 2015 at 8:49 PM, Joe Schaefer <joes...@gmail.com> wrote:

> The whole point of the ASF's archiving policy is to ensure these types of
> concerns can
> be examined objectively by others.  With jira we have the ability to drill
> down in considerably
> more detail than we do trawling the email archives, but in either case any
> objective attempts
> to discover inappropriate conduct will fail to yield much fruit.  The
> committers do work fast
> when it comes to repairing bugs they discover, but that doesn't mean they
> are doing things
> in the wrong order.  I have yet to see a large patch prematurely applied
> to the repo: the bulk
> of the patches are minor changes that certainly can be worked out hours
> after discovering the
> problem and filing the ticket.
>
> On Tue, Nov 3, 2015 at 8:25 PM, Joe Schaefer <joes...@gmail.com> wrote:
>
>> Look at what we don't see- signs of dysfunction.  Even with this thread,
>> with serious consequences for the podling,
>> nobody is behaving in a territorial or defensive way about the project.
>> The feedback has been very reasonable,
>> respectful of Joe's concerns, and direct.
>>
>> I have a strong suspicion that the core problem here is that the mentors
>> aren't following the commit list, which is
>> where the jira email trail gets sent.  Looking there you will see a
>> plethora of examples where tickets, many filed by
>> non-project participants, are being discussed by several project members,
>> far from the presentation that discussions
>> are happening off-Apache-infra and tickets are being "shut down" without
>> public review.
>>
>>
>> On Tue, Nov 3, 2015 at 8:17 PM, Joe Schaefer <joes...@gmail.com> wrote:
>>
>>> The only thing I might recommend of the podling is to try to leave
>>> low-hanging fruit in jira unpatched for a longer period of time to allow
>>> outside contributors the ability to participate.  Coupled with identifying
>>> these tickets on the mailing list, that might lead to more outside
>>> contributions.
>>>
>>> I do share the concern that we have several elected committers that
>>> haven't yet advanced to the ppmc level.
>>> Perhaps there's not enough project-level mentoring (as opposed to IMPC
>>> mentoring) going on to bring these newer people along.
>>>
>>>
>>> On Tue, Nov 3, 2015 at 7:59 PM, Joe Schaefer <joes...@gmail.com> wrote:
>>>
>>>> I still consider that hearsay evidence.  If you bother to actually look
>>>> at their Jira you will see the vast majority of tickets opened in the past
>>>> month remain open.  I've spent an hour or so myself investigating this in
>>>> some detail and turned up nothing- I invite you and others to do the same.
>>>>
>>>>
>>>> On Tuesday, November 3, 2015, Rich Bowen <rbo...@rcbowen.com> wrote:
>>>>
>>>>> On Nov 3, 2015 11:34 AM, "Joe Schaefer" <joes...@gmail.com> wrote:
>>>>> >
>>>>> > David,
>>>>> >
>>>>> > The problem with Rich's commentary is that we don't have any solid
>>>>> evidence
>>>>> > to that effect.  Certainly not on a systematic level.
>>>>> > All I see is a lot of responsiveness from the team about
>>>>> repair-oriented
>>>>> > tickets, or some mundane task like updating dependencies.
>>>>> > I don't find credible evidence to support the claim that development
>>>>> is
>>>>> > happening prior to filing a ticket about it.
>>>>>
>>>>> Sure. I'm not involved in the community, but have had the above
>>>>> scenario
>>>>> described to me by two different people.
>>>>>
>>>>
>>>
>>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

The only thing I might recommend of the podling is to try to leave
low-hanging fruit in jira unpatched for a longer period of time to allow
outside contributors the ability to participate.  Coupled with identifying
these tickets on the mailing list, that might lead to more outside
contributions.

I do share the concern that we have several elected committers that haven't
yet advanced to the ppmc level.
Perhaps there's not enough project-level mentoring (as opposed to IMPC
mentoring) going on to bring these newer people along.


On Tue, Nov 3, 2015 at 7:59 PM, Joe Schaefer <joes...@gmail.com> wrote:

> I still consider that hearsay evidence.  If you bother to actually look at
> their Jira you will see the vast majority of tickets opened in the past
> month remain open.  I've spent an hour or so myself investigating this in
> some detail and turned up nothing- I invite you and others to do the same.
>
>
> On Tuesday, November 3, 2015, Rich Bowen <rbo...@rcbowen.com> wrote:
>
>> On Nov 3, 2015 11:34 AM, "Joe Schaefer" <joes...@gmail.com> wrote:
>> >
>> > David,
>> >
>> > The problem with Rich's commentary is that we don't have any solid
>> evidence
>> > to that effect.  Certainly not on a systematic level.
>> > All I see is a lot of responsiveness from the team about repair-oriented
>> > tickets, or some mundane task like updating dependencies.
>> > I don't find credible evidence to support the claim that development is
>> > happening prior to filing a ticket about it.
>>
>> Sure. I'm not involved in the community, but have had the above scenario
>> described to me by two different people.
>>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

David,

The problem with Rich's commentary is that we don't have any solid evidence
to that effect.  Certainly not on a systematic level.
All I see is a lot of responsiveness from the team about repair-oriented
tickets, or some mundane task like updating dependencies.
I don't find credible evidence to support the claim that development is
happening prior to filing a ticket about it.


On Mon, Nov 2, 2015 at 1:06 PM, David Jencks 
wrote:

>
> > On Nov 2, 2015, at 11:29 AM, Rich Bowen  wrote:
> >
> >
> >
> > On 11/02/2015 09:50 AM, David Jencks wrote:
> >> I haven’t looked at what they are doing and don’t expect I will.
> However, I’m assuming that jira changes all get to the dev list, as in all
> other projects I’ve worked on.  I don’t see the point in duplicating a
> proposal between a jira issue and a separate dev list post with the same
> information.  And I don’t have a problem with people working quickly.  I
> would like to see that the jira issue explains sufficiently what is
> proposed or implemented in enough detail that an interested party can see
> how it fits in with the code and the purpose of the project.  So I’d be
> concerned if the jira descriptions were “fix bug” or “implement javaee7”
> but possibly not if there are reasonable explanations of what is being
> proposed or done.
> >
> > What has been described to me is that a ticket is filed proposing a
> major new feature, and then seconds later a *large* patch lands
> implementing that feature, and the ticket is closed, and discussion is shut
> down, because it's a done deal.
> >
>
> Well, for me closing an issue by no means discussion is shut down…. I’m
> happy to complain years later.  However irrespective of the level of detail
> in a jira, I’d expect it to be filed when the idea behind it is hatched,
> not when development on it is complete.  The behavior you describe seems
> completely inappropriate to me, and I’m fairly shocked a mentor would
> support it.
>
> thanks for the clarification.
>
> david jencks
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

podlings and github

[Joe Schaefer]

One of the concerns members are talking about with podlings on github
concerns their overall presence there.  To be brief, we need to take a
closer look at any podlings that are using their own project on github
versus using their clone on the apache github project.

So that opens the question I now put to the mentors: do we have any
podlings that are hosting on github using anything other than their
github.com/apache presence?

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Joe, can we see some jira tickets that you find questionable?  Hard to tell
what the problem is just by scanning the email traffic.

On Mon, Nov 2, 2015 at 1:06 PM, Vinod Vavilapalli 
wrote:

> Missed that part, that sounds really bad.
>
> +Vinod
>
> On Nov 2, 2015, at 9:52 AM, Joe Brockmeier > wrote:
>
> Discussions are happening out of sight, and - in
> Arvind's own words - "as if following a roadmap the community does not
> have control over... that too is not an issue in my opinion at all."
>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

Thanks Patrick.  I did some poking around in jira and certainly wasn't
able to discern any pattern of misconduct.  We do need to distinguish
repair work
from architecture/design decisions, and what I see is a lot of the former
and relatively little of the latter.

On Mon, Nov 2, 2015 at 2:32 PM, Patrick Hunt <ph...@apache.org> wrote:

> I haven't seen the "quick closing" aside from things like some test
> cleanups, even then the average was 5 days. I ran the jira report for
> resolution time and it certainly doesn't seem like jiras are being closed
> "instantly". Most of these are closed after many (typ. double digit, some
> tripple) days.
>
>
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12314720=daily=30=12314720=com.atlassian.jira.plugin.system.reports%3Aresolutiontime-report=Next
>
> All of the jira events are forwarded to the Sentry mailing list, so from
> the perspective of following along and getting an opportunity to respond I
> haven't seen an issue. As Vinod mentioned many projects (e.g. hadoop)
> operate in this manner. Jira is used to focus discussion and ensure there
> is a record and an action item. ML discussion isn't discouraged, but it can
> be hard to follow multiple threads of discussion/resolution.
>
> Patrick
>
>
> On Mon, Nov 2, 2015 at 10:09 AM, Joe Schaefer <joes...@gmail.com> wrote:
>
> > Joe, can we see some jira tickets that you find questionable?  Hard to
> tell
> > what the problem is just by scanning the email traffic.
> >
> > On Mon, Nov 2, 2015 at 1:06 PM, Vinod Vavilapalli <
> vino...@hortonworks.com
> > >
> > wrote:
> >
> > > Missed that part, that sounds really bad.
> > >
> > > +Vinod
> > >
> > > On Nov 2, 2015, at 9:52 AM, Joe Brockmeier <j...@zonker.net > > j...@zonker.net>> wrote:
> > >
> > > Discussions are happening out of sight, and - in
> > > Arvind's own words - "as if following a roadmap the community does not
> > > have control over... that too is not an issue in my opinion at all."
> > >
> > >
> >
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

What we do here is practice open *development*.  That means if it is a
foregone conclusion that some jira ticket gets opened with a patch already
cooked up for it, you're not doing it right.  The entire development
process needs to be subject to public scrutiny, not just the end result.


On Mon, Nov 2, 2015 at 11:29 AM, Rich Bowen  wrote:

>
>
> On 11/02/2015 09:50 AM, David Jencks wrote:
>
>> I haven’t looked at what they are doing and don’t expect I will.
>> However, I’m assuming that jira changes all get to the dev list, as in all
>> other projects I’ve worked on.  I don’t see the point in duplicating a
>> proposal between a jira issue and a separate dev list post with the same
>> information.  And I don’t have a problem with people working quickly.  I
>> would like to see that the jira issue explains sufficiently what is
>> proposed or implemented in enough detail that an interested party can see
>> how it fits in with the code and the purpose of the project.  So I’d be
>> concerned if the jira descriptions were “fix bug” or “implement javaee7”
>> but possibly not if there are reasonable explanations of what is being
>> proposed or done.
>>
>
> What has been described to me is that a ticket is filed proposing a major
> new feature, and then seconds later a *large* patch lands implementing that
> feature, and the ticket is closed, and discussion is shut down, because
> it's a done deal.
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Schaefer]

All of our projects are primarily in the recruitment business, so it does
concern
me that a project that's been here for over a year and hasn't managed to
attract
any new talent yet has some issues that need addressing.

But that said I think you might be being a little hard on these guys Joe
for failing in
that regard.  If your advice is being ignored that's a problem, but if it's
not and still
no good outcomes yet, them's the breaks.  I wouldn't consider that a
blocker for
graduation if so.


On Mon, Nov 2, 2015 at 6:15 PM, Upayavira <u...@odoko.co.uk> wrote:

>
>
> On Mon, Nov 2, 2015, at 08:28 PM, Joe Brockmeier wrote:
> > On 11/02/2015 01:09 PM, Joe Schaefer wrote:
> > > Joe, can we see some jira tickets that you find questionable?  Hard to
> tell
> > > what the problem is just by scanning the email traffic.
> >
> > I'll (again) point to the previous conversation that came out of David's
> > discussion with Sentry folks at ApacheCon [1] and then the reply from
> > Arvind which basically says he doesn't consider it an issue if the
> > project is "following a roadmap the community does not have control
> > over... that too is not an issue in my opinion at all." [2]
>
> Joe, I'd encourage you to re-read what he says there under [2]. When he
> says "following a roadmap the community doesn't control over" he seems
> to be paraphrasing what has previously been stated, and when he says
> "this is not an issue" it seems to me he is saying "this is not
> happening" rather than "this doesn't bother me". It seems to me you are
> misrepresenting him based upon this one email.
>
> > It's not specific tickets - it's (again) that there appears to be a lot
> > of discussion and planning taking place off-list, out of sight. Take the
> > 1.6.0 release discussion - no roadmap discussed for 1.6.0 at all, it
> > just appeared [3] and then within 15 minutes there's an "I agree, and
> > I'll be release manager!" [4] message and then several +1 / "I agree"
> > messages, and then .. done. This looks a lot to me like planning and
> > decisions happening off-list and then a cursory "discussion" for
> > appearance's sake.
> >
> > How is a person who's not tapped into the Sentry development process
> > already supposed to get involved? How is this building community? I see
> > the Sentry podling creating code... just not much evidence of a
> > community outside what Sentry came in with.
>
> I have no comment/perspective on the rest of this.
>
> Upayavira
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Joe Schaefer]

Just looked over Bertrand's document and I must say while I had high
expectations Bertrand has managed to surpass them.  That this is a
functional and itemized list of details is just perfect- even better that
there are citations and references along with it!

Excellent job Bertrand!

On Sat, Oct 17, 2015 at 1:14 AM, Greg Stein  wrote:

> I concur, and similarly pushed back just a few days ago on another
> suggestion of such "policy".
>
> Not really sure that an ASF-wide metric is appropriate (ie. all communities
> are different, and freedom to set their own path is important), but there
> is definitely value in some in the model. It can with provide
> insight/review, and critical thinking about a community.
>
> Cheers,
> -g
>
> On Thu, Oct 15, 2015 at 7:21 AM, Jim Jagielski  wrote:
>
> > If we are to use the maturity model as the guideline regarding podling
> > graduation, then certainly the model should be voted on and approved
> > by the membership as *the* model for the ASF, right?
> >
> > Basically, it looks to me that the model is proposing and creating
> policy,
> > and this is something that needs to be done 'correctly', if you get my
> > meaning.
> >
> > > On Oct 15, 2015, at 5:46 AM, Bertrand Delacretaz <
> bdelacre...@apache.org>
> > wrote:
> > >
> > > Hi Incubator PMC,
> > >
> > > FYI I have started an experiment at
> > > https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> > > using our maturity model to evaluate Groovy before its mentors suggest
> > > its graduation (which should happen very soon).
> > >
> > > So far this has helped uncover a few issues that we (at least I)
> > > hadn't noticed otherwise. Nothing major, but interesting, and I think
> > > it can be useful for the IPMC and Board once they have to decide to
> > > graduate the podling.
> > >
> > > -Bertrand
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: structural reform- division of labor

[Joe Schaefer]

The incubator is a very large committee with a lot of moving parts.  To
pick an example off the top of my head, let's look at the mentoring
situation.  What we generally do with new mentors is say hey so and so I
trust you will do a good job of watching over this podling for us.  What we
don't have right now are any general agreements of what "doing a good job"
entails.  Sure there are probably some docs about the subject, but
different people will interpret the relative merits of every bullet point
in different ways. The things we ask them to do, like sign off on reports
etc, are just ways of taking their pulse.  What we need is some place where
they can talk to other mentors about what they're supposed to be doing,
what is actually important versus what isn't, etc etc.  If issues pop up
they can shoot off an informal email to the mentoring working group before
having things escalated to incubator-private the way they do now.  You
might say they could contact other, more senior mentors on the project but
then again it's a crap shoot about the type of response you receive.

There are other examples, like on boarding and off boarding, where more
focused collaboration would serve the org well.  Docs are great, but they
don't replace the personal touch.


On Thu, Oct 15, 2015 at 3:48 AM, Joe Schaefer <
joe_schae...@yahoo.com.invalid> wrote:

> That's certainly a reasonable approach, but it doesn't quite capture what
> I'm talking about when I mention the concept of having individual working
> groups to do more focused collaboration on specific areas of work
> activity.  Where these conversations take place isn't really all that
> important, what is important is that we have them.
>
>
>
>  On Thursday, October 15, 2015 3:38 AM, Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
>
>
>  On Thu, Oct 15, 2015 at 5:05 AM, Joe Schaefer
> <joe_schae...@yahoo.com.invalid> wrote:
> > ...Formally, that's all a working group needs to be- yet another mailing
> list
>
> I'm not in favor of more mailing lists, I think [tags] in subject
> lines can pretty much do the same thing without splitting the
> community (as per Stefano Mazzocchi's busy lists pattern [1]).
>
> So maybe just define a set of such tags like [graduation], [proposal]
> [release] etc. but stay here.
>
> -Bertrand
>
> [1]
> http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
>
>
>
>

Re: structural reform- division of labor

[Joe Schaefer]

That's certainly a reasonable approach, but it doesn't quite capture what I'm 
talking about when I mention the concept of having individual working groups to 
do more focused collaboration on specific areas of work activity.  Where these 
conversations take place isn't really all that important, what is important is 
that we have them.
 


 On Thursday, October 15, 2015 3:38 AM, Bertrand Delacretaz 
<bdelacre...@apache.org> wrote:
   

 On Thu, Oct 15, 2015 at 5:05 AM, Joe Schaefer
<joe_schae...@yahoo.com.invalid> wrote:
> ...Formally, that's all a working group needs to be- yet another mailing 
> list

I'm not in favor of more mailing lists, I think [tags] in subject
lines can pretty much do the same thing without splitting the
community (as per Stefano Mazzocchi's busy lists pattern [1]).

So maybe just define a set of such tags like [graduation], [proposal]
[release] etc. but stay here.

-Bertrand

[1] http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/


  

Re: structural reform- division of labor

[Joe Schaefer]

I apologize for the formatting, Y!'s html-only text munging is to blame.

 


 On Wednesday, October 14, 2015 11:26 PM, Joe Schaefer 
<joe_schae...@yahoo.com.INVALID> wrote:
   

 To be specific, what I have in mind is something like
proposals@incubatordocs@incubatormentoring@incubatorgraduation@incubatorreleases@incubator
We probably don't need to start off with more subdivisions than that.
 


    On Wednesday, October 14, 2015 11:06 PM, Joe Schaefer 
<joe_schae...@yahoo.com.INVALID> wrote:
  

 This list is a pretty high volume list that really is intended for topics 
suitable for a general audience of incubator participants.  Nevertheless it 
carries a lot of traffic better suited for more topic-specific specialization.  
Not everyone here is capable of participating in release voting, acceptance 
voting, graduation voting, mentoring, documentation, or any of the other of 
these specialized areas.  So it does make some sense to shut some of this 
traffic elsewhere.
Formally, that's all a working group needs to be- yet another mailing list.  
Informally it could stimulate conversations between people working on similar 
subjects that don't want to burden this list with that sort of conversation.



 


    On Wednesday, October 14, 2015 10:17 PM, Joe Schaefer 
<joe_schae...@yahoo.com.INVALID> wrote:
  

 Elsewhere in the org several ideas have been floated around regardinggeneral 
reorganization and reform.  Things like possibly creating a newcommittee to 
oversee inbound and outbound podlings, or perhaps having the IPMC form such a 
subcommittee.
I mention these notions not because I support them, but because othershere 
might want to pick up that ball and push some of that to conclusion.
However, one related suggestion I do support: creating subdivisions withinthe 
incubator by labor.  I would prefer to call those working groups butthat's not 
a big deal.
It would be beneficial in several ways: teams of ingress IPMC memberscould have 
a focused discussion on their own list about how to makeimprovements in that 
labor area.  Similarly for documentation, outbound transitioning, mentoring, 
tho as Martijn points out that might need additional subdividing by focus areas 
or timeline specialization.
Ted can fully flesh the details out as this was something he mentioned to me as 
one possible avenue of improvement.





  

Re: structural reform- division of labor

[Joe Schaefer]

This list is a pretty high volume list that really is intended for topics 
suitable for a general audience of incubator participants.  Nevertheless it 
carries a lot of traffic better suited for more topic-specific specialization.  
Not everyone here is capable of participating in release voting, acceptance 
voting, graduation voting, mentoring, documentation, or any of the other of 
these specialized areas.  So it does make some sense to shut some of this 
traffic elsewhere.
Formally, that's all a working group needs to be- yet another mailing list.  
Informally it could stimulate conversations between people working on similar 
subjects that don't want to burden this list with that sort of conversation.



 


 On Wednesday, October 14, 2015 10:17 PM, Joe Schaefer 
<joe_schae...@yahoo.com.INVALID> wrote:
   

 Elsewhere in the org several ideas have been floated around regardinggeneral 
reorganization and reform.  Things like possibly creating a newcommittee to 
oversee inbound and outbound podlings, or perhaps having the IPMC form such a 
subcommittee.
I mention these notions not because I support them, but because othershere 
might want to pick up that ball and push some of that to conclusion.
However, one related suggestion I do support: creating subdivisions withinthe 
incubator by labor.  I would prefer to call those working groups butthat's not 
a big deal.
It would be beneficial in several ways: teams of ingress IPMC memberscould have 
a focused discussion on their own list about how to makeimprovements in that 
labor area.  Similarly for documentation, outbound transitioning, mentoring, 
tho as Martijn points out that might need additional subdividing by focus areas 
or timeline specialization.
Ted can fully flesh the details out as this was something he mentioned to me as 
one possible avenue of improvement.

  

structural reform- division of labor

[Joe Schaefer]

Elsewhere in the org several ideas have been floated around regardinggeneral 
reorganization and reform.  Things like possibly creating a newcommittee to 
oversee inbound and outbound podlings, or perhaps having the IPMC form such a 
subcommittee.
I mention these notions not because I support them, but because othershere 
might want to pick up that ball and push some of that to conclusion.
However, one related suggestion I do support: creating subdivisions withinthe 
incubator by labor.  I would prefer to call those working groups butthat's not 
a big deal.
It would be beneficial in several ways: teams of ingress IPMC memberscould have 
a focused discussion on their own list about how to makeimprovements in that 
labor area.  Similarly for documentation, outbound transitioning, mentoring, 
tho as Martijn points out that might need additional subdividing by focus areas 
or timeline specialization.
Ted can fully flesh the details out as this was something he mentioned to me as 
one possible avenue of improvement.

Re: structural reform- division of labor

[Joe Schaefer]

To be specific, what I have in mind is something like
proposals@incubatordocs@incubatormentoring@incubatorgraduation@incubatorreleases@incubator
We probably don't need to start off with more subdivisions than that.
 


 On Wednesday, October 14, 2015 11:06 PM, Joe Schaefer 
<joe_schae...@yahoo.com.INVALID> wrote:
   

 This list is a pretty high volume list that really is intended for topics 
suitable for a general audience of incubator participants.  Nevertheless it 
carries a lot of traffic better suited for more topic-specific specialization.  
Not everyone here is capable of participating in release voting, acceptance 
voting, graduation voting, mentoring, documentation, or any of the other of 
these specialized areas.  So it does make some sense to shut some of this 
traffic elsewhere.
Formally, that's all a working group needs to be- yet another mailing list.  
Informally it could stimulate conversations between people working on similar 
subjects that don't want to burden this list with that sort of conversation.



 


    On Wednesday, October 14, 2015 10:17 PM, Joe Schaefer 
<joe_schae...@yahoo.com.INVALID> wrote:
  

 Elsewhere in the org several ideas have been floated around regardinggeneral 
reorganization and reform.  Things like possibly creating a newcommittee to 
oversee inbound and outbound podlings, or perhaps having the IPMC form such a 
subcommittee.
I mention these notions not because I support them, but because othershere 
might want to pick up that ball and push some of that to conclusion.
However, one related suggestion I do support: creating subdivisions withinthe 
incubator by labor.  I would prefer to call those working groups butthat's not 
a big deal.
It would be beneficial in several ways: teams of ingress IPMC memberscould have 
a focused discussion on their own list about how to makeimprovements in that 
labor area.  Similarly for documentation, outbound transitioning, mentoring, 
tho as Martijn points out that might need additional subdividing by focus areas 
or timeline specialization.
Ted can fully flesh the details out as this was something he mentioned to me as 
one possible avenue of improvement.



  

seekable stdout test

[Joe Schaefer]

ignore

testing auto moderation of committer emails

[Joe Schaefer]

ignore please

ezmlm-gate -q test

[Joe Schaefer]

ignore this

testing dmarc yahoo neutralization

[Joe Schaefer]

ignore this message, it's for testing

test 2 y! munging

[Joe Schaefer]

ignore this internal test

Y! invalidator

[Joe Schaefer]

testing dmarc 

Re: Graduation resolution does not allow for committers != PMC

[Joe Schaefer]

As a practical matter the tlp migration scripts seed the
committer group from the list in asf-authorization for svn.
The PMC is taken directly from the resolution, but if there
is no corresponding group in svn (say UCB applies to
the project) then the PMC chair has to seed the committer
group themselves.


It is remarkably easy for a chair to ensure that everyone on the pmc
is in fact in the unix group for the project:

% list_committee.pl foo | modify_unix_group.pl foo --add -

the code will filter out any redundancies automatically.

On Friday, April 4, 2014 7:38 AM, Bertrand Delacretaz bdelacre...@apache.org 
wrote:
 
Hi,

On Fri, Apr 4, 2014 at 12:29 PM, Edward J. Yoon edwardy...@apache.org wrote:
 ...When consider TLP graduation, all
 committers should be PPMC members?...

At the foundation level (i.e. in the board resolution that establishes
the project) we don't care about committers, it's only PMC members
which are relevant.

If a podling wishes to have only a subset of its committers as PPMC
members that's possible, and as I wrote earlier in this thread the
committers are not mentioned in the graduation resolution but they can
be re-established by the new PMC right after graduation.

IOW, PMC member is a foundation-level status whereas it's only the
PMC who's responsible for the committer status.

-Bertrand

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

CMS improvements of late...

[Joe Schaefer]

See http://blogs.apache.org/infra/entry/scaling_down_the_cms_to
for today's discussion of the Thrift migration to the CMS.
Basically there was a support gap for moderately-sized sites
that has now been filled with the latest changes to the cms
build libs.

HTH


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

Re: Podling new committer votes

[Joe Schaefer]

It doesn't.  People were just being pedantic
and untrusting of podling participants.  Committers
have accounts, not formal standing in the org.  There
is absolutely no reason for the IPMC to inject itself
in a podling election of a new committer, so let's just
leave oversight over the voting process to the mentors.
As a matter of fact, we don't even need to document a
standard for committer promotions- projects and podlings
alike are free to experiment with whatever process they
deem appropriate. Case in point is the Subversion process,
which essentially promotes new committers through lazy
consensus alone.

IOW +1 to roll back to pre-May 1, 2007.


- Original Message -
 From: ant elder ant.el...@gmail.com
 To: general@incubator.apache.org
 Cc: 
 Sent: Wednesday, July 10, 2013 3:04 PM
 Subject: Re: Podling new committer votes
 
 Ok seems everyone so far is ok with changing this, so how far can this go...
 
 In the experiment Joe commented ...basically rolling back the 
 clock
 to May 1, 2007 on guides/ppmc.html which is this change
 http://svn.apache.org/viewvc/incubator/public/trunk/content/guides/ppmc.xml?r1=517024r2=542806
 which added Only votes cast by Incubator PMC members are binding.
 Before then podlings did their own committer votes and the Incubator
 PMC weren't involved.
 
 Good we go back to that? Why does the Incubator PMC need to be notified?
 
    ...ant
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

personal expectations for ombudsman role

[Joe Schaefer]

Now that things have settled down a bit,
I'd like to talk about some of the things
I'm looking for out of the ombudsman post.

1) proactively solicits opinions of exiting podlings
   about their experiences in the form of interviews
   and surveys.

2) make anonymized results of (1) available to the IPMC
   on a regular basis.

3) provides advocacy and facilitates solutions for
   committers who report issues with their podling's
   mentors.


That's pretty much it- what are your expectations
for the ombudsman role?

Re: Stratos proposal: is it possible to add another initial committer?

[Joe Schaefer]

- Original Message -
 From: Marvin Humphrey mar...@rectangular.com
 To: general@incubator.apache.org
 Cc: 
 Sent: Tuesday, June 18, 2013 12:45 PM
 Subject: Re: Stratos proposal: is it possible to add another initial 
 committer?
 
 On Tue, Jun 18, 2013 at 5:34 AM, Ross Gardler
 rgard...@opendirective.com wrote:
  For me the social norm *should* be to allow things to progress
  unhindered unless an action is non-reversible and potentially damaging
  to the community.
 
 No.  That's not acceptable to me as an IPMC member.
 
 VOTEs are tied to specific language.


Agreed.  It is trivial to use the proper procedures to add new committers.
This episode does not justify a precedent of amendments to a document while
we are supposed to be evaluating and voting on it as offered.

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

Re: [PROPOSAL] Creation of the Incubator Ombudsman

[Joe Schaefer]

Cmon folks, all we're looking for is an email alias and
a descriptive title.  That's not *overhead* any more than
Greg's novel position as Vice Chair is *overhead* to the
board.  A title doesn't an officer make, there is no need
to imbue Incubator Ombudsman with any power whatsoever,
not even the power to compel people to take their work
seriously.  I wish we could get to reasonable objections
for this role instead of gut reactions about its perceived
optics.


- Original Message -
 From: Marvin Humphrey mar...@rectangular.com
 To: general@incubator.apache.org
 Cc: 
 Sent: Tuesday, June 18, 2013 6:13 PM
 Subject: Re: [PROPOSAL] Creation of the Incubator Ombudsman
 
 On Mon, Jun 17, 2013 at 9:14 PM, Mattmann, Chris A (398J)
 chris.a.mattm...@jpl.nasa.gov wrote:
  I'm not in favor of an Ombudsman. Seems like an extra
  layer of overhead beyond what the Chair already provides. Seriously
  does someone need a title in order to be the clearinghouse for folks'
  honest assessments of the Incubator, its personnel, or other sensitive
  issues?
 
 We could really do a much better job of gathering feedback, both solicited and
 unsolicited.
 
 I'm sensitive to the argument against layering on bureaucracy and 
 complexity.
 As with public APIs, it is often more difficult to remove stuff later than it
 was to add it.
 
 Maybe we should focus first on the service of exit interviews, rather than on
 the creation of a new title?  We should be able to do a decent job
 administering exit interviews with existing personnel.  The option to expand
 -- or not -- will always be available later, should the initiative prove
 successful.
 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [PROPOSAL] Creation of the Incubator Ombudsman

[Joe Schaefer]

It's easy for people to argue that we don't need it based
on the fact that nobody files formal complaints, but if you
think about it that's a self-fulfilling prophesy.  Unless
we try something different, we shouldn't expect anything to
change.

Your argument for a new list IS an argument for more bureaucracy.
Alan and I are simply asking for two things: a title and an alias
to go along with it.  That's it - no additional process, no new
oversight groups to participate in, no new powers to monitor.
Why so much reluctance to just honor the request such as it is
instead of looking for different ways of modifying it to taste?



- Original Message -
 From: Dave Fisher dave2w...@comcast.net
 To: general@incubator.apache.org
 Cc: 
 Sent: Tuesday, June 18, 2013 6:45 PM
 Subject: Re: [PROPOSAL] Creation of the Incubator Ombudsman
 
 I think what we really should discuss is how the IPMC can help podlings in as 
 simple a way as possible.
 
 I think we are looking for people in the IPMC who are willing to help 
 podlings 
 solved their real and their perceived problems. An Ombudsman is one title for 
 someone like that  and so is Shepherd.
 
 I think that there exists an ever changing group within the IPMC that in 
 their 
 own serves this function. These people meet at private@.
 
 Why can't a PPMC go to private@ with any issue and then someone can take 
 care of it?
 
 If the complaint is that the group is too large and will debate it endlessly 
 then the solution would be to have a smaller group with their own list - make 
 these people Shepherd / Ombudsmen / Lieutenants / Watchdogs - let them lean 
 in 
 on reports and respond to situations discretely. Let their report be 
 a private addition for the board report.
 
 Regards,
 Dave
 
 On Jun 18, 2013, at 3:22 PM, Joe Schaefer wrote:
 
  Cmon folks, all we're looking for is an email alias and
  a descriptive title.  That's not *overhead* any more than
  Greg's novel position as Vice Chair is *overhead* to the
  board.  A title doesn't an officer make, there is no need
  to imbue Incubator Ombudsman with any power whatsoever,
  not even the power to compel people to take their work
  seriously.  I wish we could get to reasonable objections
  for this role instead of gut reactions about its perceived
  optics.
 
 
  - Original Message -
  From: Marvin Humphrey mar...@rectangular.com
  To: general@incubator.apache.org
  Cc: 
  Sent: Tuesday, June 18, 2013 6:13 PM
  Subject: Re: [PROPOSAL] Creation of the Incubator Ombudsman
 
  On Mon, Jun 17, 2013 at 9:14 PM, Mattmann, Chris A (398J)
  chris.a.mattm...@jpl.nasa.gov wrote:
  I'm not in favor of an Ombudsman. Seems like an extra
  layer of overhead beyond what the Chair already provides. Seriously
  does someone need a title in order to be the clearinghouse for 
 folks'
  honest assessments of the Incubator, its personnel, or other 
 sensitive
  issues?
 
  We could really do a much better job of gathering feedback, both 
 solicited and
  unsolicited.
 
  I'm sensitive to the argument against layering on bureaucracy and 
  complexity.
  As with public APIs, it is often more difficult to remove stuff later 
 than it
  was to add it.
 
  Maybe we should focus first on the service of exit interviews, rather 
 than on
  the creation of a new title?  We should be able to do a decent job
  administering exit interviews with existing personnel.  The option to 
 expand
  -- or not -- will always be available later, should the initiative 
 prove
  successful.
 
  Marvin Humphrey
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: Stratos proposal: is it possible to add another initial committer?

[Joe Schaefer]

He said majority, not everybody ant. Try a little harder to
understand the written words instead of needing to interject
your dissonant 2 cents and things will improve around here.

Anyway the point is that when you see multiple changes to an
in-progress VOTE on a proposal, it suggests not that we
need to be more flexible, or let the champion dictate common
courtesy, but instead that the VOTE should restart once the
dust has settled as it was clearly premature.  If there's
some rush to modify the document instead of following approved
policy on adding new committers (which formally doesn't even
require a vote), just cancel+restart the vote once the proposal is
done being modified.  It's the most respectful thing to do.




- Original Message -
 From: ant elder ant.el...@gmail.com
 To: general@incubator.apache.org
 Cc: 
 Sent: Tuesday, June 18, 2013 6:57 PM
 Subject: Re: Stratos proposal: is it possible to add another initial 
 committer?
 
 On Tue, Jun 18, 2013 at 11:49 PM, Ross Gardler
 rgard...@opendirective.comwrote:
 
  It seems clear that the majority of IPMC members believe this change
  on a vote in progress is not acceptable.
 
 
 Don't assume its that clear, i think at least some agree with you that this
 is just ISSUE3 and kept quiet, thats what i did.
 
 I think its fine, its nothing like changing a release artifact during a
 release, IMHO the way to judge it is if the champion for the proposal being
 voted on doesn't object to the addition, if the champion is ok then just
 carry on.
 
    ...ant


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

Re: [DISCUSS] PodlingBillOfRights

[Joe Schaefer]

Did you read the topmatter disclaimer about the terminology?
Anyway no podling has a guaranteed right to a sufficient number
of mentors, that's why I didn't bother addressing Upayavira's
concern.  That is a best-effort attempt based on volunteer availability
not something we should commit to in a Bill of Rights.



- Original Message -
 From: Ross Gardler rgard...@opendirective.com
 To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com
 Cc: 
 Sent: Tuesday, June 18, 2013 7:09 PM
 Subject: Re: [DISCUSS] PodlingBillOfRights
 
 Joe, this is (in general) great. I feel I could pick a few holes and
 make a few suggestions but they are mostly insignificant so I'll
 refrain from doing so.
 
 I do have one concern I want to air. Unfortunately I don't have a
 suggestion for improvement so am happy for you to ignore it, but maybe
 someone else has a bright idea.
 
 My concern is the use of the word right. We are a volunteer
 organisation. Telling a podling they have a right to Foo and Bar
 might set the wrong tone. Upayavira appears to be thinking something
 similar (unless I'm misinterpreting him) when he asks:
 
 I guess a question that it would be worth clarifying - what happens to a
 perfectly reasonable podling who's mentors resign/go awol, when the
 Incubator PMC cannot recruit replacements? Can we make any promises at
 that point?
 
 Perhaps we can use a slightly softer word - perhaps I'm being too cautious.
 
 On 16 June 2013 15:16, Joe Schaefer joe_schae...@yahoo.com wrote:
  Since I realize that most of you can't be
  bothered to look at the wiki page I created ;-),
  I'll go ahead and post the current content
  here for commentary.  I hope the bulk of it
  is non-controversial, though some of it may
  not belong on the page...
 
 
  
  First a clarification- as provisional constructs of the Incubator PMC, 
 podlings have no official standing in the corporation known as The Apache 
 Software Foundation. So technically, it is a farce to claim that podlings 
 have 
 any formal rights whatsoever. What we write about here are promises and 
 covenants the Incubator PMC will make a good-faith effort to honor.
 
      1. First, podlings have a right to expect active participation and 
 guidance from their mentors. That minimally includes participation in release 
 votes, discussions and votes on new personnel, and signing off on a 
 podling's quarterly reports.
 
 
      2. Mentoring is done solely for the podling's benefit, and as such 
 podlings have the right to fire mentors for any reason by a majority 
 consensus 
 vote on their private list. Just don't be denigrating about it, since 
 mentors are always volunteers and not paid staff.
 
 
      3. Podlings who find themselves in need of additional mentors have the 
 right to ask general@incubator for more mentors to volunteer.
 
 
      4. Podlings have the right to expect their quarterly reports to be 
 read, reviewed, and critiqued by shepherds on the Incubator PMC, who 
 are typically outside the podling's set of mentors.
 
 
      5. Podlings have the right to express private concerns about anything 
 related to their incubation to the Incubator Ombudsman 
 ombudsman@incubator, who will handle such communications as if they were 
 sent anonymously.
 
 
      6. Podlings have the right to express their opinions concerning their 
 incubation efforts post-graduation (or post-mortem) in the form of an 
 anonymous 
 survey.
 
 
      7. Podlings have the right to ignore commentary made on 
 general@incubator in the middle of a VOTE thread, especially during releases. 
 Reminder- release votes are a majority consensus vote, so seeing a few -1's 
 occasionally is expected and often ignorable by the RM should they otherwise 
 see 
 a majority of at least 3 binding IPMC votes.
 
 
      8. Podling committers have the right to remain unsubscribed to 
 general@incubator. Any relevant policy/process changes will be passed along 
 by 
 the podling's mentors.
  
 
  Comments and critiques welcome.  I'd like to
  move the ball forward to a ceremonial endorsement
  VOTE on this over the course of the remainder
  of June, so please be constructive!
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [DISCUSS] PodlingBillOfRights

[Joe Schaefer]

- Original Message -

 From: Roman Shaposhnik r...@apache.org
 To: Joseph Schaefer joe_schae...@yahoo.com
 Cc: general@incubator.apache.org
 Sent: Monday, June 17, 2013 2:02 AM
 Subject: Re: [DISCUSS] PodlingBillOfRights
 
 On Sun, Jun 16, 2013 at 10:48 PM, Joseph Schaefer
 joe_schae...@yahoo.com wrote:
  The typical escalation path is either board@ or board-private@ assuming 
 private messages
  to the chair are ineffective.  Most of the time, for most of our projects, 
 this has worked well enough.
 
 So isn't learning this bit of information a crucial part of graduation? 
 After
 all, once the project leaves the incubator its commiters and PMC won't have
 an access to the Ombudsman, isn't it in all of our best interest to teach
 them from the get-go what you've just described above?


Not really, because the type of information we're looking for is about the
IPMC, not the podling.

 
 What's the danger of hooking up poddlings to the very channels they should
 be using once they graduate?
 
  The real issue for the IPMC boils down to the judgement call of whether the 
 standard
  escalation procedures are working to everyone's satisfaction,
 
 Do we have real indication they are not?


Isn't this an academic question?  Those of us that have been here a while have
seen any number of cases where podling committers feel frustrated about the 
process and powerless to do anything about it.  This isn't a new problem.


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

[DISCUSS] PodlingBillOfRights

[Joe Schaefer]

Since I realize that most of you can't be
bothered to look at the wiki page I created ;-),
I'll go ahead and post the current content
here for commentary.  I hope the bulk of it
is non-controversial, though some of it may
not belong on the page...



First a clarification- as provisional constructs of the Incubator PMC, podlings 
have no official standing in the corporation known as The Apache Software 
Foundation. So technically, it is a farce to claim that podlings have any 
formal rights whatsoever. What we write about here are promises and covenants 
the Incubator PMC will make a good-faith effort to honor.

1. First, podlings have a right to expect active participation and guidance 
from their mentors. That minimally includes participation in release votes, 
discussions and votes on new personnel, and signing off on a podling's 
quarterly reports.


2. Mentoring is done solely for the podling's benefit, and as such podlings 
have the right to fire mentors for any reason by a majority consensus vote on 
their private list. Just don't be denigrating about it, since mentors are 
always volunteers and not paid staff.


3. Podlings who find themselves in need of additional mentors have the 
right to ask general@incubator for more mentors to volunteer.


    4. Podlings have the right to expect their quarterly reports to be read, 
reviewed, and critiqued by shepherds on the Incubator PMC, who are typically 
outside the podling's set of mentors.


5. Podlings have the right to express private concerns about anything 
related to their incubation to the Incubator Ombudsman ombudsman@incubator, 
who will handle such communications as if they were sent anonymously.


6. Podlings have the right to express their opinions concerning their 
incubation efforts post-graduation (or post-mortem) in the form of an anonymous 
survey.


7. Podlings have the right to ignore commentary made on general@incubator 
in the middle of a VOTE thread, especially during releases. Reminder- release 
votes are a majority consensus vote, so seeing a few -1's occasionally is 
expected and often ignorable by the RM should they otherwise see a majority of 
at least 3 binding IPMC votes.


8. Podling committers have the right to remain unsubscribed to 
general@incubator. Any relevant policy/process changes will be passed along by 
the podling's mentors.


Comments and critiques welcome.  I'd like to
move the ball forward to a ceremonial endorsement
VOTE on this over the course of the remainder
of June, so please be constructive!

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

Re: [PROPOSAL] Creation of the Incubator Ombudsman

[Joe Schaefer]

Yeah I get that, but I'm wondering what sort of power we'd
impart to the position besides information gathering.  It
might make an interesting complementary position to the
chair that's more directly focused on the Incubator as it
presents itself to podlings, which is something we recently
discussed in relation to the recent chair vote.


- Original Message -
 From: Alan Cabrera l...@toolazydogs.com
 To: general@incubator.apache.org
 Cc: 
 Sent: Sunday, June 16, 2013 1:36 PM
 Subject: Re: [PROPOSAL] Creation of the Incubator Ombudsman
 
 
 On Jun 15, 2013, at 10:52 AM, Joseph Schaefer joe_schae...@yahoo.com 
 wrote:
 
  This is a suggestion that has come up in the past, and the typical 
 counter-argument is that this is something the chair needs to provide 
 themselves.
 
  Sent from my iPhone
 
 The usual reason for an ombudsman is to have a safe third party to bring up 
 issues up privately.  Podling members may feel too intimidated to complain to 
 mentors/IPMC chairs to complain.  Maybe the complaint may be an absentee, or 
 problem, mentor or chair.  One never knows.
 
 
 Regards,
 Alan


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

Re: Incubator reorg ideas: sub-groups per technology?

[Joe Schaefer]

I'm with Alan on our penchant to solve people
problems with reorganization.  We lack tangible
means of measuring and recognizing that actual
oversight is happening in these podlings.  And
by that I mean that somebody is actually following
along as the project develops and providing them
with requisite guidance.

This whole idea of technology subgroups harkens
back to the original organizational structure at
Apache, which we abandoned a long time ago because
it wound up despoiling our real goal of self-
governance.  Why it's being reintroduced again
just means to me that we don't ever learn from our
past mistakes.





 From: Upayavira u...@odoko.co.uk
To: general@incubator.apache.org 
Sent: Saturday, June 15, 2013 10:16 AM
Subject: Re: Incubator reorg ideas: sub-groups per technology?
 

I think there's merit in the idea of multiple, smaller incubators, so
long as it is set up in a way that doesn't involve prospective podlings
playing the incubators against each other.

Smaller groups, with smaller membership, gives the chance of a greater
sense of ownership and identification, which are important to community
building.

Upayavira

On Fri, Jun 14, 2013, at 11:58 PM, Shane Curcuru wrote:
 Apologies if this horse has been beaten already, but... have we 
 discussed the concept of splitting incubator operations into a handful 
 of separate groups, based on technology areas?
 
 I.e. while the IPMC or ComDev or whoever would still set policy and 
 provide community best practice guidance.  But then separate mailing 
 lists/groups would provide actual oversight of podlings (incoming, 
 mentoring, graduating).  These would be based on rough technology areas: 
 java, hadoop, servers, UI, whatever.
 
 That way, people could participate in governance oversight and mentoring 
 in focus areas that they care about, and not have to immediately deal 
 with the many other podlings that are not related in terms of 
 technology/interest areas.
 
 Obviously there's a lot about coordinating suggested feedback on 
 policies, best practices, etc. between the groups and the core 
 IPMC/ComDev., but it would (hopefully) result in most of the groups 
 being much quieter, and more focused.
 
 - Shane, off to make a GT
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Re: Incubator reorg ideas: sub-groups per technology?

[Joe Schaefer]

What we really need for podlings is a bill of
rights towards what they can expect of their
mentors, because too few of them actually are
willing to question the participation of the
people who signed up to mentor them and that's
not helping anybody.




 From: Alan Cabrera l...@toolazydogs.com
To: general@incubator.apache.org 
Sent: Saturday, June 15, 2013 11:04 AM
Subject: Re: Incubator reorg ideas: sub-groups per technology?
 


On Jun 15, 2013, at 7:16 AM, Upayavira u...@odoko.co.uk wrote:

 I think there's merit in the idea of multiple, smaller incubators, so
 long as it is set up in a way that doesn't involve prospective podlings
 playing the incubators against each other.

Can you provide detail on what you mean by prospective podlings playing the 
incubators against each other?  I'm not sure what that means.

 Smaller groups, with smaller membership, gives the chance of a greater
 sense of ownership and identification, which are important to community
 building.

Is that really our problem?  Who needs this greater sense of ownership and 
identification?  

In short, I'd like proponents of this thread to explain in concrete detail:
What is the problem to be solved?
What is the base cause of that problem?
How does splitting the Incubator in to sub-groups of technology solves the 
cause of this problem?


Regards,
Alan

Re: [Incubator Wiki] Update of PodlingBillOfRights by JoeSchaefer

[Joe Schaefer]

Ok Alan I'm done hacking on the page for now.
Have at it folks, if you so choose.




 From: Apache Wiki wikidi...@apache.org
To: Apache Wiki wikidi...@apache.org 
Sent: Saturday, June 15, 2013 12:52 PM
Subject: [Incubator Wiki] Update of PodlingBillOfRights by JoeSchaefer
 

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Incubator Wiki for 
change notification.

The PodlingBillOfRights page has been changed by JoeSchaefer:
https://wiki.apache.org/incubator/PodlingBillOfRights?action=diffrev1=3rev2=4

Comment:
a few ignorables

  
  6) Podlings have the right to express their opinions concerning their 
incubation efforts post-graduation (or post-mortem) in the form of an 
anonymous survey.
  
+ 7) Podlings have the right to ignore commentary made on general@incubator in 
the middle of a VOTE thread, especially during releases.  Reminder- release 
votes are a majority consensus vote, so a seeing a few -1's occasionally are 
expected and often ignorable by the RM should he otherwise see a majority of 
at least 3 binding IPMC votes.
+ 
+ 8) Podling committers have the right to remain unsubscribed to 
general@incubator. Any relevant policy changes can expected to be passed along 
by the podling's mentors.
+ 

-
To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
For additional commands, e-mail: cvs-h...@incubator.apache.org

Re: [DISCUSS] Accept Stratos as an Apache Incubation Project

[Joe Schaefer]

It'd help to know concretely what is meant
by a probationary TLP, particularly what
is different about it from normal incubation.
I am not looking for yet another email discussion,
but an URL to a wiki page would be nice.




 From: Ross Gardler rgard...@opendirective.com
To: general@incubator.apache.org 
Sent: Wednesday, June 12, 2013 10:12 PM
Subject: Re: [DISCUSS] Accept Stratos as an Apache Incubation Project
 

So here's a thought...

There have been many discussions about different ways to incubate
projects. One of the most radical ideas is to dismantle the incubator
and replace the podling concept with probationary TLPs reporting to
the board. As readers of this list will know I do not support the idea
of dismantling the IPMC. I believe it does a great job that is not
easily replaced by a board of nine directors. However, I have always
acknowledged that the idea has merit under a certain set of
circumstances.

For me those circumstances are present in the Apache Stratos proposal.
That is there are sufficient mentors and initial committers who are
ASF Members that we can be reasonably certain that this project will
succeed here at the ASF.

I would therefore like to propose that we use Apache Stratos as a test
case for the probationary TLP idea. I've already talked to Chris
(who is driving the deconstruct the IPMC case) and Ant (who is less
keen on dismantling the IPMC but wants to see how a probationary TLP
model will play out). Both have agreed to help with this experiment if
the IPMC and the Board wish it to proceed. I have not, however,
discussed it with all the initial comitters or even mentors - I'm
expecting them to speak up now.

For my part my intention is to get the project set-up and then
dissolve into the background. I do not intend to monitor the project
on a day-to-day basis. However, I do promise to help pick up the
pieces if the experiment should go horribly wrong.

Of course running a single experiment will only allow us to define the
incubation process for probationary TLPs, It is not going to solve all
the problems Chris sees in the IPMC. However it will give us an
opportunity to define the process, ask the board to approve this
process and thus lay the foundations for other projects wishing to
follow this path.

So, what do you think?

Ross


On 11 June 2013 10:10, Ross Gardler rgard...@opendirective.com wrote:
 It's with great pleasure that I invite the IPMC to review a new
 proposal [1] for the Apache Incubator. Please let us know if you have
 any questions or comments - as you will see there are plenty of people
 on the initial commit list ready and willing to answer your questions.

 I copy the full text of the proposal for your convenience:

 = Stratos - A PaaS Framework =
 == Abstract ==
 Stratos will be a polyglot
 [[http://www.gartner.com/it-glossary/platform-as-a-service-paas|PaaS]]
 framework, providing developers a cloud-based environment for
 developing, testing, and running scalable applications, and IT
 providers high utilization rates, automated resource management, and
 platform-wide insight including monitoring and billing.
 == Proposal ==
 The Stratos PaaS framework will encompass four layers:
  1. An 
[[http://www.gartner.com/it-glossary/infrastructure-as-a-service-iaas/|IaaS]]-agnostic
 layer that can interface with a wide variety of IaaS systems to
 provide elastic resources, and for multiple IaaS infrastructures to be
 automated at one time (hybrid clouds.)
  2. A PaaS Controller with a cloud controller that automates and
 monitors IaaS runtime interactions, distributes artifacts to the
 underlying runtimes, deploys workloads, directs runtime traffic to the
 right runtimes using a tenant-aware elastic load balancer, and
 provides a portal for monitoring and provisioning of tenants on the
 system.
  3. Foundational Services including security, logging, messaging,
 registry, storage (relational, file, and noSQL), task management, and
 billing.  Foundational services will be loosely-coupled to allow
 swapping in alternate foundational services.
  4. A Cartridge Architecture allowing frameworks, servers, and other
 runtimes to participate in the advantages of the system.  The
 Cartridge Architecture must support multi-tenant workloads, and
 provide for various levels of tenant isolation and policy-based
 control over provisioning.

 Together these layers offer a foundational layer upon which
 applications and middleware frameworks can be deployed to speed
 time-to-market and simplify the development of scalable applications,
 as well as provide a high level of resource sharing and centralized
 management that can deliver lowest resource, infrastructure, and
 management costs.
 == Background ==
 The Stratos Project has been under development[a] at http://wso2.org
 under the Apache 2.0 license and the Apache Way governance model since
 2010.  It initially was focussed on providing PaaS benefits to the
 users of WSO2 Carbon 

Re: Vote on personal matters: majority vote vs consensus

[Joe Schaefer]

Yes your logic is flawed- what you are actually
arguing for is majority voting not consensus voting,
and bringing the criterion down from 100% to 
75% only helps mitigate your concerns.

As Doug points out, votes are structured away
from the status quo- we don't ever vote to 
continue on with previously agreed to issues
just to circumvent the voting process.






 From: ant elder ant.el...@gmail.com
To: general@incubator.apache.org 
Sent: Thursday, March 28, 2013 12:29 PM
Subject: Re: Vote on personal matters: majority vote vs consensus
 
On Thu, Mar 28, 2013 at 2:17 PM, Joseph Schaefer joe_schae...@yahoo.com 
wrote:
 No more so than they already had.


It does Joe, let me give you a more clear example.

Lets imagine i've done something that you deem shows i'm a terrible
incubator mentor, and its not the first time.

There's a big debate within the PMC, no clear consensus, so in the end
you say enough is enough and call a vote to remove me so i don't do
any more damage - a vote on removing ant.

With this new supermajority approach you'd need 75% or more of voters
to agree with you to get me gone.

Alternatively, you could say enough is enough and to end the debate
you're going to call a vote to demonstrate i've the PMCs support - a
vote on letting ant stay on. That sounds like you're being nice, but
in fact you're being clever, because now you only need 25% of voters
to vote -1 and i'm gone.

25% is much easier to get than the 75% in the previous vote example.

The problem here i think is that the policy is being rushed through
and people are only thinking of the voting people to the PMC case
whereas the policy is going to apply much more widely that  - to all
votes on personal matters - so lots of scope for wording bias.

Isn't this the case? Apologies in advance for the noise if my logic is
screwed up somewhere.

   ...ant

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

Re: [PROPOSAL] Ivory - Hadoop data management and processing platform

[Joe Schaefer]

Can we pretty-please do this *before* resources
are requested, just to save us poor infra saps
the trouble of renaming everything?






 From: Jakob Homan jgho...@gmail.com
To: general@incubator.apache.org 
Sent: Friday, March 15, 2013 8:18 PM
Subject: Re: [PROPOSAL] Ivory - Hadoop data management and processing platform
 
As part of Incubation a suitable name search will be done to verify the
name's appropriate.  I imagine Ivory would fail this test based on the
prior project, so this Ivory would need to find a new name.  Alternatively,
before the vote, the Ivory folks can find another name.  This has happened
before (Howl - HCatalog), so it's not a huge reason to be concerned.


On Fri, Mar 15, 2013 at 5:15 PM, Dmitriy Ryaboy dvrya...@gmail.com wrote:

 It would be awfully nice of you not to stomp on another hadoop ecosystem
 project's google-fu when your project becomes very successful and admired
 across the hadoopverse :)

 Ivory isn't a fly-by-night project someone threw up on github -- it's
 generated over a dozen peer-reviewed papers, and has many watchers and dev
 forks.

 I don't have a vote here, but I'd say that yes, this will lead to confusion
 when people look for hadoop ivory.

 D


 On Fri, Mar 15, 2013 at 11:09 AM, Seetharam Venkatesh 
 venkat...@innerzeal.com wrote:

  Hi Henry,
 
  Is there a concern with the current name? The closest is a tool for
  Information Retrieval. Not sure if there is an overlap.  We will also
 bring
  this up with the champion and mentors to see if this needs to be vet with
  trademarks folks as well.
 
  Your suggestions are welcome.
 
  Thanks!
 
 
  On Fri, Mar 15, 2013 at 10:18 AM, Henry Saputra henry.sapu...@gmail.com
  wrote:
 
   HI Srikanth,
  
   So does the Ivory name stay or once the podling near graduation it will
  try
   to find another name?
  
   - Henry
  
  
   On Fri, Mar 15, 2013 at 12:34 AM, Srikanth Sundarrajan 
   srikanth.sundarra...@inmobi.com wrote:
  
Made few edits to the proposal (
http://wiki.apache.org/incubator/IvoryProposal) as per the feedback
received so far.
   
Regards
Srikanth Sundarrajan
   
= Ivory Proposal =
   
== Abstract ==
Ivory is a data processing and management solution for Hadoop
 designed
for data motion, coordination of data pipelines, lifecycle
 management,
and data discovery. Ivory enables end consumers to quickly onboard
their data and its associated processing and management tasks on
Hadoop clusters.
   
== Proposal ==
Ivory will enable easy data management via declarative mechanism for
Hadoop. Users of Ivory platform simply define infrastructure
endpoints, data sets and processing rules declaratively. These
declarative configurations are expressed in such a way that the
dependencies between these configured entities are explicitly
described. This information about inter-dependencies between various
entities allows Ivory to orchestrate and manage various data
management functions.
   
The key use cases that Ivory addresses are:
     * Data Motion
     * Process orchestration and scheduling
     * Policy-based Lifecycle Management
     * Data Discovery
     * Operability/Usability
   
With these features it is possible for users to onboard their data
sets with a comprehensive and holistic understanding of how, when and
where their data is managed across its lifecycle. Complex functions
such as retrying failures, identifying possible SLA breaches or
automated handling of input data changes are now simple directives.
All the administrative functions and user level functions are
available via RESTful APIs. CLI is simply a wrapper over the RESTful
APIs.
   
== Background ==
Hadoop and its ecosystem of products have made storing and processing
massive amounts of data commonplace. This has enabled numerous
organizations to gain valuable insights that they never could have
achieved in the past. While it is easy to leverage Hadoop for
crunching large volumes of data, organizing data, managing life cycle
of data and processing data is fairly involved. This is solved
adequately well in a classic data platform involving data warehouses
and standard ETL (extract-transform-load) tools, but remains largely
unsolved today. In addition to data processing complexities, Hadoop
presents new sets of challenges and opportunities relating to
management of data.
   
Data Management on Hadoop encompasses data motion, process
orchestration, lifecycle management, data discovery, etc. among other
concerns that are beyond ETL. Ivory is a new data processing and
management platform for Hadoop that solves this problem and creates
additional opportunities by building on existing components within
 the
Hadoop ecosystem (ex. Apache Oozie, Apache Hadoop DistCp etc.)
 without
reinventing the wheel. Ivory has been in 

Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release

[Joe Schaefer]

That's not your role as chair to be personally
concerned about a project release- that's the
group's responsibility.  You should confine
your concerns to our efficacy and ability to
carry out the role of an IPMC member properly.


IOW relax, the outcome isn't going to sink the
org one way or another ;-).





 From: Benson Margulies bimargul...@gmail.com
To: general@incubator.apache.org general@incubator.apache.org 
Sent: Friday, January 25, 2013 3:55 PM
Subject: Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
 
Chris et al,

I'm suffering from a mild crisis of responsibility here. I'm the VP of
the incubator. cTakes is planning to ship a release containing
something that, according to some lights, is inadmissible. If that
'something' is in *the (source) release*, I have serious qualms. If
it's merely in a the convenience binaries, I have fewer. We have a
ticket open at LEGAL, and no response except postings of opinion.

So, am I supposed to drop a hammer here, required to drop a hammer
here, or am I having an acute Alexander Haig moment by even
considering dropping a hammer here?

I know that a number of board members read this list, so perhaps one
or more will tell me which padded cell I should retire to.

--benson

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

Re: [DISCUSS] Expressing priorities about release reviews

[Joe Schaefer]

Trust me, nobody here has any legal training either.
We're just more familiar with policy, not so much the
rationale behind it.  And no I'm not saying this
kind of review is worthless, I'm just trying to
adjust priorities to better match reality- we can
provide this legal feedback in other ways than simply
voting against a release, and that's what I'm
pointing out here.




- Original Message -
 From: Alex Harui aha...@adobe.com
 To: Joe Schaefer joe_schae...@yahoo.com; general@incubator.apache.org 
 general@incubator.apache.org
 Cc: 
 Sent: Monday, January 14, 2013 12:46 PM
 Subject: Re: [DISCUSS] Expressing priorities about release reviews
 
 
 
 
 On 1/14/13 9:20 AM, Joe Schaefer joe_schae...@yahoo.com 
 wrote:
 
  The thing is Alex, all of this effort
  to dot our i's and cross our t's on the legal
  issues really is only for the benefit
  of major corporations who want to incorporate
  our work into some corporate-branded application.
  Actual end users of our software do not benefit
  one iota from the type of nitpicking we do on
  general@incubator, nor does the org's reputation
  for clean IP hinge on these considerations.
 
  My attitude is to let the elephants in our projects
  provide their own feedback directly to the projects
  on the legal nitpicks that cause them pain- we do not
  need to police these minor issues on their behalf in a
  generic way.
 
 I'm not sure I know what an elephant is in this context.  And 
 I'm not
 quite sure what issues are considered 'i' and 't'.  IMO, it was 
 a good
 lesson for our podling to see that we can get delayed by not getting the
 LICENSE and NOTICE and other files right, so we had proper expectations set
 for when we became a TLP.   And IMO, because IANAL and nobody else in the
 podling is either, it was good to have other sets of eyes on the reviews.
 
 -- 
 Alex Harui
 Flex SDK Team
 Adobe Systems, Inc.
 http://blogs.adobe.com/aharui


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

[DISCUSS] Expressing priorities about release reviews

[Joe Schaefer]

One of my long time pet peeves with how we
PMC members participate in vetting releases
is our penchant for focusing too much on the
policies surrounding license and notice info.
I really think our exclusive focus on things
that really don't pose any organizational risk
to either the org nor the project participants
serves us well in our other, often unexpressed
but far more relevant, goals about encouraging
committers to participate in active review of
their project's commit activity.

Just think about this for a second, what's more
likely for people to start suing us over, some
bug in the NOTICE file or an undetected backdoor
in one of our programs?  I am personally far more
concerned about the current state of the actual
review going on in our podlings than I am about
NOTICE minutia.

Maybe we should compile some list of which committers
are actually subscribed to their project's commit lists?
It's crude but it may be useful data to look at to
a first order.

Re: [DISCUSS] Expressing priorities about release reviews

[Joe Schaefer]

The thing is, as far as risk management
goes, the vetting we do on general@incubator
is largely ceremonial.  The real responsible
review work is done by people who are reviewing
commit activity, and it is a shame we don't
do a better job of empowering these conscientious
reviewers with a binding vote on a release.






 From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov
To: general@incubator.apache.org general@incubator.apache.org; Joe 
Schaefer joe_schae...@yahoo.com 
Sent: Saturday, January 12, 2013 12:30 PM
Subject: Re: [DISCUSS] Expressing priorities about release reviews
 
I agree with you on this Joe. A lot of times my metric is more
responsiveness and participation than in legal/language intricacies. More
power to folks who are good at that, it's just not me.

Cheers,
Chris

On 1/12/13 9:07 AM, Joe Schaefer joe_schae...@yahoo.com wrote:

One of my long time pet peeves with how we
PMC members participate in vetting releases
is our penchant for focusing too much on the
policies surrounding license and notice info.
I really think our exclusive focus on things
that really don't pose any organizational risk
to either the org nor the project participants
serves us well in our other, often unexpressed
but far more relevant, goals about encouraging
committers to participate in active review of
their project's commit activity.

Just think about this for a second, what's more
likely for people to start suing us over, some
bug in the NOTICE file or an undetected backdoor
in one of our programs?  I am personally far more
concerned about the current state of the actual
review going on in our podlings than I am about
NOTICE minutia.

Maybe we should compile some list of which committers
are actually subscribed to their project's commit lists?
It's crude but it may be useful data to look at to
a first order.


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

Re: [DISCUSS] Expressing priorities about release reviews

[Joe Schaefer]

If we ran infra the way this PMC
manages its own constituency, we
wouldn't have a single volunteer
willing to work constructively
with us.  Sometimes it's better
to let go of control and let people
work to impress you with the karma
you have given them.






 From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov
To: general@incubator.apache.org general@incubator.apache.org; Joe 
Schaefer joe_schae...@yahoo.com 
Sent: Saturday, January 12, 2013 12:44 PM
Subject: Re: [DISCUSS] Expressing priorities about release reviews
 
Totally agree, Joe.

Cheers,
Chris

On 1/12/13 9:37 AM, Joe Schaefer joe_schae...@yahoo.com wrote:

The thing is, as far as risk management
goes, the vetting we do on general@incubator
is largely ceremonial.  The real responsible
review work is done by people who are reviewing
commit activity, and it is a shame we don't
do a better job of empowering these conscientious
reviewers with a binding vote on a release.






 From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov
To: general@incubator.apache.org general@incubator.apache.org; Joe
Schaefer joe_schae...@yahoo.com
Sent: Saturday, January 12, 2013 12:30 PM
Subject: Re: [DISCUSS] Expressing priorities about release reviews
 
I agree with you on this Joe. A lot of times my metric is more
responsiveness and participation than in legal/language intricacies. More
power to folks who are good at that, it's just not me.

Cheers,
Chris

On 1/12/13 9:07 AM, Joe Schaefer joe_schae...@yahoo.com wrote:

One of my long time pet peeves with how we
PMC members participate in vetting releases
is our penchant for focusing too much on the
policies surrounding license and notice info.
I really think our exclusive focus on things
that really don't pose any organizational risk
to either the org nor the project participants
serves us well in our other, often unexpressed
but far more relevant, goals about encouraging
committers to participate in active review of
their project's commit activity.

Just think about this for a second, what's more
likely for people to start suing us over, some
bug in the NOTICE file or an undetected backdoor
in one of our programs?  I am personally far more
concerned about the current state of the actual
review going on in our podlings than I am about
NOTICE minutia.

Maybe we should compile some list of which committers
are actually subscribed to their project's commit lists?
It's crude but it may be useful data to look at to
a first order.


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





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

Re: [DISCUSS] Expressing priorities about release reviews

[Joe Schaefer]

Yes you make a good point- that any effort
towards review is welcome and appreciated.
It's just that having an exclusive focus
on the things we can actually review here,
namely adherence to License and Notice policy,
can leave people with the mistaken impression
that that's all that a PMC should concern itself
with.  All of that daily effort that goes into
validating commits on a project really should
garner more appreciation from the PMC, if we
could just find a way to be more trusting about
who we let issue binding votes on behalf of
the org.


Really is it so bad to say to a project with
a bug in their license and notice info: fix
this in trunk and show me the revision and
I'll go ahead and approve your release as-is.

Running through iterations of this is very
labor-intensive for the project, and anything
we can do to cut down on the pain involved
in cutting incubator releases is IMO worthwhile.






 From: Sergio Fernández sergio.fernan...@salzburgresearch.at
To: general@incubator.apache.org 
Cc: Joe Schaefer joe_schae...@yahoo.com 
Sent: Saturday, January 12, 2013 2:22 PM
Subject: Re: [DISCUSS] Expressing priorities about release reviews
 
Joe,

personally I appreciate such policies checking from the IPMC members. The 
technical quality of a release is responsibility of the project itself, which 
could be hard to be evaluated by people working on other topics. Therefore, 
all additional checkpoints are useful and grateful.

Cheers,


On 12/01/13 18:07, Joe Schaefer wrote:
 One of my long time pet peeves with how we
 PMC members participate in vetting releases
 is our penchant for focusing too much on the
 policies surrounding license and notice info.
 I really think our exclusive focus on things
 that really don't pose any organizational risk
 to either the org nor the project participants
 serves us well in our other, often unexpressed
 but far more relevant, goals about encouraging
 committers to participate in active review of
 their project's commit activity.
 
 Just think about this for a second, what's more
 likely for people to start suing us over, some
 bug in the NOTICE file or an undetected backdoor
 in one of our programs?  I am personally far more
 concerned about the current state of the actual
 review going on in our podlings than I am about
 NOTICE minutia.
 
 Maybe we should compile some list of which committers
 are actually subscribed to their project's commit lists?
 It's crude but it may be useful data to look at to
 a first order.
 

-- Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at

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

Re: Cloudstack report signoffs

[Joe Schaefer]

May have simply been to indicate that
there's new content in the report that
needs to be processed by mentors.  I'm
not worried about it personally.






 From: Benson Margulies bimargul...@gmail.com
To: cloudstack-...@incubator.apache.org; general@incubator.apache.org 
general@incubator.apache.org 
Sent: Thursday, January 10, 2013 3:58 PM
Subject: Cloudstack report signoffs
 
If I read the diffs correctly, Joe just posted an update to the report
which removed all the mentor signoffs.

Was this on purpose?

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

Re: PPMC versus commiter

[Joe Schaefer]

The thing to avoid is to wind up with a significant number of active 
contributors on a project who are not on the pmc.  Separating committers from 
pmc members can be a symptom but it's manageable under the right conditions.  
Note committers aren't the only class of contributors that projects might be 
unintentionally excluding from pmc participation.

Sent from my iPhone

On Dec 19, 2012, at 11:50 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 Well, different policies make sense at different phases of growth.  A new
 project is in growth mode and a major goal is to bind people into the
 project.  C == PMC helps do that.  If you have nothing to lose and
 everything to gain, then this is a pretty reasonable idea.
 
 A more mature project has something to lose so there is a case that C !=
 PMC makes some sense.
 
 On Wed, Dec 19, 2012 at 5:02 AM, Christian Grobmeier 
 grobme...@gmail.comwrote:
 
 2. Historically, podlings have *not* maintained this distinction, but
 have waited for graduation to sort  out the initial PMC members.
 
 Why do they behave differently than later as TLD?
 

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

Re: PPMC versus commiter

[Joe Schaefer]

Sent from my iPhone

On Dec 19, 2012, at 11:50 AM, Mattmann, Chris A (388J) 
chris.a.mattm...@jpl.nasa.gov wrote:

 Is it a fight to state an opinion, when one has already been stated,
 Marvin? C'mon now.
 Fair's fair, you already got yours out so I have every right to get mine
 out.
 
 To your point of we shouldn't legislate this across all podlings/projects,
 +1 to that.
 
 To your point of ending this useless thread, +1 to that.
 
 Cheers,
 Chris
 
 On 12/19/12 8:38 AM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Wed, Dec 19, 2012 at 8:35 AM, Mattmann, Chris A (388J)
 chris.a.mattm...@jpl.nasa.gov wrote:
 I have always recommended PPMC==C on all of my podlings, and was taught
 about that flat organizational structure when I started to see the light
 at Apache.
 
 Argh, do we really have to have this knock-down drag-out fight again?
 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Re: PPMC versus commiter

[Joe Schaefer]

Marvin didn't even make his full point about Lucy- the fact is that all Apache 
committers have commit to Lucy.  Putting them all on the pmc would be nuts in 
an entirely different way!
Sent from my iPhone

On Dec 19, 2012, at 11:50 AM, Mattmann, Chris A (388J) 
chris.a.mattm...@jpl.nasa.gov wrote:

 Is it a fight to state an opinion, when one has already been stated,
 Marvin? C'mon now.
 Fair's fair, you already got yours out so I have every right to get mine
 out.
 
 To your point of we shouldn't legislate this across all podlings/projects,
 +1 to that.
 
 To your point of ending this useless thread, +1 to that.
 
 Cheers,
 Chris
 
 On 12/19/12 8:38 AM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Wed, Dec 19, 2012 at 8:35 AM, Mattmann, Chris A (388J)
 chris.a.mattm...@jpl.nasa.gov wrote:
 I have always recommended PPMC==C on all of my podlings, and was taught
 about that flat organizational structure when I started to see the light
 at Apache.
 
 Argh, do we really have to have this knock-down drag-out fight again?
 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


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

Re: PPMC versus commiter

[Joe Schaefer]

It certainly should be discu

Sent from my iPhone

On Dec 19, 2012, at 12:40 PM, Benson Margulies bimargul...@gmail.com wrote:

 I'm sorry to generate the latest incarnation of this perpetual
 annoyance. I don't think that there's an argument to win here; as
 always there is a spectrum of opinion and experience. I started this
 thread because I thought that a vote thread was not the best place to
 open the conversation with a particular podling about starting to
 distinguish C from PPMC.
 
 On Wed, Dec 19, 2012 at 12:08 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 
 Marvin didn't even make his full point about Lucy- the fact is that all 
 Apache committers have commit to Lucy.  Putting them all on the pmc would be 
 nuts in an entirely different way!
 Sent from my iPhone
 
 On Dec 19, 2012, at 11:50 AM, Mattmann, Chris A (388J) 
 chris.a.mattm...@jpl.nasa.gov wrote:
 
 Is it a fight to state an opinion, when one has already been stated,
 Marvin? C'mon now.
 Fair's fair, you already got yours out so I have every right to get mine
 out.
 
 To your point of we shouldn't legislate this across all podlings/projects,
 +1 to that.
 
 To your point of ending this useless thread, +1 to that.
 
 Cheers,
 Chris
 
 On 12/19/12 8:38 AM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Wed, Dec 19, 2012 at 8:35 AM, Mattmann, Chris A (388J)
 chris.a.mattm...@jpl.nasa.gov wrote:
 I have always recommended PPMC==C on all of my podlings, and was taught
 about that flat organizational structure when I started to see the light
 at Apache.
 
 Argh, do we really have to have this knock-down drag-out fight again?
 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Re: PPMC versus commiter

[Joe Schaefer]

Probably better to discuss on the project's lists than here

Sent from my iPhone

On Dec 19, 2012, at 12:40 PM, Benson Margulies bimargul...@gmail.com wrote:

 I'm sorry to generate the latest incarnation of this perpetual
 annoyance. I don't think that there's an argument to win here; as
 always there is a spectrum of opinion and experience. I started this
 thread because I thought that a vote thread was not the best place to
 open the conversation with a particular podling about starting to
 distinguish C from PPMC.
 
 On Wed, Dec 19, 2012 at 12:08 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 
 Marvin didn't even make his full point about Lucy- the fact is that all 
 Apache committers have commit to Lucy.  Putting them all on the pmc would be 
 nuts in an entirely different way!
 Sent from my iPhone
 
 On Dec 19, 2012, at 11:50 AM, Mattmann, Chris A (388J) 
 chris.a.mattm...@jpl.nasa.gov wrote:
 
 Is it a fight to state an opinion, when one has already been stated,
 Marvin? C'mon now.
 Fair's fair, you already got yours out so I have every right to get mine
 out.
 
 To your point of we shouldn't legislate this across all podlings/projects,
 +1 to that.
 
 To your point of ending this useless thread, +1 to that.
 
 Cheers,
 Chris
 
 On 12/19/12 8:38 AM, Marvin Humphrey mar...@rectangular.com wrote:
 
 On Wed, Dec 19, 2012 at 8:35 AM, Mattmann, Chris A (388J)
 chris.a.mattm...@jpl.nasa.gov wrote:
 I have always recommended PPMC==C on all of my podlings, and was taught
 about that flat organizational structure when I started to see the light
 at Apache.
 
 Argh, do we really have to have this knock-down drag-out fight again?
 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Re: PPMC versus commiter

[Joe Schaefer]

That's just RBD's signature boilerplate for a document he likely started.  Feel 
free to remove it if you think it detracts from the document.

Sent from my iPhone

On Dec 19, 2012, at 11:40 PM, Christian Grobmeier grobme...@gmail.com wrote:

 On Wed, Dec 19, 2012 at 11:43 PM, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
 Ross Gardler wrote on Wed, Dec 19, 2012 at 22:13:17 +:
 Christian, you can review any podling I'm a mentor on, including AOO, to
 see discussion of both models. I'm sure many other projects have discussed
 this too.
 
 The page you refer to is correct, there are two separate roles as
 recognised by the foundation.
 
 You do have a point that things can be documented more clearly, they always
 can be, but I don't think the how it works page is at fault. That page
 doesn't describe how someone gets those roles, it merely defines the roles
 the foundation recognises.
 
 http://www.apache.org/foundation/governance/pmcs#merit describes both
 modes of operation.
 
 Didn't know about that document, but its good.
 
 Unfortunately: This document is a DRAFT and should not be considered
 as a normative or detailed explanation at the current time.
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Re: PPMC versus commiter

[Joe Schaefer]

Shane actually wrote that page but I still hate the exclusionary draft label he 
picked up from rbd.

Sent from my iPhone

On Dec 19, 2012, at 11:52 PM, Joe Schaefer joe_schae...@yahoo.com wrote:

 That's the whole problem with Robert's labels, they scare people away from 
 working on the document while simultaneously pretend that there is some 
 supercommittee who will determine when one of his drafts is no longer a draft.
 
 Sent from my iPhone
 
 On Dec 19, 2012, at 11:47 PM, Christian Grobmeier grobme...@gmail.com wrote:
 
 On Thu, Dec 20, 2012 at 5:44 AM, Joe Schaefer joe_schae...@yahoo.com wrote:
 That's just RBD's signature boilerplate for a document he likely started.  
 Feel free to remove it if you think it detracts from the document.
 
 
 I leave the labeling of a document to the people who worked on it
 
 
 Sent from my iPhone
 
 On Dec 19, 2012, at 11:40 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 
 On Wed, Dec 19, 2012 at 11:43 PM, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
 Ross Gardler wrote on Wed, Dec 19, 2012 at 22:13:17 +:
 Christian, you can review any podling I'm a mentor on, including AOO, to
 see discussion of both models. I'm sure many other projects have 
 discussed
 this too.
 
 The page you refer to is correct, there are two separate roles as
 recognised by the foundation.
 
 You do have a point that things can be documented more clearly, they 
 always
 can be, but I don't think the how it works page is at fault. That page
 doesn't describe how someone gets those roles, it merely defines the 
 roles
 the foundation recognises.
 
 http://www.apache.org/foundation/governance/pmcs#merit describes both
 modes of operation.
 
 Didn't know about that document, but its good.
 
 Unfortunately: This document is a DRAFT and should not be considered
 as a normative or detailed explanation at the current time.
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 
 --
 http://www.grobmeier.de
 https://www.timeandbill.de
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

How to use an apache webpage

[Joe Schaefer]

All webpages we host are works in progress subject to change when better 
consensus emerges.  Please do not affix any labels to the pages describing them 
as drafts as that only serves to discourage others from working on them.  
Normative policy documents are few and far between and you will recognize them 
by their self-descriptions as such.

Every interested party is welcome to collaborate with us to produce more 
informative and accurate webpages through the CMS.  Please help out where you 
can.  Our documentation becomes increasingly authoritative as more and more 
people refer to it in positive ways; ie the best documents wear well over time.

HTH
Sent from my iPhone

On Dec 20, 2012, at 12:07 AM, Joe Schaefer joe_schae...@yahoo.com wrote:

 Shane actually wrote that page but I still hate the exclusionary draft label 
 he picked up from rbd.
 
 Sent from my iPhone
 
 On Dec 19, 2012, at 11:52 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 
 That's the whole problem with Robert's labels, they scare people away from 
 working on the document while simultaneously pretend that there is some 
 supercommittee who will determine when one of his drafts is no longer a 
 draft.
 
 Sent from my iPhone
 
 On Dec 19, 2012, at 11:47 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 
 On Thu, Dec 20, 2012 at 5:44 AM, Joe Schaefer joe_schae...@yahoo.com 
 wrote:
 That's just RBD's signature boilerplate for a document he likely started.  
 Feel free to remove it if you think it detracts from the document.
 
 
 I leave the labeling of a document to the people who worked on it
 
 
 Sent from my iPhone
 
 On Dec 19, 2012, at 11:40 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 
 On Wed, Dec 19, 2012 at 11:43 PM, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
 Ross Gardler wrote on Wed, Dec 19, 2012 at 22:13:17 +:
 Christian, you can review any podling I'm a mentor on, including AOO, to
 see discussion of both models. I'm sure many other projects have 
 discussed
 this too.
 
 The page you refer to is correct, there are two separate roles as
 recognised by the foundation.
 
 You do have a point that things can be documented more clearly, they 
 always
 can be, but I don't think the how it works page is at fault. That page
 doesn't describe how someone gets those roles, it merely defines the 
 roles
 the foundation recognises.
 
 http://www.apache.org/foundation/governance/pmcs#merit describes both
 modes of operation.
 
 Didn't know about that document, but its good.
 
 Unfortunately: This document is a DRAFT and should not be considered
 as a normative or detailed explanation at the current time.
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 
 --
 http://www.grobmeier.de
 https://www.timeandbill.de
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Re: Incubator report reminders sent for Dec 2012

[Joe Schaefer]

The hdt-dev@ list is the wrong address, which
explains why the others are missing: reminders.pl
is not expecting the new mailing list pattern.






 From: David Crossley cross...@apache.org
To: general@incubator.apache.org 
Sent: Sunday, December 9, 2012 4:54 PM
Subject: Re: Incubator report reminders sent for Dec 2012
 
I do not know what is happening. Marvin seems to have an old list.

The list is here:
http://incubator.apache.org/report_due_3.txt
and does correctly have Onami, Ripple, and Streams.

Oh well, just reminders, everyone should know.

-David

Marvin wrote to private@i.a.o:
 
 The next board meeting is scheduled for Wed, 19 December 2012, 10:00:00 PST.
 
 I have just sent reminder emails to the below addresses, requesting them
 to supply board reports 2 weeks before the above date (Wed, Dec 5th).
 
 Please recall that the Incubator report is due Wed, Dec 12th.
 
     Allura Developers    allura-...@incubator.apache.org
     Bloodhound Developers    bloodhound-...@incubator.apache.org
     cTAKES Developers    ctakes-...@incubator.apache.org
     Drill Developers    drill-...@incubator.apache.org
     Etch Developers    etch-...@incubator.apache.org
     Flex Developers    flex-...@incubator.apache.org
     Hadoop Development Tools Developers    hdt-...@incubator.apache.org
     HCatalog Developers    hcatalog-...@incubator.apache.org
     Kalumet Developers    kalumet-...@incubator.apache.org
     Openmeetings Developers    openmeetings-...@incubator.apache.org
     S4 Developers    s4-...@incubator.apache.org
     Wave Developers    wave-...@incubator.apache.org
 
 -

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

Re: Incubator report reminders sent for Dec 2012

[Joe Schaefer]

Well it seems simple enough- I get a bounce
whenever I run the reminders script.  Clearly
the address listed on the rotation url must be wrong,
otherwise reminders wouldn't produce a bounce.






 From: David Crossley cross...@apache.org
To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com 
Sent: Sunday, December 9, 2012 6:31 PM
Subject: Re: Incubator report reminders sent for Dec 2012
 
Joe Schaefer wrote:
 The hdt-dev@ list is the wrong address, which
 explains why the others are missing: reminders.pl
 is not expecting the new mailing list pattern.

Thanks for updating marvin reminders.pl to handle the
new incubator pattern.

The hdt thing is something different. The recent tweaks
to Clutch need to also cope with them having a name which is
different to their project name.

-David

 
  From: David Crossley
  
 I do not know what is happening. Marvin seems to have an old list.
 
 The list is here:
 http://incubator.apache.org/report_due_3.txt
 and does correctly have Onami, Ripple, and Streams.
 
 Oh well, just reminders, everyone should know.
 
 -David
 
 Marvin wrote to private@i.a.o:
  
  The next board meeting is scheduled for Wed, 19 December 2012, 10:00:00 
  PST.
  
  I have just sent reminder emails to the below addresses, requesting them
  to supply board reports 2 weeks before the above date (Wed, Dec 5th).
  
  Please recall that the Incubator report is due Wed, Dec 12th.
  
      Allura Developers    allura-...@incubator.apache.org
      Bloodhound Developers    bloodhound-...@incubator.apache.org
      cTAKES Developers    ctakes-...@incubator.apache.org
      Drill Developers    drill-...@incubator.apache.org
      Etch Developers    etch-...@incubator.apache.org
      Flex Developers    flex-...@incubator.apache.org
      Hadoop Development Tools Developers    hdt-...@incubator.apache.org
      HCatalog Developers    hcatalog-...@incubator.apache.org
      Kalumet Developers    kalumet-...@incubator.apache.org
      Openmeetings Developers    openmeetings-...@incubator.apache.org
      S4 Developers    s4-...@incubator.apache.org
      Wave Developers    wave-...@incubator.apache.org
  
  -

Re: [DISCUSS] Apache Mayhem proposal

[Joe Schaefer]

No no no.  It's migrating from git to svn that
we don't know how to do, going the other way
is largely trivial with git-svn.






 From: Christian Grobmeier grobme...@gmail.com
To: general@incubator.apache.org general@incubator.apache.org 
Sent: Thursday, November 1, 2012 3:48 PM
Subject: Re: [DISCUSS] Apache Mayhem proposal
 
Cool.

Personally I have not the competence to do anything with git except using
it (referencing to Craigs mail).
Now... how did you do the history transition from svn to git?

Cheers


On Thu, Nov 1, 2012 at 8:24 PM, Jarek Jarcec Cecho jar...@apache.orgwrote:

 I've been participating in three different projects that were moving from
 SVN to git (flume, sqoop, mrunit) and we did not experienced any issues
 with that process.

 Jarcec

 On Thu, Nov 01, 2012 at 12:09:43PM -0700, Craig L Russell wrote:
 
  On Nov 1, 2012, at 11:59 AM, Christian Grobmeier wrote:
 
  Hello,
  
  I would prefer GIT, even when I am not a GIT guru. The reason is
  simple:
  there is no way to save history when moving from git to svn. At
  least two
  or three incubating projects had to fight with that recently
  (Wave, Cordova
  i think). Somebody from the Apache committers started an effort to
  make a
  migration tool but its not finished to my knowledge.
  
  That said, I welcome the opportunity to work with git in a big
  team. And I
  would not like to loose history.
  
  Not sure about the entry criteria for the GIT experiment right
  now, but I
  think it should be pretty stable - lets ask infra?
 
  From what I've seen, the entry criteria are a team that wants to use
  git, and most important:
 
  volunteers from the team to work actively with infra to manage the
  git repository.
 
  Craig
  
  Cheers
  Christian
  
  
  On Thu, Nov 1, 2012 at 1:04 PM, Simone Tripodi
  simonetrip...@apache.orgwrote:
  
  Hi Mohammad,
  
  what about having SVN+Git mirror? I personally just need a SCM, don't
  have a strong preference, so recommendations are more than welcome!
  What do you suggest?
  
  Many thanks in advance, all the best!
  -Simo
  
  http://people.apache.org/~simonetripodi/
  http://simonetripodi.livejournal.com/
  http://twitter.com/simonetripodi
  http://www.99soft.org/
  
  
  On Thu, Nov 1, 2012 at 11:11 AM, Mohammad Nour El-Din
  nour.moham...@gmail.com wrote:
  Hi
  
   I noticed that the code is hosted on github but u r asking
  for an svn
  rep
  while we can have a git repo, or u don't want to continue
  using git ?
  
  Sent from my Samsung Galaxy S3
  Apologies for any typos
  On Nov 1, 2012 11:59 AM, Mohammad Nour El-Din 
 nour.moham...@gmail.com
  
  wrote:
  
  Hi Simone
  
    I like the idea pretty much and I would like to be a
  mentor of this
  project. But I can't edit the wiki page at the moment would u
  please add
  me
  :)
  Thanks for bringing the project to ASF
  
  Sent from my Samsung Galaxy S3
  Apologies for any typos
  
  On Nov 1, 2012 10:30 AM, Eric Charles e...@apache.org wrote:
  
  I was waiting this since a long time, especially since
  guiceyfruit is
  not officially update to guice3.
  
  It's great time to do this, as more well-known 3rd parties provide
  their own extensions [1]. With such a good code base coming
  from 99soft
  foundation, we will be good on track.
  
  Big +1 and thx again,
  
  Eric
  
  [1]
  
  
 http://techblog.netflix.com/2012/10/governator-lifecycle-and-dependency.html
  
  
  On 31/10/2012 22:16, Christian Grobmeier wrote:
  
  I like that proposal (you have guessed it as I signed up
  to mentor).
  Guice is something cool as I found out recently. And I
  really like
  the
  logging component in there (surprise)
  
  
  On Wed, Oct 31, 2012 at 8:55 PM, Donald Whytock
  dwhyt...@gmail.com
  wrote:
  
  Just giving a post-hurricane nudge.
  
  On Tue, Oct 30, 2012 at 11:49 AM, Simone Tripodi
  simonetrip...@apache.org wrote:
  
  Hi all guys,
  
  I prepared a new proposal[1] for the incubator, concerning the
  creation of a new community focused on all aspects
  of Google Guice
  extensions, starting from a rather than small
  codebase that I and
  other friends - already ASF committers/members - would like to
  donate
  to the ASF.
  
  We still need at least one mentor, is there any
  volunteer available
  on
  joining to provide help on bringing that new community up?
  
  Many thanks in advance, all the best!!!
  -Simo
  
  [1] http://wiki.apache.org/incubator/MayhemProposal
  
  http://people.apache.org/~simonetripodi/
  http://simonetripodi.livejournal.com/
  http://twitter.com/simonetripodi
  http://www.99soft.org/
  
  
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail:
 general-h...@incubator.apache.org
  
  
  
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional 

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Joe Schaefer]

+1





 From: Andrea Pescetti pesce...@apache.org
To: general@incubator.apache.org 
Sent: Wednesday, October 10, 2012 3:00 PM
Subject: [VOTE] Recommend to the Board to establish the Apache OpenOffice 
Project
 
Seeing no objections to my last message, and keeping into account that this 
list had been regularly informed about the steps Apache OpenOffice was taking 
towards graduation, I'm hereby asking the IPMC to recommend the following 
resolution to the Board. Aim of the resolution is to establish the Apache 
OpenOffice Project as a Top Level Project.

Please cast your vote:

[ ] +1, recommend the resolution to the Board
[ ] +0, abstain/don't care
[ ] -1, do not recommend the resolution to the Board, because...

This vote will be open for 72 hours from now; only votes from the Incubator 
PMC are binding.

Resolution text:
  ---
WHEREAS, the Board of Directors deems it to be in the best interests of the 
Foundation and consistent with the Foundation's purpose to establish a Project 
Management Committee charged with the creation and maintenance of open-source 
software related to the OpenOffice personal productivity applications, for 
distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to 
be known as the Apache OpenOffice Project, be and hereby is established 
pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache OpenOffice Project be and hereby is responsible for 
the creation and maintenance of software related to the OpenOffice personal 
productivity applications; and be it further

RESOLVED, that the office of Vice President, OpenOffice be and hereby is 
created, the person holding such office to serve at the direction of the Board 
of Directors as the chair of the Apache OpenOffice Project, and to have 
primary responsibility for management of the projects within the scope of 
responsibility of the Apache OpenOffice Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are 
appointed to serve as the initial members of the Apache OpenOffice Project:

    * Andre Fischer (af)
    * Andrea Pescetti (pescetti)
    * Andrew Rist (arist)
    * Ariel Constenla-Haile (arielch)
    * Armin Le Grand (alg)
    * Dave Fisher (wave)
    * Donald Harbison (dpharbison)
    * Drew Jensen (atjensen)
    * Ian Lynch (ingotian)
    * Jürgen Schmidt (jsc)
    * Kay Schenk (kschenk)
    * Kazunari Hirano (khirano)
    * Louis Suarez-Potts (louis)
    * Marcus Lange (marcus)
    * Oliver-Rainer Wittmann (orw)
    * Pedro Giffuni (pfg)
    * Peter Junge (pj)
    * Raphael Bircher (rbircher)
    * Regina Henschel (regina)
    * RGB.ES (rgb-es)
    * Roberto Galoppini (galoppini)
    * Yang Shih-Ching (imacat)
    * Yong Lin Ma (mayongl)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed to 
the office of Vice President, OpenOffice, to serve in accordance with and 
subject to the direction of the Board of Directors and the Bylaws of the 
Foundation until death, resignation, retirement, removal or disqualification, 
or until a successor is appointed; and be it further

RESOLVED, that the initial Apache OpenOffice Project be and hereby is tasked 
with the creation of a set of bylaws intended to encourage open development 
and increased participation in the OpenOffice Project; and be it further

RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with the 
migration and rationalization of the Apache OpenOffice.org podling; and be it 
further

RESOLVED, that all responsibilities pertaining to the Apache Incubator 
OpenOffice.org podling encumbered upon the Apache Incubator Project are 
hereafter discharged.
  ---
Best regards,
  Andrea Pescetti - Apache OpenOffice PPMC.

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

Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC

[Joe Schaefer]

No, just like Upayavira doesn't.






 From: Benson Margulies bimargul...@gmail.com
To: general@incubator.apache.org 
Sent: Monday, October 1, 2012 8:00 PM
Subject: Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 
On Mon, Oct 1, 2012 at 7:58 PM, Dave Fisher dave2w...@comcast.net wrote:
 FYI - This is being done in public!


Who or what is an RGB.ES? Don't PMC members have to disclose an identity?

 Regards,
 Dave

 Begin forwarded message:

 From: Andrew Rist andrew.r...@oracle.com
 Date: October 1, 2012 3:38:03 PM PDT
 To: ooo-...@incubator.apache.org
 Subject: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 Reply-To: ooo-...@incubator.apache.org
 delivered-to: mailing list ooo-...@incubator.apache.org

 This is a call for vote on selecting the following list as the starting 
 membership for the Apache OpenOffice PMC, to be listed in the TLP 
 resolution.  The voting is for the entire slate as listed.

   Apache OpenOffice PMC Starting Membership:
       Andre Fischer (af)
       Andrea Pescetti (pescetti)
       Andrew Rist (arist)
       Ariel Constenla-Haile (arielch)
       Armin Le Grand (alg)
       Dave Fisher (wave)
       Donald Harbison (dpharbison)
       Drew Jensen (atjensen)
       Ian Lynch (ingotian)
       Jürgen Schmidt (jsc)
       Kay Schenk (kschenk)
       Kazunari Hirano (khirano)
       Louis Suarez-Potts (louis)
       Marcus Lange (marcus)
       Oliver-Rainer Wittmann (orw)
       Pedro Giffuni (pfg)
       Peter Junge (pj)
       Raphael Bircher (rbircher)
       Regina Henschel (regina)
       RGB.ES (rgb-es)
       Roberto Galoppini (galoppini)
       Yang Shih-Ching (imacat)
       Yong Lin Ma (mayongl)


 The balloting will be until UTC midnight Thursday,
   4 October: 2012-10-04T24:00Z.

   Approval requires a majority of +1 over -1 votes cast by members of the 
PPMC.

    [  ] +1 approve
    [  ]  0 abstain
    [  ] -1 disapprove, for the following reasons:


   The [DISCUSS] for this vote was enthusiastically in favor. There were no 
concerns expressed other than issues with the timeframe of discussions, 
which were suitably extended.  (note: All members of this list, except for 
Drew and Raphael, accepted their nomination to this list.  I have left Drew 
and Raphael on the list as neither declined, and they still have the ability 
to decline later)





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


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

Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC

[Joe Schaefer]

Relax, we aren't that dumb as an org to accept
signatures from fictitious entities.  The board
knows everyone's identity, and ultimately they
are the ones who ratify these PMC rosters.






 From: Ian Boston i...@tfd.co.uk
To: general@incubator.apache.org 
Sent: Monday, October 1, 2012 8:33 PM
Subject: Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 
Upayavira is not a good example of anonymity, as he is not.

I think his name is sometimes prefixed by Dh and he is quite open
about his identity. [1],[2],[3]

I trust the Foundation knows the true identity of rgb-es. IIRC, any
legal document signed by an incognito is not binding, and we should
have have all signed CLA's as individuals.


Ian


1 http://www.flickr.com/search/?q=upayaviraw=alls=intreferer_searched=1
2 http://wiki.apache.org/cocoon/Upayavira
3 http://www.linkedin.com/pub/dh-upayavira/1b/5a3/7a6



On 2 October 2012 10:13, Benson Margulies bimargul...@gmail.com wrote:
 On Mon, Oct 1, 2012 at 8:07 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 No, just like Upayavira doesn't.

 Oh, I thought he was just a person-of-single-name, like a number of
 people I've met (often from Indonesia).










 From: Benson Margulies bimargul...@gmail.com
To: general@incubator.apache.org
Sent: Monday, October 1, 2012 8:00 PM
Subject: Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC

On Mon, Oct 1, 2012 at 7:58 PM, Dave Fisher dave2w...@comcast.net wrote:
 FYI - This is being done in public!


Who or what is an RGB.ES? Don't PMC members have to disclose an identity?

 Regards,
 Dave

 Begin forwarded message:

 From: Andrew Rist andrew.r...@oracle.com
 Date: October 1, 2012 3:38:03 PM PDT
 To: ooo-...@incubator.apache.org
 Subject: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 Reply-To: ooo-...@incubator.apache.org
 delivered-to: mailing list ooo-...@incubator.apache.org

 This is a call for vote on selecting the following list as the starting 
 membership for the Apache OpenOffice PMC, to be listed in the TLP 
 resolution.  The voting is for the entire slate as listed.

   Apache OpenOffice PMC Starting Membership:
       Andre Fischer (af)
       Andrea Pescetti (pescetti)
       Andrew Rist (arist)
       Ariel Constenla-Haile (arielch)
       Armin Le Grand (alg)
       Dave Fisher (wave)
       Donald Harbison (dpharbison)
       Drew Jensen (atjensen)
       Ian Lynch (ingotian)
       Jürgen Schmidt (jsc)
       Kay Schenk (kschenk)
       Kazunari Hirano (khirano)
       Louis Suarez-Potts (louis)
       Marcus Lange (marcus)
       Oliver-Rainer Wittmann (orw)
       Pedro Giffuni (pfg)
       Peter Junge (pj)
       Raphael Bircher (rbircher)
       Regina Henschel (regina)
       RGB.ES (rgb-es)
       Roberto Galoppini (galoppini)
       Yang Shih-Ching (imacat)
       Yong Lin Ma (mayongl)


 The balloting will be until UTC midnight Thursday,
   4 October: 2012-10-04T24:00Z.

   Approval requires a majority of +1 over -1 votes cast by members of 
the PPMC.

    [  ] +1 approve
    [  ]  0 abstain
    [  ] -1 disapprove, for the following reasons:


   The [DISCUSS] for this vote was enthusiastically in favor. There were 
no concerns expressed other than issues with the timeframe of 
discussions, which were suitably extended.  (note: All members of this 
list, except for Drew and Raphael, accepted their nomination to this 
list.  I have left Drew and Raphael on the list as neither declined, and 
they still have the ability to decline later)





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


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





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


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

Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC

[Joe Schaefer]

iclas.txt contains the full record of every processed
ICLA at Apache and it is available to every member of
the org.  Traditionally it is expected of the membership
to keep the details of that file confidential, and
to date I'm not aware of a single exception.






 From: Ian Holsman i...@holsman.com.au
To: general@incubator.apache.org 
Sent: Monday, October 1, 2012 9:06 PM
Subject: Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 
Another example was from early apache httpd days where a person used a 
pseudonym.
People (not me, I can't even remember his handle) knew who he was, but it was 
never made public.

regards
Ian

On Oct 2, 2012, at 10:33 AM, Ian Boston i...@tfd.co.uk wrote:

 Upayavira is not a good example of anonymity, as he is not.
 
 I think his name is sometimes prefixed by Dh and he is quite open
 about his identity. [1],[2],[3]
 
 I trust the Foundation knows the true identity of rgb-es. IIRC, any
 legal document signed by an incognito is not binding, and we should
 have have all signed CLA's as individuals.
 
 
 Ian
 
 
 1 http://www.flickr.com/search/?q=upayaviraw=alls=intreferer_searched=1
 2 http://wiki.apache.org/cocoon/Upayavira
 3 http://www.linkedin.com/pub/dh-upayavira/1b/5a3/7a6
 
 
 
 On 2 October 2012 10:13, Benson Margulies bimargul...@gmail.com wrote:
 On Mon, Oct 1, 2012 at 8:07 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 No, just like Upayavira doesn't.
 
 Oh, I thought he was just a person-of-single-name, like a number of
 people I've met (often from Indonesia).
 
 
 
 
 
 
 
 
 
 
 From: Benson Margulies bimargul...@gmail.com
 To: general@incubator.apache.org
 Sent: Monday, October 1, 2012 8:00 PM
 Subject: Re: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 
 On Mon, Oct 1, 2012 at 7:58 PM, Dave Fisher dave2w...@comcast.net wrote:
 FYI - This is being done in public!
 
 
 Who or what is an RGB.ES? Don't PMC members have to disclose an identity?
 
 Regards,
 Dave
 
 Begin forwarded message:
 
 From: Andrew Rist andrew.r...@oracle.com
 Date: October 1, 2012 3:38:03 PM PDT
 To: ooo-...@incubator.apache.org
 Subject: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 Reply-To: ooo-...@incubator.apache.org
 delivered-to: mailing list ooo-...@incubator.apache.org
 
 This is a call for vote on selecting the following list as the starting 
 membership for the Apache OpenOffice PMC, to be listed in the TLP 
 resolution.  The voting is for the entire slate as listed.
 
  Apache OpenOffice PMC Starting Membership:
      Andre Fischer (af)
      Andrea Pescetti (pescetti)
      Andrew Rist (arist)
      Ariel Constenla-Haile (arielch)
      Armin Le Grand (alg)
      Dave Fisher (wave)
      Donald Harbison (dpharbison)
      Drew Jensen (atjensen)
      Ian Lynch (ingotian)
      Jürgen Schmidt (jsc)
      Kay Schenk (kschenk)
      Kazunari Hirano (khirano)
      Louis Suarez-Potts (louis)
      Marcus Lange (marcus)
      Oliver-Rainer Wittmann (orw)
      Pedro Giffuni (pfg)
      Peter Junge (pj)
      Raphael Bircher (rbircher)
      Regina Henschel (regina)
      RGB.ES (rgb-es)
      Roberto Galoppini (galoppini)
      Yang Shih-Ching (imacat)
      Yong Lin Ma (mayongl)
 
 
 The balloting will be until UTC midnight Thursday,
  4 October: 2012-10-04T24:00Z.
 
  Approval requires a majority of +1 over -1 votes cast by members of 
the PPMC.
 
   [  ] +1 approve
   [  ]  0 abstain
   [  ] -1 disapprove, for the following reasons:
 
 
  The [DISCUSS] for this vote was enthusiastically in favor. There were 
no concerns expressed other than issues with the timeframe of 
discussions, which were suitably extended.  (note: All members of this 
list, except for Drew and Raphael, accepted their nomination to this 
list.  I have left Drew and Raphael on the list as neither declined, and 
they still have the ability to decline later)
 
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

--
Ian Holsman
i...@holsman.com.au
http://doitwithdata.com.au
PH: +61-400-988-964 Skype:iholsman



-
To unsubscribe, e-mail: general-unsubscr

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

- Original Message -

 From: Benson Margulies bimargul...@gmail.com
 To: general@incubator.apache.org
 Cc: 
 Sent: Monday, August 27, 2012 9:16 AM
 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 
 Jim,
 
 Two points:
 
 1: you skip over the liability question. Is Bill legally exposed?

Short answer: yes he assumes some liability for those httpd windows builds,
but it is probably limited to any negligence on his part in ensuring the
build environment was properly secured.  Going forward if the org wants
to produce such production-quality builds itself it will need to invest in
an audits produced by an Intrusion Detection System on such build hosts,
and we'll need to have an auditable means of controlling 3rd party software
involved in the builds (think maven repo, CPAN, etc).  It's a serious
change from the level of paranoia currently deployed in our existing build
farms.

HTH

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

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

Which better agrees with written policy anyway- the sigs
are part of the release package to be voted on and voted on
by the PMC, so even tho it constitutes individual sigs
those sigs (well at least the RM's sig) are PMC-approved.




- Original Message -
 From: Greg Stein gst...@gmail.com
 To: general@incubator.apache.org
 Cc: ooo-...@incubator.apache.org ooo-...@incubator.apache.org
 Sent: Monday, August 27, 2012 1:03 PM
 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 
 On Aug 27, 2012 9:57 AM, Jim Jagielski j...@jagunet.com 
 wrote:
 ...
  But recall in all this that even when the PMC releases code, it is
  signed by the individual RM, and not by the PMC itself.
 
 Apache Subversion releases tend to have a half-dozen signatures. Thus, I'd
 say they are signed by the PMC. For example:
 
 https://dist.apache.org/repos/dist/release/subversion/subversion-1.7.6.tar.bz2.asc
 
 Cheers,
 -g
 

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

Re: downloading external dependencies outside of svn.apache.org

[Joe Schaefer]

Many projects in a similar situation ship a deps
package that contains dependencies and distribute
those from the mirrors.

HTH






 From: Juan Pablo Santos Rodríguez juanpa...@apache.org
To: general@incubator.apache.org 
Sent: Monday, August 27, 2012 2:42 PM
Subject: downloading external dependencies outside of svn.apache.org
 
Hello,

As a part of JSPWiki's July 2012 incubator report [#1], it was noted that
JSPWiki (incubating) should not ship external jars alongside with code.
This has been achieved in current trunk. However, as part of AOO community
graduation vote thread [#2] it was noted that:

 If you try to build from source the build system will download packages
from svn.apache.org instead of from elsewhere or the mirrors.  That
violates infra policy.

Which is exactly what is happening to us: we download jars from Central as
much as possible but, as there are a few of them ([#3], [#4]) which are not
published in Central, we download them from svn.apache.org. These jar are
all AL compatible so, the questions are:

- where can we place them in order to not violate infra policy?
- could this be a -1 towards voting a release? how to proceed?


thx  regards,
juan pablo

[#1] http://s.apache.org/zsq
[#2] http://s.apache.org/8Gk
[#3] http://svn.apache.org/repos/asf/incubator/jspwiki/libs/lib/
[#4] http://svn.apache.org/repos/asf/incubator/jspwiki/libs/tests/lib/

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

No.  There is NO WAY IN HELL the org can indemnify
a volunteer who produces a binary build themselves.

Please don't bother asking legal-discuss to tackle this.

The way liability works in an incorporated volunteer
charity is that you are not liable for club activities
performed without negligence on your part.  IANAL but
this is the whole point of the law surrounding this
area of human activity in the US.

Building software on 3rd party hosts which are not
operated by the org exposes you to the possibility
that your system may be compromised beyond what
is in source, and should you publish those artifacts
to ASF mirrors you could be held liable for any damages
your inattentiveness towards the system that produced
those packages may have caused.  Nothing the org can
do other than adopt an insane indemnity policy will
absolve a volunteer of that personal risk at this point.
However, if the org decides on a method of producing
production-quality builds itself and signs off on them itself
as an org, then clearly only the ASF, and any malicious or negligent
party, is exposed to any risks associated with widescale distribution.


If the software is built by an ASF host using ASF-maintained
software,  you might be able to make the case before a judge
that is was the ASF's fault for producing vulnerable builds
on a compromised host.  But you will have to plead that
before a judge at this point should you be named in a suit,
because we don't currently offer that level of management
in our build farms.


HTH

 From: Marvin Humphrey mar...@rectangular.com
To: general@incubator.apache.org 
Sent: Sunday, August 26, 2012 10:09 AM
Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 
On Sun, Aug 26, 2012 at 4:26 AM, Branko Čibej br...@apache.org wrote:
 On 26.08.2012 13:15, Tim Williams wrote:
 Marvin gave the link earlier in this thread. 4th para is the relevant bit.

 http://www.apache.org/dev/release.html#what

 The relevant part is in the last paragraph. However, that says
 convenience and defines version numbering requirements, but it does
 /not/ state that the binaries are not sanctioned by the ASF and are not
 part of the official ASF release.

 It would be very useful if that paragraph were amended to say so
 explicitly. I've had no end of trouble trying to explain to managers and
 customers that any binaries that come from the ASF are not official.
 Regardless of the policy stated numerous times in this thread and on
 this list, this is not clear anywhere in the bylaws or other online
 documentation (that I can find).

The possibility exists that when the question is put to legal-discuss, we will
find that Roy's missives have been misinterpreted, and that so long as the
imperative of a clean source release (uncontaminated by e.g. embedded jar
files) is satisfied, it is permissible for a PMC to sanction accompanying
binary artifacts which are wholly derived from said clean source.

It is also possible that the V.P. of Legal (who is a Board member) will kick
the question up to the Board and that they will take up a full-blown
resolution clarifying the policy.  Perhaps they will impose restrictions going
forward such as the requirement that binaries to be blessed must be created
via automatic processes kicked off by Infra on sterile build machines.  Or
perhaps there won't be a resolution, but the discussion will produce a new
common understanding that PMCs have so much autonomy they can release a
peanut butter and jelly sandwich alongside the source code as an act of the
corporation.

And yet another possibility is that the Legal VP will issue a narrowly
tailored rulying stating that AOO may release blessed binaries while
incubating, but that after graduation only binaries produced on sterile build
machines may be blessed.

Who knows?  We aren't going to resolve these questions on this list.

In any case, I do not believe that it is in the best interests of either the
ASF or the AOO podling (particularly those contributing towards the binary
artifacts) for ambiguity to persist around issues of indemnification, and I
don't think it's good for the ASF to walk backwards into a policy on binary
releases accidentally.

Apologies for keeping the zombie thread alive.  If it were up to me, it would
have hopped forums some time ago.

Marvin Humphrey

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





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

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

The point most people seem to make out of sanctioned
or official builds revolves around indemnifying volunteers
involved in the production of the release.


I'm tired of rehashing release.html for the umpteenth time
simply because Brane or you or some other newb lacks the
experience to know the context behind the document, but
as they say patches welcome (on site-...@apache.org).  Every
committer can alter the wording on that page and do something
more productive than make clueless arguments on this
ever devolving thread.


AOO is mentored by some of the most experienced people in the org,
please just ignore any further chaff from this thread and pay attention
to the guidance you have been repeatedly given on this issue.
AOO doesn't need to change anything to their current release processes
other than to stop pointing source downloads at svn (which is the sole
reason I won't vote for AOO candidates).




- Original Message -
 From: Rob Weir robw...@apache.org
 To: general@incubator.apache.org
 Cc: 
 Sent: Sunday, August 26, 2012 9:54 AM
 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 
 On Sun, Aug 26, 2012 at 7:26 AM, Branko Čibej br...@apache.org wrote:
  On 26.08.2012 13:15, Tim Williams wrote:
  Marvin gave the link earlier in this thread. 4th para is the relevant 
 bit.
 
  http://www.apache.org/dev/release.html#what
 
  The relevant part is in the last paragraph. However, that says
  convenience and defines version numbering requirements, but it 
 does
  /not/ state that the binaries are not sanctioned by the ASF and are not
  part of the official ASF release.
 
 
 And again, as I and others have stated, this is merely a label with no
 content to it.  What does sanctioned (or not sanctioned) by the ASF
 mean?  Anything specific?
 
 Remember, the binaries (or Object form in the words of the license)
 are also covered by the Apache License 2.0, and sections 7 and 8 of
 that license already say that it is provided as-is, and disclaims
 warranty and liability.
 
 In other words, the same license and the same disclaimers apply to
 source (which we seem to agree is part of the ASF release) and to
 binaries.
 
 So again I urge the IPMC to mind the seductive appeal of mere labeling
 and instead consider whether there is any actual constraints on
 activities and behavior for Podlings (or TLP's for that matter) based
 on whether something is a source or binary, e.g.:
 
 1) Is there some required (or forbidden) way in which a distinction
 must be acknowledged in a release vote?
 
 2) Is there some required (or forbidden) language on the download webpage?
 
 3) Any required (or forbidden) language on release announcements?
 
 4) Is there some required (or forbidden) constraint with distribution?
 
 So far I have heard some on this list suggest the AOO podling is doing
 something incorrect, something against ASF policy.  But dispute
 repeated queries, no one has stated what exactly this is.  This is
 extremely unfair to the podling, to any podling.  It denies us the
 opportunity of addressing issues.  Is this really how the IPMC
 operates?  It reminds me of tactics practiced by Microsoft against
 open source -- intimate that something is wrong, but never offer
 specifics.  We call it FUD there.  What do we call it at the ASF?
 
  It would be very useful if that paragraph were amended to say so
  explicitly. I've had no end of trouble trying to explain to managers 
 and
  customers that any binaries that come from the ASF are not 
 official.
 
 That may be true for your users, but for mine they would just come
 back with, What does that mean in practice?
 
  Regardless of the policy stated numerous times in this thread and on
  this list, this is not clear anywhere in the bylaws or other online
  documentation (that I can find).
 
 
 I agree.
 
  -- Brane
 
  P.S.: I asked this same question on legal-discuss a week ago. My post
  has not even been moderated through as of today, so referring people to
  that list doesn't appear to be too helpful.
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

Waah Brane- obviously you're not as community-oriented
as you'd like to think.  release.html is the byproduct
of several years of writing oriented towards the lowest
common denominator of the org, but if you think you know
how to improve it you have all the requisite karma already.

All that's missing is a clue.





- Original Message -
 From: Branko Čibej br...@apache.org
 To: general@incubator.apache.org
 Cc: 
 Sent: Sunday, August 26, 2012 10:53 AM
 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 
 On 26.08.2012 16:46, Joe Schaefer wrote:
  The point most people seem to make out of sanctioned
  or official builds revolves around indemnifying volunteers
  involved in the production of the release.
 
 
  I'm tired of rehashing release.html for the umpteenth time
  simply because Brane or you or some other newb lacks the
  experience to know the context behind the document, but
  as they say patches welcome (on site-...@apache.org).  Every
  committer can alter the wording on that page and do something
  more productive than make clueless arguments on this
  ever devolving thread.
 
 That's very helpful, thanks. So if someone asks me about ASF releases
 and binaries I should refer them to the legal-discuss archives, or these
 general@ archives, or simply tell them to find a founding member to
 condescendingly explain the obvious. Because I sure can't give 'em a
 link to some page on our web site.
 
 I'll refrain from spelling out the epithets that come to mind.
 
 -- Brane
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

Better attitude, now all you need to do is subscribe to site-...@apache.org
and join the rest of the people who care about the content of our site
documentation.





- Original Message -
 From: Branko Čibej br...@apache.org
 To: general@incubator.apache.org
 Cc: 
 Sent: Sunday, August 26, 2012 11:13 AM
 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 
 On 26.08.2012 17:04, Joe Schaefer wrote:
  Waah Brane- obviously you're not as community-oriented
  as you'd like to think.  release.html is the byproduct
  of several years of writing oriented towards the lowest
  common denominator of the org, but if you think you know
  how to improve it you have all the requisite karma already.
 
  All that's missing is a clue.
 
 Joe, I know very well (and you know that I know) that I can edit most of
 the things that appear on our web site. But if community-oriented means
 that anyone should just edit those docs to scratch an itch and to hell
 with consensus and the consequences, then you're right, I'm definitely a
 misfit here.
 
 -- Brane
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

- Original Message -

 From: Dave Fisher dave2w...@comcast.net
 To: general@incubator.apache.org
 Cc: 
 Sent: Sunday, August 26, 2012 1:08 PM
 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 
 
 On Aug 26, 2012, at 7:46 AM, Joe Schaefer wrote:
 
  AOO doesn't need to change anything to their current release processes
  other than to stop pointing source downloads at svn (which is the sole
  reason I won't vote for AOO candidates).
 
 Well this is worth discussion.
 
 On this page [1]:
 
 The source downloads go through aoo-closer.cgi, but all of the hashes and 
 signatures go through www.a.o/dist/. Is that your issue?

No, but I'm tired of talking about it.  If you try to build from source
the build system will download packages from svn.apache.org instead of
from elsewhere or the mirrors.  That violates infra policy.

 
 Or is it this page [2]?
 
 Please help me understand what is wrong and it will be fixed.
 
 Best Regards,
 Dave
 
 [1] http://incubator.apache.org/openofficeorg/downloads.html
 [2] http://www.openoffice.org/download/other.html#tested-sdk
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Joe Schaefer]

Really, all this fuss over the LABELLING of
a file being distributed does not add value
to either the org, the podling, or the users
of the software.  Nowhere is it written that
you CANNOT DISTRIBUTE BINARIES, however it
has always been clear that they are provided
for the convenience of our users, not as part
of an official release.  That however does
not mean that things like release announcements
cannot refer users to those binaries, it simply
means those announcements need to reference the
sources as the thing that was formally voted on
and approved by the ASF.







 From: Dave Fisher dave2w...@comcast.net
To: general@incubator.apache.org 
Sent: Friday, August 24, 2012 1:56 PM
Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
 

On Aug 24, 2012, at 10:09 AM, Rob Weir wrote:

 On Fri, Aug 24, 2012 at 12:45 PM, Rob Weir robw...@apache.org wrote:
 On Fri, Aug 24, 2012 at 12:32 PM, Marvin Humphrey
 mar...@rectangular.com wrote:
 Returning to this topic after an intermission...
 
 On Tue, Aug 21, 2012 at 6:18 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 On Tue, Aug 21, 2012 at 11:54 AM, Jürgen Schmidt jogischm...@gmail.com 
 wrote:
 ...As one of the active developers I would have a serious problem if we 
 as
 project couldn't provide binary releases for our users. And I thought
 the ASF is a serious enough institution that can ensure to deliver
 binaries of these very popular end user oriented software and can of
 course protect the very valuable brand OpenOffice that the ASF now owns
 as well...
 
 As has been repeatedly mentioned in this thread and elsewhere, at the
 moment ASF releases consist of source code, not binaries.
 
 My impression from this discussion is that many podling contributors are
 dismayed by this policy, and that there is an element within the PPMC which
 remains convinced that it is actually up to individual PMCs within the ASF 
 to
 set policy as to whether binaries are official or not.
 
 
 If there actually is an ASF-wide Policy concerning binaries then I
 would expect that:
 
 1) It would come from the ASF Board, or from a Legal Affairs, not as
 individual opinions on the IPMC list
 
 2) It would be documented someplace, as other important ASF policies
 are documented
 
 
 And 2a)  Actually state the constraints of the policy, i.e., what is
 allowed or disallowed by the policy.  Merely inventing a label like
 convenience or unofficial gives absolutely zero direction to
 PMC's.  It is just a label.  Consider what the IPMC's Release Guide
 gives with regards to the source artifact.  It is labeled canonical,
 but that level is backed up with requirements, e.g., that every
 release must include it, that it must be signed, etc.  Similarly,
 podling releases are not merely labeled podling releases, but policy
 defines requirements, e.g., a disclaimer, a required IPMC vote, etc.
 
 I hope I am not being too pedantic here.  But I would like to have a
 policy defined here so any PMC can determine whether they are in
 compliance.  But so far I just hear strongly held opinions that amount
 to applying labels, but not mandating or forbidden any actions with
 regards to artifacts that bear these labels.
 
 Consider:  If some IPMC members declared loudly that It is ASF policy
 that binary artifacts are 'Umbabuga', what exactly would you expect a
 Podling to do, given that Umbabuga is an undefined term with no policy
 mandated or forbidden actions?
 
 There is a seductive appeal to reaching consensus on a label. But it
 avoids the hard part of policy development, the useful part:  reaching
 consensus on constraints to actions.

The AOO PPMC was asked to take this discussion along with digital signature 
issue to legal-discuss to get advice. Whether or not this becomes guidance for 
AOO or official foundation wide policy is ultimately up to the Board and the 
Membership.

Regards,
Dave


 
 
 3) That the policies is applied not only to AOO, but to other podlings
 and to TLP's as well.
 
 Until that happens, I hear only opinions.  But opinions, even widely
 held opinions, even Roy opinions, are not the same as policy.
 
 -Rob
 
 OTOH I don't think anybody said the ASF will never allow projects to
 distribute binaries - but people who want to do that need to get
 together (*) and come up with a proposal that's compatible with the
 ASF's goals and constraints, so that a clear policy can be set.
 
 I'm concerned that such an effort may not be completed, and that once the
 podling graduates, AOO binaries will once again be advertised as official,
 placing the project in conflict with ASF-wide policy.  It may be that some
 within the newly formed PMC will speak out in favor of the ASF status quo, 
 but
 as their position will likely be inexpedient and unpopular, it may be
 difficult to prevail.
 
 Of course I don't know how things will play out, but it seems to me that
 reactions from podling contributors have ranged from discouraged to