from:"myrle"

Thank you Bertrand!

Finding that would've saved me a bit of time and trouble.  Hopefully we've
made it easier on the next person!

Best,
Myrle

On Thu, Mar 21, 2019 at 3:08 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi Myrle,
>
> On Thu, Mar 21, 2019 at 11:39 AM Myrle Krantz  wrote:
> > ...I wanted to edit this page:
> > https://incubator.apache.org/guides/releasemanagement.html
>
> I have updated https://incubator.apache.org/guides/website.html
> (should be live in a few minutes) to remove redundant information and
> point to the README at https://github.com/apache/incubator which
> should provide all the required information.
>
> It includes a link to
> https://builds.apache.org/view/H-L/view/Incubator/job/Incubator%20Site/
> where you can follow the site builds.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Changes to Release Management documentation live, please review

Hey all,

Please check:
https://incubator.apache.org/guides/releasemanagement.html

Feedback (and patches : o) welcome.

Best Regards,
Myrle

Re: Learning to edit the incubator website

Disregard my previous email.  Apparently I already had it, and just needed
to be patient.  : o)

Thank you anyways!
Myrle

On Thu, Mar 21, 2019 at 11:39 AM Myrle Krantz  wrote:

> Hey all,
>
> In order to publish the additional service offering with respect to
> release management, I wanted to edit this page:
> https://incubator.apache.org/guides/releasemanagement.html
>
> This is my first time editing the incubator website.  I've never used
> asciidoc before either.  And that page already has a handful of minor
> errors.  So I decided to make my first test run fixing those minor errors.
> I cloned from, and committed and pushed to
> https://gitbox.apache.org/repos/asf/incubator.git master.
>
> What's the next step to get my changes published?  Do we have
> documentation for this somewhere?
>
> Best Regards,
> Myrle
>

Learning to edit the incubator website

Hey all,

In order to publish the additional service offering with respect to release
management, I wanted to edit this page:
https://incubator.apache.org/guides/releasemanagement.html

This is my first time editing the incubator website.  I've never used
asciidoc before either.  And that page already has a handful of minor
errors.  So I decided to make my first test run fixing those minor errors.
I cloned from, and committed and pushed to
https://gitbox.apache.org/repos/asf/incubator.git master.

What's the next step to get my changes published?  Do we have documentation
for this somewhere?

Best Regards,
Myrle

[RESULT][VOTE] introduce "[DISCUSS]" threads for podling releases

With 5 binding votes, the vote passes.

Votes received from:
Myrle Krantz
Justin Mclean
Sheng Wu
Furkan Kamaci
Lars Francke

I'm going to start by editing this here:
https://incubator.apache.org/guides/releasemanagement.html

If that's wrong, feel free to object and suggest a better location.  And
expect this to get a little messy since it'll be my first time editing
incubator material. : o)

Best,
Myrle

On Wed, Mar 13, 2019 at 10:09 AM Lars Francke 
wrote:

> +1 (binding)
>
> Just one question: Where/how do you plan on documenting this?
>
> On Wed, Mar 13, 2019 at 9:53 AM Furkan KAMACI 
> wrote:
>
> > Hi,
> >
> > +1 from me too!
> >
> > Kind Regards,
> > Furkan KAMACI
> >
> > On Wed, Mar 13, 2019 at 11:50 AM 吴晟 Sheng Wu 
> wrote:
> >
> > > > Amendment:
> > > > "A non-ASF release
> > > > * May or may not be staged on ASF infrastructure for the purposes of
> a
> > > > vote, but it is distributed via non-ASF infrastructure, AND
> > > > * Is either not linked from a podling's website, or is linked but
> > clearly
> > > > marked as a non-ASF release.”
> > >
> > >
> > > +1 (binding) from me. Make sense.
> > >
> > >
> > > --
> > > Sheng Wu
> > > Apache SkyWalking, ShardingSphere, Zipkin
> > > Twitter, wusheng1108
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -- Original --
> > > From:  "justin";
> > > Date:  Wed, Mar 13, 2019 04:41 PM
> > > To:  "general";
> > >
> > > Subject:  Re: [VOTE] introduce "[DISCUSS]" threads for podling releases
> > >
> > >
> > >
> > > Hi,
> > >
> > > +1 (binding)
> > >
> > > > Amendment:
> > > > "A non-ASF release
> > > > * May or may not be staged on ASF infrastructure for the purposes of
> a
> > > > vote, but it is distributed via non-ASF infrastructure, AND
> > > > * Is either not linked from a podling's website, or is linked but
> > clearly
> > > > marked as a non-ASF release.”
> > >
> > > Sounds reasonable to me, thanks for updating it.
> > >
> > > Thanks,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

Hey Bertrand,

On Wed, Mar 13, 2019 at 10:54 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Ok, if it's specific about non-ASF releases it should be named like that
> IMO.
>

There have been discussions about keeping ASF release votes inside the
podlings lists.  If one of those proposals gets accepted, I want to include
those releases in this service offering.

> [DISCUSS] threads have existed forever.
>

Yes they have been.  But in practice they are not being used for releases.

Best,
Myrle

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

On Wed, Mar 13, 2019 at 10:09 AM Lars Francke 
wrote:

> Just one question: Where/how do you plan on documenting this?
>

I don't know yet: I will look for an appropriate place and ask for
feedback.  Do you have a good idea?

Best,
Myrle

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

Hey Betrand! : o)

I totally agree that we don't need more rules.  Here's the original discuss
thread:
https://lists.apache.org/thread.html/3c4c8473f6733ad243b748398b25f3ef614aab32aa264216eeaa0695@

Specifically:
"It's not a rule. It's an offering of an additional service + an
incremental reduction in stringency of the incubator."

What's different than now is that rather than pretending non-ASF releases
don't exist, we are offering podlings the opportunity to use them to learn
and prepare for ASF releases.

Best,
Myrle

On Wed, Mar 13, 2019 at 10:04 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi Myrle,
>
> On Tue, Mar 12, 2019 at 6:27 PM Myrle Krantz  wrote:
> > ..."Podlings should be able to request feedback by starting a "[DISCUSS]"
> > thread or a "[VOTE]" thread
>
> Sorry that I didn't catch this at the discussion stage, but what is
> new in this proposal compared to now?
>
> Anyone can start a [DISCUSS] thread around anything including a release.
>
> We might write recommendations or examples of how to use such threads,
> but I don't think we need more rules.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

That seems fixable

I hereby amend the proposal with the following definition of "non-ASF
release".  If this definition is not sufficient, consider accepting the
term as currently undefined and start a discussion to create a definition
without blocking this vote:

Amendment:
"A non-ASF release
* May or may not be staged on ASF infrastructure for the purposes of a
vote, but it is distributed via non-ASF infrastructure, AND
* Is either not linked from a podling's website, or is linked but clearly
marked as a non-ASF release."

As to how I propose dealing with user confusion resulting from the
incomplete status of podlings:  This problem already exists, and it's been
discussed here for years.  I don't think that we need to solve every
problem of the incubator with this one proposal.  Independent of this
proposal, my opinion on the matter is that it shouldn't be up to the
podlings to solve it.  Podlings already have enough on their plates with
learning a new culture, building a community, getting a technology stack
set up, moving their stuff onto our infrastructure, and adjusting to a new
set of policies and procedures.  Explaining the difference between a
podling and a TLP should be the incubator's job.  And we need to accept
that it's not possible to do it perfectly.

My request now:  This proposal has been in discussion since February 26th.
Discussion had petered out.  If y'all think we need more discussion we can
do that, but please a.) *say* we need more discussion and b.) participate
in it.  Otherwise, please vote.

Best Regards,
Myrle

On Wed, Mar 13, 2019 at 12:13 AM Justin Mclean 
wrote:

> Hi,
>
> +1 to the idea in general, but +0 to it in its current form.
>
> > "Podlings should be able to request feedback by starting a "[DISCUSS]"
> > thread or a "[VOTE]" thread.  The podling can decide whether they prefer
> > [DISCUSS] or [VOTE], but only a release which passes a vote by members of
> > the IPMC is an official ASF release.
> >
> > Discussion should give podlings feedback on what they would need to do to
> > bring their release in line with the requirements of an official ASF
> > release and thus for graduation to TLP.  Podlings will be responsible for
> > capturing feedback that they accept in work items for their project.
> >
> > Feedback provided in a discussion thread will not block a non-ASF
> release.
> > Asking for feedback using this mechanism is not obligatory, but rather a
> > service that the incubator offers and podlings can take advantage of."
>
> I think this is an excellent idea but the wording re "will not block a
> non-ASF release” may need some work. (A minus one vote on a release doesn’t
> block anything as it’s not a veto, but that’s not my main concern).
>
> Let's assume for a minute that an podling make a release candidate, votes
> on it and put it up for incubator discussion. The IPMC finds it contains
> GPL licensed software and provides that feedback. What does the podling do?
> They probably can’t make this an ASF release or place in the ASF
> distribution channel or link to on their download page. to do so they would
> problem need permission from legal and infra. If they place it elsewhere
> it’s likely it will cause user confusion to what is an ASF release and what
> is not. How do you see the proposal working in this situatiion?
>
> Part of the big problem here is with distinguishing the non-ASF releases
> from the ASF ones. A lot of podlings fail to follow branding, trademark or
> distribution policy when making non-ASF releases or worse make it easy for
> users to confuse non-ASF releases with actual ASF releases and promote
> these non-ASF releases as ASF ones.
>
> > Notes on proposal:
> > * This proposal does presume that we are allowing non-ASF releases in the
> > early days of a poddling.  My understanding of the discussion of the last
> > few weeks is that this has *actually* always been allowed, but that that
> > knowledge may not have been wide spread.
>
> It’s a little more subtle than that, 3rd parties can make non-ASF
> releases, podlings (or rather the IPMC) can’t. A member of the (P)PMC can
> act as a 3rd party. This has also been used in a couple of cases to get
> around making official ASF release.
>
> Thanks,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Include Incubator as part of Community Track at Apachecon NA?

2019-03-12 Thread Myrle Krantz

Hey Dave,

Would you also be interested in submitting a talk to ApacheCon EU 2019?
Please keep us in mind!

Best Regards,
Myrle
Event Lead, ApacheCon Europe

On Tue, Mar 12, 2019 at 5:18 PM Dave Fisher  wrote:

> Hi Sharan,
>
> I’m thinking about submitting an Incubator focused talk for Apachecon NA
>
> Regards,
> Dave
>
> > On Mar 7, 2019, at 11:48 AM, Sharan Foga  wrote:
> >
> > Hi All
> >
> > I’m helping to manage the Community track for ApacheCon NA in Las Vegas
> > http://www.apachecon.com/acna19/index.html
> >
> > and would like to know what people think about including Incubator as
> part of the Community track. I know that some incubating projects might be
> included as part of the other tracks such as big data, iot or integration
> so this would give some potential schedule space to projects that don’t fit
> those categories.
> >
> > What do people think?
> >
> > Thanks
> > Sharan
> >
> > -
> > 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
>
>

[VOTE] introduce "[DISCUSS]" threads for podling releases

2019-03-12 Thread Myrle Krantz

I believe discussion has petered down on my proposal. It's time to bring
it to a vote.

Proposal:

"Podlings should be able to request feedback by starting a "[DISCUSS]"
thread or a "[VOTE]" thread. The podling can decide whether they prefer
[DISCUSS] or [VOTE], but only a release which passes a vote by members of
the IPMC is an official ASF release.

Discussion should give podlings feedback on what they would need to do to
bring their release in line with the requirements of an official ASF
release and thus for graduation to TLP. Podlings will be responsible for
capturing feedback that they accept in work items for their project.

Feedback provided in a discussion thread will not block a non-ASF release.
Asking for feedback using this mechanism is not obligatory, but rather a
service that the incubator offers and podlings can take advantage of."

Notes on proposal:
* I've adjusted it slightly from my original proposal based on feedback.
* This does not remove the requirement of voting on general for official
ASF releases. I do not object to that idea, but it's not necessary for
this proposal, so I'm keeping it separate.
* If the proposal is accepted, I'll find and update the relevant incubator
documentation. I'd appreciate any pointers y'all would like to give me.
* This proposal does presume that we are allowing non-ASF releases in the
early days of a poddling. My understanding of the discussion of the last
few weeks is that this has *actually* always been allowed, but that that
knowledge may not have been wide spread.
* It's not explicitly stated in my proposal, but I think many of us would
veto graduation of a podling that has never asked for feedback on its
releases in any form. I don't feel the need to encode that in the
proposal, since it is current policy.

Best Regards,
Myrle

* The discuss thread can be found here:
https://lists.apache.org/thread.html/3c4c8473f6733ad243b748398b25f3ef614aab32aa264216eeaa0695@%3Cgeneral.incubator.apache.org%3E

Re: A smaller IPMC

2019-03-08 Thread Myrle Krantz

+1 option #4.

Based on Justin's fact-finding, these "extra" IPMC members are not the
source of the IPMC's problem.  Let's put the conversation about removing
IPMC members to bed so that we can focus on more promising causes and cures.

Best,
Myrle

On Fri, Mar 8, 2019 at 12:33 AM Justin Mclean 
wrote:

> Hi,
>
> It’s been suggested that the IPMC is too large, what do other IPMC members
> think might be a way to address this?
>
> Please discuss and indicate +1 what you would think would help, you can
> vote for more than one.
>
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> see who steps down. Being inactive they are probably not following this
> list so we need to identify and send each one email them personally.
> 2. There were some questions around merit raised, remove all IPMC members
> who were not on the initial proposal and who were voted in. Those left on
> the IPMC vote back in those who are currently active.
> 3. Get rid of all IPMC members, and vote (with ASF members vote being
> binding - not sure how else it could be done?) currently active ones back
> in.
> 4. Do nothing as this is not actually a problem but instead address other
> underlying issues. e.g. lack of mentor engagement.
>
> Also re point 2 do you think we should drop that ASF members can
> automatically get IPMC membership and change it to requiring a vote by the
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently
> voted more people in that we’ve had requests from ASF members.
>
> Any other sugestions?
>
> Options 2 and 3 may cause some issues around mentors, but if they were not
> active then I guess it’s no big loss.
>
> And any suggestions on level of activity? Such as:
> - Emailed the list in the last year.
> - Reviewed at least one release in that time.
>
> It’s already been determined that some (about 15%) of the less than active
> PMC members (out of the 100 odd that are not signed up to the IPMC private
> list) do help out infrequently but that help is very useful. That may also
> apply to other inactive IPMC members, so I would suggest the bar for what
> consider active be kept low.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

2019-03-07 Thread Myrle Krantz

On Thu, Mar 7, 2019 at 11:07 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> a) Asking PMC members if they want to step down from the PMC if they
> seem to be inactive for a long time
>
> b) Forcibly removing PMC members that the PMC considers inactive
>
> IMO a) is fine if a PMC wants to have a roster that reflects reality,
> but b) is bad in terms of community
>
> And yes in any case removals have to be ratified by the Board as per
> http://www.apache.org/dev/pmc.html#pmc-removal

Minor correction (and perhaps this is what you meant):  In the case of
voluntary resignation, the board does not have to ratify.

Quote from the document you linked:
"Once the PMC member's resignation is received on a mailing list of the
Foundation, the resignation is considered effective (however, the PMC
member has 72 hours to withdraw their resignation). Notifying the board is
not required, but encouraged to ease tracking."

We're not quite the Hotel California. : o)

Greets,
Myrle

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

2019-03-06 Thread Myrle Krantz

Hey all,

I've only heard positive feedback on this proposal.  It doesn't solve all
our problems, but it would provide a path around some of the bureaucracy.

Would the other mentors be willing to bring this suggestion to their
podlings?  Especially the "young" ones who still need releases outside of
the ASF?

Best Regards,
Myrle

On Tue, Feb 26, 2019 at 8:50 AM Myrle Krantz  wrote:

> Motivation:
>
> Some podlings want or need feedback on their releases before they are
> ready to make official Apache releases.  They want to discuss releases that
> are not yet ready for a VOTE, or that they are not sure they are ready for
> a vote.  They may wish to make an early release outside of the foundation,
> but still test the ASF waters.  They prefer to "fail early, fail often and
> fail forward". [1]
>
>
> Proposal:
>
> Podlings should be able to request feedback by starting a "[DISCUSS]"
> thread instead of a "[VOTE]" thread.  Discussion should give podlings
> feedback on what they would need to do to bring their release in line with
> the requirements for graduation to TLP.  Podlings will be responsible for
> capturing feedback that they accept in work items for their project.
> Feedback provided in a discussion thread will not block a non-ASF release.
>
> Asking for feedback using this mechanism is not obligatory, but rather a
> service that the incubator offers.
>
>
> Arguments for this proposal:
>
> * It's a very small change which may make it easier to implement than some
> of the "throw it all away and start over" proposals circulating, but...
> * It doesn't prevent us from making other larger changes.
> * It's not a rule.  It's an offering of an additional service + an
> incremental reduction in stringency of the incubator.
> * It captures some of the value in what we are doing now while increasing
> the degrees of freedom provided to podlings.
> * It is consistent with our values of transparency, collaboration,
> community, pragmatism, meritocracy, and charity.
>
> Best Regards,
> Myrle
>
> 1.)
> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

2019-03-06 Thread Myrle Krantz

On Wed, Mar 6, 2019 at 4:49 PM Daniel Gruno  wrote:

> Or put differently; why would we care that someone is inactive on the
> IPMC? Are we short on bytes on the LDAP server and need to conserve
> space? ;). It should make no difference if there are inactive members of
> the IPMC or not.
>

Have you tried loading the IPMC roster in whimsy?  ; o)
Here, look at what I mean:
https://whimsy.apache.org/roster/committee/incubator

(This still isn't my argument though.)

Best,
Myrle

Re: Write access to Incubator Wiki

2019-03-05 Thread Myrle Krantz

Hey Lee,

I've added you.  Let me know if it doesn't work.

Best,
Myrle

On Mon, Mar 4, 2019 at 9:09 PM lee...@gmail.com  wrote:

> Hi,
>
> May I get write access to wiki? My wiki name is *Lee Rhodes*
>
> Project Proposal: Apache DataSketches
>
> Kind Regards,
> Lee Rhodes
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Graduate Apache SkyWalking (incubating) as a TLP(take2)

2019-03-04 Thread Myrle Krantz

When I was writing the graduation proposal for Fineract I explicitly asked
each PMC member for permission to put them on the list.  One guy never
answered, so I removed him from the list.  There's nothing really *wrong*
with having inactive PMC members, but you can at least start your project's
TLP "life" with the ones who are active enough to respond and subscribe.

YMMV, but for the graduation vote, I'd like to at least know which ones are
subscribed for the purposes of getting a slightly more accurate picture of
the project's true corporate diversity.

Best,
Myrle

On Mon, Mar 4, 2019 at 8:42 AM Justin Mclean 
wrote:

> Hi,
>
> I’m still not 100% sure that this project its ready to graduate. Looking
> at the roster [1] only 1/2 the the proposed PMC members are signed up to
> the projects private list. Some of the people suggested have limited
> interaction on the mailing list(s)  and in a couple of cases have never
> sent an email to them that I can find. How was this PMC list determined and
> where was this discussed? Perhaps the roster needs to be adjusted in the
> proposal for it to be accepted by the IPMC? What do others think?
>
> Thanks,
> Justin
>
> 1.  https://whimsy.apache.org/roster/ppmc/skywalking
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

2019-03-01 Thread Myrle Krantz

On Fri, Mar 1, 2019 at 12:33 AM Justin Mclean 
wrote:

>
> And most probably do not participate. Would asking for those 100 odd
> people to be removed come across as friendly?
>

I'd be +1 on removing them.  a.) While kindness towards our fellow PMC
members is important, the role of the Incubator is to be friendly to
incoming projects. b.) It's not unkind to our fellow PMC members.  They are
welcome to come back when they're ready.

But I also don't think it's going to solve anything.  Those people aren't
contributing to solutions *or* problems.

Best,
Myrle

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

2019-02-28 Thread Myrle Krantz

Hey Justin,

On Wed, Feb 27, 2019 at 8:33 AM Justin Mclean 
wrote:

> How do we make podling aware they can do this? Obvious people who follow
> this list may know, and we can ask mentors to pass it on to their podling
> lists, on document on the website and perhaps mention it in Dave’s welcome
> package idea. But would that be enough?
>

Important question!

Aren't podlings still required to subscribe to general@incubator?  I don't
know how the rest of the world figures these things out, but I mostly
followed the examples I saw here.  So we need to get a few podlings doing
this to create visibility.  We could do some combination of:

* notify all the dev lists for all the podlings
* notify just those podlings still doing releases outside of the ASF (which
you have helpfully identified)
* ask mentors to suggest it to their podlings when a release is imminent
and the mentor thinks its a good candidate for this approach.
* if a podling approaches you for feedback, ask if you can do so on the
general@incubator list.
* document it (probably the most obligatory and least effective item on the
list. ; o)

I'd also like to read Mick's feedback:
Do you think replacing release voting with release discussing at podling
request as I've suggested would be an improvement?  If so, do you have
ideas for ways to communicate this to podlings?

Best,
Myrle

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

2019-02-26 Thread Myrle Krantz

Dave,

On Tue, Feb 26, 2019 at 10:30 PM Dave Fisher  wrote:

> The IPMC could consider some changes to the Incubator rules. (As proposed
> mostly by Roy on private lists.)
>
> Allow the VOTE thread to be only on the dev@ list with 0 or 1 mentor vote
> required. As long as the DISCLAIMER exists then the pooling release is good.
>

I think the idea is worth discussing (and I'm still deciding how I feel
about it).  But my proposal to move towards offering early feedback on
releases works with or without this change.  For this reason, I suggest you
start a separate thread to discuss this proposal.

Best,
Myrle

(Note: since Roy is making his arguments on a private list, you'll have to
depend on your own words.  If Roy doesn't wish to engage on the public
list, we need to respect that.)

Re: Podlings Which Need Mentors

2019-02-26 Thread Myrle Krantz

This is a helpful collection Dave,

So one way to put these facts next to each other:
* We have 1 podling that has expressed concerned about too much IPMC
involvement.  (Possibly more who are concerned but unwilling to speak up.)
* We have 8 podlings that have too little IPMC involvement.

This does look like a problem with how we decide to distribute our
attention rather than a problem of "too many cooks".

Best,
Myrle

[DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

2019-02-25 Thread Myrle Krantz

Motivation:

Some podlings want or need feedback on their releases before they are ready
to make official Apache releases. They want to discuss releases that are
not yet ready for a VOTE, or that they are not sure they are ready for a
vote. They may wish to make an early release outside of the foundation,
but still test the ASF waters. They prefer to "fail early, fail often and
fail forward". [1]

Proposal:

Podlings should be able to request feedback by starting a "[DISCUSS]"
thread instead of a "[VOTE]" thread. Discussion should give podlings
feedback on what they would need to do to bring their release in line with
the requirements for graduation to TLP. Podlings will be responsible for
capturing feedback that they accept in work items for their project.
Feedback provided in a discussion thread will not block a non-ASF release.

Asking for feedback using this mechanism is not obligatory, but rather a
service that the incubator offers.

Arguments for this proposal:

* It's a very small change which may make it easier to implement than some
of the "throw it all away and start over" proposals circulating, but...
* It doesn't prevent us from making other larger changes.
* It's not a rule. It's an offering of an additional service + an
incremental reduction in stringency of the incubator.
* It captures some of the value in what we are doing now while increasing
the degrees of freedom provided to podlings.
* It is consistent with our values of transparency, collaboration,
community, pragmatism, meritocracy, and charity.

Best Regards,
Myrle

1.)
https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success

Re: Starting at the incubator and releases

2019-02-25 Thread Myrle Krantz

 voting  both before and after
graduation.  As a mentor, I _shudder_ at the thought of being asked to vote
on a new release every day.  Removing the possibility for QA builds only
forces project activity behind corporate firewalls.  It doesn't enable
transparency or community.


As to the documentation
-
This is both a typical software project problem and a typical volunteer
organization problem: "'somebody' should fix this mess".  Whoever takes it
on certainly will not be paid for it, and is very likely to get yelled at
for it.  Given those two conditions, it's actually surprising that it's as
good as it is.  And that's not even considering the ways in which incubator
information is duplicated in other places in the foundation, or
contradicted, or linked.


Best Regards,
Myrle

On Mon, Feb 25, 2019 at 10:05 AM Mick Semb Wever  wrote:

>
> I'll chime in, but on the technical front my experience is rather new in
> the incubator, i'm still learning.
>
>
> > Looking at some of the situations we currently have I think we may need
> > some more general guidance for incubating projects and making releases
> > after just joining the incubator.
>
>
> By far, the two biggest issues I see are:
>  i)  "too many cooks in the kitchen" and IPMC strangers _policing_ the
> rules on podlings,
>  ii) "There is documentation _all over the place_ and it's not possible to
> know which of it is outdated and which is still current especially in the
> face of conflicting information." – Lars Francke.
>
> Addressing and improving the rules and process can help. But better
> documentation, automation of checks, and better communication style and
> channels, will go a lot further, imho.
>
> Another way to think of this is: it is not the podling that failed the
> release process, but the IPMC that failed the podling. Why were the tooling
> and documentation not put in place by the IPMC so that it then had to rely
> upon instead late policing and being the gatekeepers.
>
>
> > In this context “non approved” means
> > releases or distributions not approved by the PPPM and IPMC (usually by
> > voting) and available and promoted to the general public.
>
>
> Something that has been brought up is allowing a podling to incrementally
> improve their releases. What this actually means has not been stated
> clearly.
>
> The different types of resulting podling releases I'm aware of are…
>  a) fully ASF compliant,
>  b) legal but not fully ASF compliant,
>  c) illegally ASF,
>  d) staged/nightly/snapshot,
>  e) external.
>
>
> With these types, my understanding is that a podling needs to demonstrate
> a number of releases of type (a) before raising its vote for graduation.
> What's not clear is what releases are (b), and where should (c) releases
> get hosted? (For example can they simply stay as staged releases.)
>
> If the goal is to encourage momentum, and for some podling cultures this
> means permitting incrementally improving ASF releases, then the more
> minimal the requirements to (a) are the better, and any shortcomings in
> releases of type (b) should be listed in a jira ticket rather than as a
> "-1" vote on the release.
>
> So far there's been the effort to minimise the requirements to (a), and
> this is very appreciated.
>
> https://lists.apache.org/thread.html/7690a00c6a8aba9f51a6dfaa9dc9273626715006eab4c43e6893a839@%3Cprivate.incubator.apache.org%3E
>
> It's still unclear to me what are all the soft requirements that when
> violated lead to type (b)?
> For example this document alludes to the distinction, but not the
> separation: https://wiki.apache.org/incubator/IncubatorReleaseChecklist
>
> Is this documented correctly anywhere?  If this was better documented, and
> violations dealt with as jira tickets, it might well have been enough to
> have prevented the situation with Zipkin. I'm sure the same is true for the
> other podlings that have experienced such feedback as abrasive.
>
> Another thing is legal violations that lead to (a) but that are not
> specific to one podling, should not suddenly become a burden on a podling
> doing its first release. If other releases have the problem, for example
> it's not been properly identified before, it's brand new or the dust on how
> to deal with it is still settling, then for the love of god don't decide to
> pick on it with a podling's *first* release attempt. Get it in order
> (settled and documented) elsewhere before policing the podling. Taking
> release violations up with mentors first would also be another way around
> this problem.
>
> I'm also in favour of aiming for deprecating the need for the IPMC votes.
> With the

Re: [VOTE] Accept Training into the Apache Incubator

2019-02-19 Thread Myrle Krantz

I think very strictly the rules would say no. But I also don’t think anyone
here will object if you add Jim anyways.

Best,
Myrle

On Tue, Feb 19, 2019 at 3:18 PM Lars Francke  wrote:

> I'd be happy to add you but I have honestly no idea what the rules say
> about changing a proposal after the vote has already started?
>
> On Tue, Feb 19, 2019 at 2:59 PM Jim Jagielski  wrote:
>
> > PS: I'd also like to be added to the initial Contributor's list, if
> > possible.
> >
> > > On Feb 19, 2019, at 8:51 AM, Jim Jagielski  wrote:
> > >
> > > +1 (binding)
> > >
> > >> On Feb 13, 2019, at 2:57 AM, Lars Francke 
> > wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> we've discussed the proposal for the Training project in [1] and [2].
> > The
> > >> proposal itself can be found on the wiki[3].
> > >>
> > >> According to the Incubator rules[4] I'd like to call a vote to accept
> > the
> > >> new "Training" project as a podling in the Apache Incubator.
> > >>
> > >> A vote for accepting a new Apache Incubator podling is a majority
> vote.
> > >> Everyone is welcome to vote, only Incubator PMC member votes are
> > binding.
> > >> It would be helpful (but not required) if you could add a comment
> > stating
> > >> whether your vote is binding or non-binding.
> > >>
> > >> This vote will run for at least 72 hours (but I expect to keep it open
> > for
> > >> longer). Please VOTE as follows:
> > >>
> > >> [ ] +1 Accept Training into the Apache Incubator
> > >> [ ] +0 Abstain
> > >> [ ] -1 Do not accept Training into the Apache Incubator because ...
> > >>
> > >> Thank you for everyone who decided to join in in the past discussions!
> > >> Lars
> > >>
> > >> [1] <
> > >>
> >
> https://lists.apache.org/thread.html/5c00016b769135cc302bb2ce4e5f6bbfeeda933a07e9c38b5017d651@%3Cgeneral.incubator.apache.org%3E
> > >>>
> > >>
> > >> [2] <
> > >>
> >
> https://lists.apache.org/thread.html/9cb4d7eef73e0d526e0124944c3d37325aa892675351a1eed0a25de3@%3Cgeneral.incubator.apache.org%3E
> > >>>
> > >>
> > >> [3] <https://wiki.apache.org/incubator/TrainingProposal#preview>
> > >>
> > >> [4] <
> > >>
> >
> https://incubator.apache.org/policy/incubation.html#approval_of_proposal_by_sponsor
> > >>>
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: the case of the maven wrapper

2019-02-18 Thread Myrle Krantz

On Thu, Feb 14, 2019 at 7:05 AM Mick Semb Wever  wrote:

> One of the tings I've noticed is that the vetos on a podling's first
> release can be a bit harsh.
>

> On releases I would rather see such vetos replaced with comments that are
> feedback, while still obvious that they are an issue that is expected to be
> fixed by the next release (and before graduation). I think this would be
> warmer feedback, and permit a more incremental approach to getting to the
> standard of release required for graduation.

I have to disagree here. I’ve been watching Justin vote on releases for
*years* now. No one is more prolific (not even by half). And he always
gives detailed reasons for his vote. He’s also very clear about what issues
he sees as blockers and what issues aren’t blockers, but that he’d like to
see resolved before graduation. The overarching principle is clear: if it
could place users, contributors, or the ASF in jeopardy we veto. Justin is
very good at finding these.  This is the reason that, even though vetos
don’t technically block the release, when Justin states a -1, others will
often withdraw a +1.

And yes: that’s frustrating. No amount of warm verbiage added to the veto
will change the fact that it’s frustrating.  Would you rather we accept the
legal jeopardy?

Justin is not always right about a given detail.  No one is.  That may be
the case in this specific instance.  But what I'm responding to is a
general statement about the way our release vetting process.  I do not
believe we are too harsh.

I’d also note: we are all doing this on his own *unpaid* time. While our
communications should be clear and empathetic there are still limits as to
how much time we can spend on our emails (and how many words others will
read). At some point the reader will need to take responsibility for their
own reactions.

Best Regards,
Myrle

Re: [DISCUSS] Guidelines for distribution of incubating artefacts on other platforms

2019-02-13 Thread Myrle Krantz

Weex Mentor here.  Answers inline:

On Wed, Feb 13, 2019 at 8:36 AM Justin Mclean 
wrote:

> Hi,
>
> > We distribute artefacts through *CocoaPods*

I'm with Justin: I'm not familiar with this either, but my first skim
across their information doesn't indicate they'd be fundamentally different
than the other distribution methods.  Would you like write access to the
instructions so that you can add them?

> > and *Gradle* channel

Do you mean maven here?  These lines in gradle:

dependencies {
...
// weex sdk and fastjson

compile 'com.taobao.android:weex_sdk:0.18.0@aar'
}

draw from a maven repository.

Maven is listed in our instructions.

> Does this mean that we need a vote even for distribution of unreleased
> > material <https://www.apache.org/dev/release-distribution#unreleased>?
>
> You are not allowed to distribute unreleased material outside the
> developer community. [1] I would read that as users being outside the
> developer community.
>

I would reserve judgement here.  If it's a limited circle of users who are
consistently QAing your stuff, I'd see them as contributors to the
project.  In this case, you should also consider making these people
committers.  They are important to the success of your project.

> > Incubator-weex had used unofficial release without vote to get quick
> > feedback from users before we knew it could break the rule of Apache
> > release. *According to my understanding, any format of release on any
> > platform needs a vote even if it is unofficial, snapshot, nightly build
> and
> > etc..* Correct me if I am wrong.
>
> Well a snapshots shot or nightly may be OK if it a) not use as a
> substitute for not voting b) clearly marked so a user wouldn’t assume it a
> release and c) not placed in the main place user go to to get it. I would
> guess that the above doesn’t qualify but check with your mentors.
>

Users can be involved in your QA process.  If select users are downloading
your stuff and giving feedback, that's fine.  However if you've  been
advertising your stuff more broadly (for example by referencing unreleased
versions it in your getting started guide), you've been "breaking the
rules".

If that's the case, I'm fairly certain you didn't intend to.  So it should
be easy to fix.  In the case of the website example: just revert the
website examples to reference properly released versions.

If you have any questions, I'm here to help.

Best Regards,
Myrle
Weex Mentor

Re: [VOTE] Accept Training into the Apache Incubator

2019-02-13 Thread Myrle Krantz

+1 (binding)

On Wed, Feb 13, 2019 at 11:03 AM Christofer Dutz 
wrote:

> +1 (binding)
>
> Chris
>
> Am 13.02.19, 08:58 schrieb "Lars Francke" :
>
> Hi everyone,
>
> we've discussed the proposal for the Training project in [1] and [2].
> The
> proposal itself can be found on the wiki[3].
>
> According to the Incubator rules[4] I'd like to call a vote to accept
> the
> new "Training" project as a podling in the Apache Incubator.
>
> A vote for accepting a new Apache Incubator podling is a majority vote.
> Everyone is welcome to vote, only Incubator PMC member votes are
> binding.
> It would be helpful (but not required) if you could add a comment
> stating
> whether your vote is binding or non-binding.
>
> This vote will run for at least 72 hours (but I expect to keep it open
> for
> longer). Please VOTE as follows:
>
> [ ] +1 Accept Training into the Apache Incubator
> [ ] +0 Abstain
> [ ] -1 Do not accept Training into the Apache Incubator because ...
>
> Thank you for everyone who decided to join in in the past discussions!
> Lars
>
> [1] <
>
> https://lists.apache.org/thread.html/5c00016b769135cc302bb2ce4e5f6bbfeeda933a07e9c38b5017d651@%3Cgeneral.incubator.apache.org%3E
> >
>
> [2] <
>
> https://lists.apache.org/thread.html/9cb4d7eef73e0d526e0124944c3d37325aa892675351a1eed0a25de3@%3Cgeneral.incubator.apache.org%3E
> >
>
> [3] 
>
> [4] <
>
> https://incubator.apache.org/policy/incubation.html#approval_of_proposal_by_sponsor
> >
>
>
>

Re: Renaming repos and security concerns

2019-02-09 Thread Myrle Krantz

I have no objections to you editing that into it.  I do however think it's
important to explain the reasons for the rules together with the rules.

Please note that I've mentioned legal jeopardy, so if you're going to
"strengthen" the language you may need to delete existing text to avoid
redundancy.  But again I have no objections to you doing that.

Best Regards,
Myrle

On Sat, Feb 9, 2019 at 2:10 PM Justin Mclean  wrote:

> Hi,
>
> > Thank you.  I've corrected some typos, and then added a motivation
> > section.  Questions/comments/suggestions, as always, welcome.
>
> Thanks for edits but I think you missed the main reason, it's mostly about
> the legal umbrella and protection we give our (P)PMC’s. If they do
> something outside of what is prescribed then there are  possible
> consequences. See [1] "Deviations from this policy may have an adverse
> effect on the legal shield's effectiveness, or the insurance premiums
> Apache pays to protect officers and directors, so are strongly discouraged
> without prior, explicit board approval” While there is still a risk of
> someone taking legal action that’s less likely.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/release-policy.html#why
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Renaming repos and security concerns

2019-02-09 Thread Myrle Krantz

Thank you.  I've corrected some typos, and then added a motivation
section.  Questions/comments/suggestions, as always, welcome.

Best Regards,
Myrle

On Fri, Feb 8, 2019 at 11:59 PM Justin Mclean 
wrote:

> Hi,
>
> > We need to make sure that pre-Apache releases whether source or binary
> are treated in a fair way.
>
> As long are they are not in after the date of incubation and clearly
> marked I see no issues.
>
> > An über-comment - let’s be exceedingly careful with time limits for
> “compliance”.
>
> What do you suggest? If a podling is not following ASF release policy how
> long do we give them to fix that? IMO if the podling is dealing with it
> then all is OK, but we can’t wait for months while that is happening.
>
> > I think it would be good to finalize proposed policies from master
> copies on the wiki.
>
> Here you go. Feel free to edit. [1]
>
> Thanks,
> Justin
>
> 1. https://wiki.apache.org/incubator/DistributionGuidelines

Re: [DISCUSS] Training (incubating) Proposal

2019-02-08 Thread Myrle Krantz

My initial thought was: this should go straight to TLP: Training should be
done by people who know what they're training about: whether it be the
Apache Way or a specific project.  All the committers will likely be people
who've at least reached committer status in a project, and most of them
will probably be ASF members.

But then I thought again: developing effective materials will require
contact to the users of those materials.  What better place to find people
to QA training materials and approaches than in the incubator?  I think a
training project would benefit from incubator participation in a different
manner than most projects do, but I do think starting in the incubator (and
possibly, after discussion, even staying there) might be a good approach
for this project.

Best Regards,
Myrle

On Fri, Feb 8, 2019 at 10:34 AM Sönke Liebau
 wrote:

> Hi,
>
> after spending some time thinking about this I also tend towards the
> Incubator route as I am sure this will help build and grow an active
> community and processes.
>
> Best regards,
> Sönke
>
> On Fri, Feb 8, 2019 at 6:38 AM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > > discussion seems to have died down. Before moving on I'd really like to
> > > hear the opinions of the interested contributors on which direction to
> go.
> > > Otherwise we might have to put it to a vote?
> >
> > Perhaps I biased, but I think going via the incubator is alway helpful.
> :-) The big question is would the board support the project going straight
> to TLP? I really don’t know, it’s approved them in the past and not
> rejected any that I know of. What could the project do to show the board
> that going straight to TLP is justifiable? Perhaps start by list out how
> many ASF members you have on the project and and give an idea of how long
> they been around, how many projects they gone through incubation with and
> how active they are in the incubator and may help you decide which path to
> go and give the board some reassurance.
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> --
> Sönke Liebau
> Partner
> Tel. +49 179 7940878
> OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Draft incubator report

2019-02-05 Thread Myrle Krantz

Cool.  I think we've generated some consensus, even if we haven't answered
every question.  To summarize, I'd like to change this paragraph of the
report:

"Again a reminder to all incubating projects and mentors that all releases
made available to the general public need to be approved by the PPMC and
IPMC. This includes docker, githubb, PyPi, npm and any other platform for
publishing releases, and also covers release candidates. If in doubt please
ask your mentors or on the incubator general list."

To this:

"A reminder to all incubating projects and mentors that all releases
and distributions advertised to the general public need to be approved by
the PPMC and IPMC. This includes docker, github, PyPi, npm and any
other platform for publishing releases, and also covers release candidates.
Nightly builds for project-internal use clearly marked as "snapshot" or
"prerelease" (or similar) can be made available to project contributors. If
in doubt please ask your mentors or on the incubator general list."

Objections?

Best Regards,
Myrle

On Tue, Feb 5, 2019 at 7:34 PM Dave Fisher  wrote:

>
>
> > On Feb 5, 2019, at 10:27 AM, Kevin A. McGrail 
> wrote:
> >
> > On 2/5/2019 6:27 AM, Justin Mclean wrote:
> >> Hi,
> >>
> >>>> As long as these are not available to the general public all is fine.
> [1]
> >>> s/available/advertised/
> >> Thanks that’s a better way of putting it. Obviously any published
> artefact is available to the general public if and when they discover it.
> >
> >
> > Thanks Justin.  The advertised vs available was a big concern for me
> > when I read that this morning.
>
> Yes, that is better, but here is the next challenge. For distribution
> channels like Maven, NPM, etc which some projects use to stage prospective
> releases how do we recommend that projects stay within the available, but
> not advertised rule? I think somewhere some guidance is needed. Recently on
> legal-discuss there is a long thread [1] which discusses binary channels.
> Perhaps some guidance can be pulled from that thread.
>
> Regards,
> Dave
>
> [1]
> https://lists.apache.org/thread.html/d578819f1afa6b8fb697ea72083e0fb05e43938a23d6e7bb804069b8@%3Clegal-discuss.apache.org%3E
> <
> https://lists.apache.org/thread.html/d578819f1afa6b8fb697ea72083e0fb05e43938a23d6e7bb804069b8@%3Clegal-discuss.apache.org%3E>
>
>
>
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>

Re: Draft incubator report

2019-02-05 Thread Myrle Krantz

That statement would also forbid maven snapshots. Something which many
projects (TLPS too) offer. Is that the intention?

It’s important to me that when we forbid something that projects are doing
for valid reasons that we offer an alternative within the same statement.
I’ve offered a potential draft of alternative language which you rejected.
I humbly request that you propose an alternative.

Best Regards,
Myrle

On Tue, Feb 5, 2019 at 11:24 AM Justin Mclean  wrote:

> Hi,
>
> > We need a formulation which enables pre-release QA by non-coding
> > contributors.  I've given my attempt at formulating it.  Please give your
> > take on how to accomplish this.
>
> As long as these are not available to the general public all is fine. [1]
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/release-policy.html#what
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Draft incubator report

2019-02-04 Thread Myrle Krantz

Hi Justin,

We need a formulation which enables pre-release QA by non-coding
contributors.  I've given my attempt at formulating it.  Please give your
take on how to accomplish this.

Best Regards,
Myrle

On Mon, Feb 4, 2019 at 10:01 PM Justin Mclean 
wrote:

> Hi,
>
> > This does *not* include nightly builds, or other project *internal*
> artifacts
> > used for quality control and experimentation.”
>
> Actually it does apply and those builds can’t be offered directly to the
> general public, but each of the platforms has mechanisms for doing that.
>
> For instance, marking nightly builds as latest (which means they get
> installed by default) in Docker would not be allowed [1], nor would marking
> nightly build as releases in guthub,
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/LEGAL-270
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Draft incubator report

2019-02-04 Thread Myrle Krantz

Hi Justin,

This looks good.

in your general notice about releases, please include a note about nightly
builds, and any other non-releases which communities can make.

In other words, after: "This includes docker, githubb, PyPi, npm and any
other platform for
publishing releases, and also covers release candidates." please add "This
does *not* include nightly builds, or other project *internal* artifacts
used for quality control and experimentation."

We don't want to be scaring off projects that have a healthy attitude
towards UX-testing. : o)

Thanks,
Myrle

On Sun, Feb 3, 2019 at 8:34 AM Justin Mclean 
wrote:

> Hi,
>
> Draft incubator report has been put up here [1]
>
> We’re still missing reports from a number of podling and you only have a
> few days to get them in.
>
> Feedback and edits welcome. Is there anything I’ve missed that should be
> mentioned?
>
> Here’s the text of the main part of the report:
>
> Incubator PMC report for February 2019
>
> The Apache Incubator is the entry path into the ASF for projects and
> codebases wishing to become part of the Foundation's efforts.
>
> There are presently 51 podlings incubating. During the month of January,
> podlings executed 3 distinct releases. We added no new IPMC members and
> had no IPMC members retire.
>
> We have one new podling Hudi. No project graduated last month but several
> podlings are heading towards graduation in the next few months.
>
> BatchEE took a vote to go to Apache Geronimo or TLP and decided on TLP and
> are back to being stuck in trying to graduate.
>
> We're currently missing several podling report but hopefully they be
> submitted and have mentor sign-off on time.
>
> There was one IP clearance.
>
> The mentor situation is continuing to improve. One of the mentors for the
> new Hudi project realised he didn't have the time be be able to give to
> the
> project and stood down. Thanks to him for being able to recognising that
> he
> wasn't going to be an effective mentor. Other mentors stepped forward to
> do
> the job.
>
> We have a problem with unapproved releases. A spot check on some (not all)
> projects reporting this month showed that five projects were making
> unapproved releases. Hopefully that's a statical aberration, but it seems
> likely that we probably have more codlings making unapproved releases than
> this. This has been brought up one the general list and I see a few
> projects have taken note of it.
>
> Three of the project Doris, Pinot and Sharding Sphere responded quickly
> and
> removed the releases. SDAP is addressing the issue. ECharts is a little
> reluctant to remove the releases due to the high use and popularity of the
> project and is trying to find another way of resolving the situation. The
> board may need to be involved.
>
> ECharts was also found to hosting a Chinese version of their incubating
> site at echarts dot baidu dot com. The PPMC is dealing with this.
>
> Again a reminder to all incubating projects and mentors that all releases
> made available to the general public need to be approved by the PPMC and
> IPMC. This includes docker, githubb, PyPi, npm and any other platform for
> publishing releases, and also covers release candidates. If in doubt
> please
> ask your mentors or on the incubator general list.
>
> Superset has not made an Apache release but is making progress towards
> one.
> They accidentally published a release candidate to GitHub but are sorting
> that out.
>
> There was also an interesting discussion on binary releases on
> legal-discuss that could have some impact on the incubator.
>
> New new project creating ASF training material may either go to straight
> to
> TLP or via the incubator. This did raise a few questions about how initial
> committers are selected.
>
> * Community
>
>   New IPMC members:
>   - None
>
>   People who left the IPMC:
>   - None
>
> * New Podlings
>   - Hudi
>
> * Podlings that failed to report, expected next month
>  - BRPC?
>  - Edgent?
>  - Heron?
>  - Iceberg?
>  - PageSpeed?
>  - Ratis?
>  - S2Graph?
>  - SDAP?
>  - Toree?
>
> * Graduations
>
>   The board has motions for the following:
>   - Unomi?
>
> * Releases
>
>   The following releases entered distribution during the month of
>   January:
>   - Apache Dubbo 2.7.0
>   - Apache SkyWalking 6.0.0-GA
>   - Apache Dubbo Spring Boot 0.2.1 and 0.1.2
>
> * IP Clearance
>   - Apache Arrow Rust DataFusion
>
> * Legal / Trademarks
>   N/A
>
> * Infrastructure
>   N/A
>
> * Miscellaneous
>   - vote to shut down some old unused incubator lists
>   - discussion on what to do with retired podling repositories
>
> Thanks,
> Justin
>
>
> 1. https://wiki.apache.org/incubator/February2019
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Grant for wiki

2019-01-30 Thread Myrle Krantz

You should have write access now.

Best Regards,
Myrle

On Wed, Jan 30, 2019 at 10:46 AM Jaeyeon Baek  wrote:

> Greetings,
>
> I’m recently plan to contribute to the Apache incubator. Can someone grant
> me ASF wiki write access?
>
> username : *caleybaek*
>
> Thanks, Caley.
>

Re: [VOTE] Graduate Apache Unomi to TLP

2019-01-21 Thread Myrle Krantz

+1 (binding)

On Mon, Jan 21, 2019 at 3:19 PM Jean-Baptiste Onofré 
wrote:

> Hi,
>
> @Bertrand, thanks for the feedback. I removed the two sections from the
> graduation resolution proposal (as an erratum).
>
> Let's continue the vote process:
>
> here's my +1 (binding).
>
> Regards
>
> Erratum on graduation resolution:
>
> 
> Establish the Apache Unomi Project
>
> 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, for distribution at no charge to the public,
> related to providing a reference implementation of the OASIS Customer
> Data Platform specification currently being worked on by the OASIS
> Context Server Technical Committee.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Unomi Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache Unomi Project be and hereby is responsible for
> the creation and maintenance of software related to providing a
> reference implementation of the OASIS Customer Data Platform
> specification currently being worked on by the OASIS Context Server
> Technical Committee; and be it further
>
> RESOLVED, that the office of "Vice President, Apache Unomi" 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 Unomi
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Unomi 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 Unomi Project:
>
>  * David Griffon
>  * Francois Papon   
>  * Jean-Baptiste Onofré 
>  * Kevan Jahanshahi 
>  * Serge Huber  
>  * Thomas Draier
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Serge Huber be appointed to
> the office of Vice President, Apache Unomi, 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 Unomi PMC be and hereby is tasked with
> the creation of a set of bylaws intended to encourage open development
> and increased participation in the Apache Unomi Project; and be it
> further
>
> RESOLVED, that the Apache Unomi Project be and hereby is tasked with the
> migration and rationalization of the Apache Incubator Unomi podling; and
> be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Unomi podling encumbered upon the Apache Incubator PMC are hereafter
> discharged.
> 
>
> On 21/01/2019 11:46, Bertrand Delacretaz wrote:
> > Hi,
> >
> >> ...I'm bringing the
> >> resolution up for an IPMC VOTE...
> >
> > +1 on graduation, but in the following text (which appears twice as
> usual):
> >
> >> ...related to providing a reference implementation of the OASIS Customer
> >> Data Platform specification currently being worked on by the OASIS
> >> Context Server Technical Committee. It provides a high-performance user
> >> profile and event tracking server...
> >
> > I think "It provides a high-performance user profile and event
> > tracking server" is superfluous, we don't want those descriptions to
> > be too specific as projects evolve over time.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Shut down unused/inactive incubator lists

2019-01-21 Thread Myrle Krantz

+1

On Mon, Jan 21, 2019 at 10:44 AM Andy Seaborne  wrote:

> +1
>
>
>
> On 21/01/2019 00:11, sebb wrote:
> > The following lists are all but inactive:
> >
> > announce@ Last post Jan 2008
> > android-interest@ Last post Mar 2011
> > dev@ - only general circulars
> > jaxws-tck@ (private) Last post 2012
> > projects@ Last post Jul 2011
> > user@ - only general circulars
> >
> > I think they should be shut down.
> >
> > Please vote so an Infra Jira can be raised to shut them down.
> > They can have a bounce message added to direct posters to
> > general@/private@ as appropriate
> >
> > [  ] +1
> > [  ] -1 - give a reason please
> >
> > Please vote by end January 2019
> >
> > Sebb.
> >
> > -
> > 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: [IPMC] What to do with retired podling repositories

2019-01-13 Thread Myrle Krantz

If we can’t name a reason for keeping the data, I’d be inclined to just
delete.  We are not data squirrels.

: o),
Myrle

On Sun, Jan 13, 2019 at 10:15 AM Daniel Gruno  wrote:

> Hello IPMC and other folks,
>
> We have a big bunch of retired podlings with git repositories on
> git-wip-us. As we are working on retiring this service, we need to
> address what happens with these old project repositories.
>
> The retired podlings we need to address are:
> blur, cmda, concerted, corinthia, cotton, gearpump, gossip, hdt, horn,
> htrace, iota, mrql, openaz, pirk, provisionr, quickstep, ripple, s4,
> slider, wave
>
> Before February 7th, we at ASF Infra, would love if the incubator could
> decide what happens to these repositories, either individually or as a
> whole.
>
> Some suggested options are:
>
> 1) delete the repositories
> 2) rename them to incubator-retired-$foo.git
> 3) Do nothing, but put a note on github etc that they retired.
> 4) punt it to the attic if possible (you'd have to coordinate with the
> Attic PMC then)
> 5) Something else??
>
> Please talk among yourselves and let Infra know :)
>
> With regards,
> Daniel on behalf of ASF Infra.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Discussion board vs. user mailing list in incubating project

2019-01-13 Thread Myrle Krantz

How’s their discussion board archived?

-Myrle

On Sat, Jan 12, 2019 at 7:01 PM Sebastian  wrote:

> Hi,
>
> I recently received a question from a project that is considering to
> apply to the incubator and I did not know the answer, so I would like to
> ask for your input on that.
>
> The project has a very active web-based discussion board, similar to
> projects like Apache MXNet on https://discuss.mxnet.io/ or Rust on
> https://users.rust-lang.org/. However, Apache projects traditionally
> prefer a user mailing list to web-based discussion boards in my experience.
>
> The question is now whether the project would have to migrate the
> discussion board to the user mailing list during incubation or whether
> they could keep it. Do we have an official stance on that?
>
> Best,
> Sebastian
>
> PS: As a side note, I'd like to mention that the project will have a
> dev@ and private@ mailinglist as usual, this question is only about the
> interactions with users.
>
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Draft incubator report for January 2019

2019-01-11 Thread Myrle Krantz

Hey Justin,

I just signed off weex... and then realized I was signing off on a report
that was already submitted.  Sorry about that.

Best Regards,
Myrle

On Mon, Jan 7, 2019 at 8:55 AM Justin Mclean  wrote:

> Hi,
>
> Currently there's a couple of projects don’t have any sign offs. While we
> have more than a day to go please don't leave it too late. Just a friendly
> reminder any project that doesn't get any sign-off will be asked to report
> next month and the board likes to see more than one sign off.
>
> Podlings missing signoff:
>  - Annotator
>  - BatchEE
>  - Milagro
>
> Podlings with only one sign off:
>  - Senssoft
>  - Weex
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Request incubator wiki admin access

2018-12-29 Thread Myrle Krantz

Thank you Daniel!

On Thu, Dec 27, 2018 at 6:29 PM Daniel Gruno  wrote:

> On 12/27/18 6:22 PM, Myrle Krantz wrote:
> > Sorry, forgot to say that: myrle
>
> You should be good to go now :)
>
> >
> > On Thu, Dec 27, 2018 at 3:52 PM Daniel Gruno 
> wrote:
> >
> >> On 12/27/18 3:44 PM, Myrle Krantz wrote:
> >>> I'd like to be able to give users from the project I'm mentoring write
> >>> access.
> >>>
> >>> Best Regards,
> >>> Myrle
> >>>
> >>
> >> What's your 8exact) wiki username?
> >>
> >> -
> >> 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: Request incubator wiki admin access

2018-12-27 Thread Myrle Krantz

Sorry, forgot to say that: myrle

On Thu, Dec 27, 2018 at 3:52 PM Daniel Gruno  wrote:

> On 12/27/18 3:44 PM, Myrle Krantz wrote:
> > I'd like to be able to give users from the project I'm mentoring write
> > access.
> >
> > Best Regards,
> > Myrle
> >
>
> What's your 8exact) wiki username?
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Request incubator wiki admin access

2018-12-27 Thread Myrle Krantz

I'd like to be able to give users from the project I'm mentoring write
access.

Best Regards,
Myrle

Re: [DISCUSS] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

2018-12-10 Thread Myrle Krantz

+1 gitbox is wonderful.

On Tue, Dec 11, 2018 at 3:33 AM Dave Fisher  wrote:

> +1
>
> Sent from my iPhone
>
> > On Dec 10, 2018, at 6:19 PM, Paul King  wrote:
> >
> > +1
> >
> >> On Tue, Dec 11, 2018 at 6:56 AM Roy Lenferink 
> wrote:
> >>
> >> Hi all,
> >>
> >> The Apache Incubator is still having a repository on git-wip-us as well
> >> [1].
> >>
> >> Does anyone have a problem with moving over the incubator repository to
> >> gitbox voluntarily?
> >> This means integrated access and easy PRs (write access to the GitHub
> >> repo).
> >>
> >> We need to document support for the decision from a mailing list post,
> so
> >> here it is.
> >>
> >> - Roy
> >>
> >> [1] https://git-wip-us.apache.org/repos/asf/incubator.git
> >>
> >> -- Forwarded message -
> >> From: Daniel Gruno 
> >> Date: vr 7 dec. 2018 om 17:53
> >> Subject: [NOTICE] Mandatory relocation of Apache git repositories on
> >> git-wip-us.apache.org
> >> To: us...@infra.apache.org 
> >>
> >> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
> >>  DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> >>
> >> Hello Apache projects,
> >>
> >> I am writing to you because you may have git repositories on the
> >> git-wip-us server, which is slated to be decommissioned in the coming
> >> months. All repositories will be moved to the new gitbox service which
> >> includes direct write access on github as well as the standard ASF
> >> commit access via gitbox.apache.org.
> >>
> >> ## Why this move? ##
> >> The move comes as a result of retiring the git-wip service, as the
> >> hardware it runs on is longing for retirement. In lieu of this, we
> >> have decided to consolidate the two services (git-wip and gitbox), to
> >> ease the management of our repository systems and future-proof the
> >> underlying hardware. The move is fully automated, and ideally, nothing
> >> will change in your workflow other than added features and access to
> >> GitHub.
> >>
> >> ## Timeframe for relocation ##
> >> Initially, we are asking that projects voluntarily request to move
> >> their repositories to gitbox, hence this email. The voluntary
> >> timeframe is between now and January 9th 2019, during which projects
> >> are free to either move over to gitbox or stay put on git-wip. After
> >> this phase, we will be requiring the remaining projects to move within
> >> one month, after which we will move the remaining projects over.
> >>
> >> To have your project moved in this initial phase, you will need:
> >>
> >> - Consensus in the project (documented via the mailing list)
> >> - File a JIRA ticket with INFRA to voluntarily move your project repos
> >>   over to gitbox (as stated, this is highly automated and will take
> >>   between a minute and an hour, depending on the size and number of
> >>   your repositories)
> >>
> >> To sum up the preliminary timeline;
> >>
> >> - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
> >>   relocation
> >> - January 9th -> February 6th: Mandated (coordinated) relocation
> >> - February 7th: All remaining repositories are mass migrated.
> >>
> >> This timeline may change to accommodate various scenarios.
> >>
> >> ## Using GitHub with ASF repositories ##
> >> When your project has moved, you are free to use either the ASF
> >> repository system (gitbox.apache.org) OR GitHub for your development
> >> and code pushes. To be able to use GitHub, please follow the primer
> >> at: https://reference.apache.org/committer/github
> >>
> >>
> >> We appreciate your understanding of this issue, and hope that your
> >> project can coordinate voluntarily moving your repositories in a
> >> timely manner.
> >>
> >> All settings, such as commit mail targets, issue linking, PR
> >> notification schemes etc will automatically be migrated to gitbox as
> >> well.
> >>
> >> With regards, Daniel on behalf of ASF Infra.
> >>
> >> PS:For inquiries, please reply to us...@infra.apache.org, not your
> >> project's dev list :-).
> >>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduate Apache Airflow to TLP

2018-12-05 Thread Myrle Krantz

+1 binding

-Myrle

On Thu, Dec 6, 2018 at 7:37 AM Huxing Zhang  wrote:

> +1  (Non-binding)
>
> On Thu, Dec 6, 2018 at 7:38 AM Jakob Homan  wrote:
> >
> > Hello-
> >
> > The Airflow podling community has VOTEd[0] to graduate, following a
> > very successful DISCUSS[1].  Accordingly I'm bringing the resolution
> > up for an IPMC VOTE.
> >
> > The podling result was:
> > Overall: 21 x +1 votes, 0 x -1 votes
> >
> > Binding +1 x 11: Kaxil, Tao, Bolke, Fokko, Maxime, Arthur, Hitesh,
> > Chris, Sid, Ash, Jakob.
> > Non-binding +1 x 10: Daniel, Shah, Stefan, Kevin, Marc, Sunil,
> > Adityan, Deng, Neelesh, Sai
> >
> > Since entering the Incubator in 2016, the Airflow community has:
> >* successfully produced 7 releases
> >* added 9 new committers/PPMC members
> >* built a diverse group of committers from multiple different
> employers
> >* had more than 3,300 JIRA tickets opened
> >* completed the project maturity model with positive responses[2]
> >
> > Here's my binding +1.  The VOTE will run for at least 72 hours.
> >
> > Thanks,
> > Jakob
> >
> > [0]
> https://mail-archives.apache.org/mod_mbox/airflow-dev/201812.mbox/%3c115b1380-619d-41d7-a30e-9c041cd4d...@gmail.com%3E
> > [1]
> https://lists.apache.org/thread.html/%3c0a763b0b-7d0d-4353-979a-ac6769eb0...@gmail.com%3E
> > [2]
> https://cwiki.apache.org/confluence/display/AIRFLOW/Maturity+Evaluation
> >
> > 
> >
> > Establish the Apache Airflow Project
> >
> > 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, for distribution at no charge to
> > the public, related to workflow automation and scheduling
> > that can be used to author and manage data pipelines.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "Apache Airflow Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that the Apache Airflow Project be and hereby is
> > responsible for the creation and maintenance of software
> > related to workflow automation and scheduling that can be
> > used to author and manage data pipelines; and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Airflow" 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 Airflow Project, and to have primary responsibility
> > for management of the projects within the scope of
> > responsibility of the Apache Airflow 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 Airflow Project:
> >
> > * Alex Guziel 
> > * Alex Van Boxel 
> > * Arthur Wiedmer 
> > * Ash Berlin-Taylor 
> > * Bolke de Bruin 
> > * Chris Riccomini 
> > * Dan Davydov 
> > * Fokko Driesprong 
> > * Hitesh Shah 
> > * Jakob Homan 
> > * Jeremiah Lowin 
> > * Joy Gao 
> > * Kaxil Naik 
> > * Maxime Beauchemin 
> > * Siddharth Anand 
> > * Sumit Maheshwari 
> > * Tao Feng 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Bolke de Bruin
> > be appointed to the office of Vice President, Apache Airflow, 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 Airflow PMC be and hereby is
> > tasked with the creation of a set of bylaws intended to
> > encourage open development and increased participation in the
> > Apache Airflow Project; and be it further
> >
> > RESOLVED, that the Apache Airflow Project be and hereby
> > is tasked with the migration and rationalization of the Apache
> > Incubator Airflow podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache
> > Incubator Airflow podling encumbered upon the Apache Incubator
> > Project are hereafter discharged.
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> --
> Best Regards！
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] - Release Apache Weex (Incubating) 0.20.0 [RC1]

2018-11-27 Thread Myrle Krantz

+1 (binding)

I've checked the following:

* Disclaimer
* License
* Notice
* Compile from source
* Hashes
* Signature (good but signing with an apache email address would be better.)
* Rat checks for headers
* incubating in name

Best Regards,
Myrle


On Mon, Nov 26, 2018 at 3:16 PM Jonathan Dong  wrote:

> Dear IPMC members,
>
> This is a call for the vote to release Apache Weex (Incubating) version
> 0.20.0.
>
> The Apache Weex community has voted and approved a proposal to release
> Apache Weex (Incubating) version 0.20.0, we now kindly request the
> Incubator PMC members to review and vote on this incubator release.
>
> Vote thread:
>
> https://lists.apache.org/thread.html/fa0634ea9936171700a74547cb8541ec4c435db9b9a61a04ca0b3950@%3Cdev.weex.apache.org%3E
>
> Vote result thread:
>
> https://lists.apache.org/thread.html/f8bd059fe324bc7d1c11ed33e9d3c1f70d6c61c0ae7928fef34ead6f@%3Cdev.weex.apache.org%3E
>
> The tag to be voted upon:
> https://github.com/apache/incubator-weex/releases/tag/0.20.0-rc1
>
> Hash for the release tag:
> 97eda0bbd91ee8ac05ca7b81ba73970217467e4a
>
> The source tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.20.0/RC1/apache-weex-incubating-0.20.0-RC1-src.tar.gz
>
> The SHA-512 checksum for the artifact can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.20.0/RC1/apache-weex-incubating-0.20.0-RC1-src.tar.gz.sha512
>
> The signature can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.20.0/RC1/apache-weex-incubating-0.20.0-RC1-src.tar.gz.asc
>
> The artifacts have been signed with Key : EACFA1A9BD14A270, which can be
> found in the keys file:
> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>
> The compilation documentation can be found at:
> https://github.com/apache/incubator-weex/blob/0.20.0-rc1/HOW-TO-BUILD.md
>
> Release note about this version:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320726=12343286
>
> This vote will remain open for at least 72 hours.
> Please vote on releasing this RC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Cheers,
>
> Jonathan Dong
>

Re: [NEW MENTOR REQUIRED] Apache Weex (incubating)

2018-11-21 Thread Myrle Krantz

I would be interested in helping out as a mentor with Weex.

I've never mentored a project before, but I have brought my own project
through the incubator.

Best Regards,
Myrle


On Tue, Nov 20, 2018 at 3:38 AM Willem Jiang  wrote:

> There could be some new IPMC member onboard recently.  It could be
> good opportunity for Weex to look for new mentor.
> I appreciate any help you can provide.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Nov 19, 2018 at 7:54 PM Adam Feng  wrote:
> >
> > +1
> >
> > We would be grateful to anyone who can volunteer time to help. A few of
> us are still
> > new to the ASF processes and need guidance.
> >
> >
> > Thanks.
> > Adam Feng
> > 在 2018年11月14日 +0800 AM11:03，Hanks Zhang ，写道：
> > > +1.
> > >
> > > I also think Weex needs more guidance from more mentors, they can give
> > > advice from different perspectives. On the other hand, most PPMC and
> > > committers of Weex are Chinese, we wish Weex can absorb ideas form
> > > more world-wide developers from different cultures. Looking forward to
> your
> > > opinions.
> > >
> > > Best Regards,
> > > Hanks Zhang
> > >
> > > Jonathan Dong  于2018年11月12日周一 下午7:32写道：
> > >
> > > > Hi Folks,
> > > >
> > > > I’m writing to seek for new motivated mentors for the Apache Weex
> > > > (incubating) project, to drive and mentor the community and project
> to
> > > > graduate.
> > > >
> > > > Weex is a project aims to build high-performance mobile applications
> by
> > > > leveraging mobile web development experience. It was accepted into
> the
> > > > Apache Incubator since Nov. 30, 2016, there are 2 Apache releases
> during
> > > > the incubation period, and 11 PPMC and 3 committers by now. We have
> been
> > > > struggling with the active mentorship which could lead us through the
> > > > podling process and push the project to the graduation, for now we
> only
> > > > have one active mentor Willem Jiang (who helps a lot to grow the
> community
> > > > as well as the processes, thanks), and we believe it’s the right
> time to
> > > > invite one more mentor or two to offload some mentoring duty from
> Willem
> > > > and push us through the graduation.
> > > >
> > > > If you are interested, please let use know at
> > > > d...@weex.incubator.apache.org. Looking forward to your guidance.
> > > >
> > > > Cheers,
> > > >
> > > > Jonathan Dong
> > > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Retire ODF Toolkit

2018-11-18 Thread Myrle Krantz

+1

On Sun, Nov 18, 2018 at 10:35 PM Justin Mclean 
wrote:

> Hi,
>
> +1 Staying in the incubator won't help the project further.
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: How to review so-called "binary releases"?

2018-11-14 Thread Myrle Krantz

On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf 
wrote:

> The answer to (1) depends on the build platform and toolchain.
> Reproducible builds [in the sense of "building the same source twice
> gives bit-for-bit identical binaries"] can help with it.  When the
> answer is negative, the next question is whether those unauditable
> artifacts should be carried by ASF mirrors alongside the source
> artifacts.
>

So if a project puts in the effort to
a.) make their build reproducible (which can actually be very difficult to
do), and
b.) do a bit-for bid compare on a release across at least two build
artifacts, created by different people on different machines...

...would we be willing to see that threat as sufficiently eliminated for
our purposes?  Would we then be willing to "officially" release binaries?

Best Regards,
Myrle

Re: How to review so-called "binary releases"?

2018-11-14 Thread Myrle Krantz

I had understood the reason that the foundation only officially supports
source releases to be the fear of undetected malware in the release (like
in the Ken Thompson hack).

Is that correct?  Are we all are in agreement that the probability of that
kind of hack is very low?

I'd extend that by one step: Isn't the probably of that kind of hack
*lower* if we compile our code ourselves, than if we ask our users to do it?

Best Regards,
Myrle

On Wed, Nov 14, 2018 at 12:08 PM Mark Thomas  wrote:

> 1. Dependencies with inappropriate licenses. Perhaps more likely with
> binary releases because they tend to ship with more dependencies but I
> don't recall this ever being more than "Whoops. Tell the users. Do a new
> release to fix it. Be more careful in future. Carry on." for either
> binary or source releases.
>
> 2. Copyright infringement. The only instance I can recall of this was a)
> related to a source release and b) invalid because the accusing party
> had actually originally copied "their" source from us and removed our
> license headers. If anything, I think issue is less likely with a binary
> release.
>
> 3. Download traffic. Some binaries are large and much more likely to
> cause infrastructure issues if the mirror network is not used correctly.
> Infra has monitoring in place to a) identify issues and b) stop them
> causing outages.
>
> So overall, the liability looks to be well within what we are already
> managing. I don't see anything that concerns me. Unless I have missed
> something.
>
> Mark
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Changing requirements for IPMC

2018-11-08 Thread Myrle Krantz

On Wed, Nov 7, 2018 at 7:10 PM Dave Fisher  wrote:

> Hi -
>
> >> ...I propose this:
> >>
> >> If someone has done several of the following:
> >> - has been involved in an incubating project from start to finish
> >> - has been a release manager
> >> - has assembled LICENSE and NOTICE files
> >> - has reviewed and voted on releases
> >> - has proposed or accepted committers/PPMC members
> >>
> >> Then they can ask the IPMC to join to IPMC by sending an email to
> private@ listing what they have been involved in...
> >
> > I like that, +1
>
> I think that those items are hard to measure and are oriented to release
> policy only.
>
> I would propose a simpler requirement.
>
> - Any PMC member of any TLP including ComDev. We then do formal NOTICE to
> the Board and if there is a concern address it.
>

You're right that some (not all) of the items are hard to measure.  I think
your counter-proposal would just push work to the Board (who simply won't
do it), and may result in podlings getting stuck with inactive mentors, and
limbo'ed releases.  Perhaps it's possible to cut the original list down to
things that are measurable, and change the approach from one of enforcement
to one of enlistment:

* Is willing and able to review and vote on releases for the podling.
* Is willing and able to coach the podling in proposing and accepting
committers/PPMC members.

The real goal here, I think, is not to specify criteria that the IPMC or
the board can apply.  The real goal is two-fold: a.) to give a potential
mentor the information necessary to determine if they can do the job.  And
b.) to create an instrument of commitment.  The mentor commits to involve
themselves in specific ways in the podling's incubation.

Best Regards,
Myrle

[RESULT] [IP CLEARANCE] Mifos I/O -> Fineract CN

2018-04-22 Thread Myrle Krantz

This measure passes by lazy consensus.

Regards,
Myrle

On Wed, Apr 18, 2018 at 11:01 AM, Myrle Krantz <my...@apache.org> wrote:
> Hi,
>
> the Apache Fineract project has received Mifos I/O as a contribution
> and wishes to accept it as Fineract CN.
>
> - A snapshot of the code is available in a github repo. (1)
> - The IP Clearance form has been committed (2).
> - The acceptance vote has passed on the d...@fineract.apache.org
> mailing list (3).
>
> The clearance passes by lazy consensus if no -1 votes are cast within
> the next 72 hours.
>
> Regards,
> Myrle
>
> P.S.  My apologies for getting this to you so late.  We should've done
> this before we started importing the code.  There will be another much
> smaller IP clearance coming called Fineract CN mobile which has also
> already been imported.
>
>
> 1.) https://github.com/mifosio-04-04-2018
> 2.) https://incubator.apache.org/ip-clearance/fineract-cn.html (As of
> this writing, not yet reflecting the updates I just made via SVN to
> add the last two "distribution rights" points.)
> 3.) 
> https://lists.apache.org/thread.html/8a791e91aa1295c84cd51f0429af2fcdada7db57fdb65b4185ea5fc0@%3Cdev.fineract.apache.org%3E
>
>
>
> -- Forwarded message --
> From: Jim Jagielski <j...@jagunet.com>
> Date: Tue, Jan 23, 2018 at 1:18 PM
> Subject: Re: Fineract CN repos filled
> To: d...@fineract.apache.org
>
>
> Let's not forget filling our the IP clearance stuff:
>
> https://incubator.apache.org/ip-clearance/index.html
>
>> On Jan 22, 2018, at 11:27 AM, Myrle Krantz <my...@apache.org> wrote:
>>
>> Hey all,
>>
>> Anyone subscribed to the commits mailing list will have noticed that
>> roughly 600 new commits just hit the fineract repos.  I've just
>> brought the fineract-cn repos in.  There are, however, still some
>> things missing:
>>
>> * pull requests made against mifosio.  There are a couple of open pull
>> requests made against mifosio, by non-committers which I haven't
>> brought in yet.
>> * integration tests Because I'm merging the three integration test
>> repositories into one for this code import, there's a bit more work
>> than just a pull and a push involved.  Please be patient, I'll get
>> them too.
>> * The wikis -- at least one of the repos contains information in its
>> github wiki.  This information will need to be moved into confluence.
>>
>> Apart from that there are some first steps that need to be made:
>> * Update the license header checker in all projects.
>> * Make sure demo-server works against the apache repositories rather
>> than the mifos io repositories.
>>
>> The fun is just starting,
>> Myrle
>> Committer, Apache Fineract

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

[IP CLEARANCE] Mifos I/O -> Fineract CN

2018-04-18 Thread Myrle Krantz

Hi,

the Apache Fineract project has received Mifos I/O as a contribution
and wishes to accept it as Fineract CN.

- A snapshot of the code is available in a github repo. (1)
- The IP Clearance form has been committed (2).
- The acceptance vote has passed on the d...@fineract.apache.org
mailing list (3).

The clearance passes by lazy consensus if no -1 votes are cast within
the next 72 hours.

Regards,
Myrle

P.S.  My apologies for getting this to you so late.  We should've done
this before we started importing the code.  There will be another much
smaller IP clearance coming called Fineract CN mobile which has also
already been imported.


1.) https://github.com/mifosio-04-04-2018
2.) https://incubator.apache.org/ip-clearance/fineract-cn.html (As of
this writing, not yet reflecting the updates I just made via SVN to
add the last two "distribution rights" points.)
3.) 
https://lists.apache.org/thread.html/8a791e91aa1295c84cd51f0429af2fcdada7db57fdb65b4185ea5fc0@%3Cdev.fineract.apache.org%3E



-- Forwarded message --
From: Jim Jagielski <j...@jagunet.com>
Date: Tue, Jan 23, 2018 at 1:18 PM
Subject: Re: Fineract CN repos filled
To: d...@fineract.apache.org


Let's not forget filling our the IP clearance stuff:

https://incubator.apache.org/ip-clearance/index.html

> On Jan 22, 2018, at 11:27 AM, Myrle Krantz <my...@apache.org> wrote:
>
> Hey all,
>
> Anyone subscribed to the commits mailing list will have noticed that
> roughly 600 new commits just hit the fineract repos.  I've just
> brought the fineract-cn repos in.  There are, however, still some
> things missing:
>
> * pull requests made against mifosio.  There are a couple of open pull
> requests made against mifosio, by non-committers which I haven't
> brought in yet.
> * integration tests Because I'm merging the three integration test
> repositories into one for this code import, there's a bit more work
> than just a pull and a push involved.  Please be patient, I'll get
> them too.
> * The wikis -- at least one of the repos contains information in its
> github wiki.  This information will need to be moved into confluence.
>
> Apart from that there are some first steps that need to be made:
> * Update the license header checker in all projects.
> * Make sure demo-server works against the apache repositories rather
> than the mifos io repositories.
>
> The fun is just starting,
> Myrle
> Committer, Apache Fineract

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

Accepting Fineract CN code into TLP Apache Fineract

2017-10-21 Thread Myrle Krantz

Hello Incubator,

The Fineract community just voted to accept mifos I/O code into Apache Fineract.

The code consists of all of the repositories found here:
https://github.com/mifosio

Here's the discussion thread:
https://lists.apache.org/thread.html/ed514d35ffd582c856d5b2e88d4423ad78036e3ed55e278045f7b56e@%3Cdev.fineract.apache.org%3E

Here's the vote thread:
https://lists.apache.org/thread.html/9bab35a9c5bcde6f460afc72d50e1cdecd57c8675abdbaefcc1d48b8@%3Cdev.fineract.apache.org%3E

And here's the vote result:
https://lists.apache.org/thread.html/8a791e91aa1295c84cd51f0429af2fcdada7db57fdb65b4185ea5fc0@%3Cdev.fineract.apache.org%3E

Apache Incubator policy is that all new code enters via the incubator:
https://incubator.apache.org/faq.html

The code currently belongs to the Mifos Initiative.  Ed Cable, CEO of
the Mifos Initiative, is preparing the software grant.  What are our
next steps to get the code accepted by the Apache Software Foundation?

Best Regards,
Myrle Krantz,
Committer, Apache Fineract

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

Re: [DISCUSS] Podlings & Gitbox Usage

2017-07-28 Thread Myrle Krantz

+1 (non-binding)

On Fri, Jul 28, 2017 at 6:05 PM, Suneel Marthi  wrote:
> +1
>
> On Fri, Jul 28, 2017 at 11:48 AM, John D. Ament 
> wrote:
>
>> All,
>>
>> As many are aware, Infra has been rolling out a new service that allows
>> projects to leverage git repositories dually hosted on github and ASF git
>> repositories, commonly known as gitbox.  This effectively allows a project
>> to commit directly to Github and have those commits reflect back on the ASF
>> side.
>>
>> This has been especially useful to a number of projects, since the github
>> interface gives many options for managing repositories.  I've recently also
>> asked infra to open it up to allow any IPMC member to request a gitbox
>> repository for any approved podling that is using gitbox.  Podlings I think
>> have found this useful, since many of them come from a github background.
>> They like using the tool and having it available for all to use.
>>
>> So with that said, I want to propose some broad incubator wide policies for
>> gitbox.  I'd like to propose that gitbox usage is approved for all
>> podlings, there is nothing to inhibit a podling to request a gitbox
>> repository and as long as a podling feels the need to use gitbox, like they
>> would any other tool that we can integrate with, they should be free to use
>> it without any additional approvals required.
>>
>> So please let me know your thoughts.  If I don't hear any -1's I plan to
>> submit an infra ticket early next week to enable the access for all
>> approved podlings.  Please note that your first conversion may need some
>> lead time with infra.
>>
>> Regards,
>>
>> John
>>

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

2017-06-08 Thread Myrle Krantz

Out of curiousity: Do we ever let domains like this expire?

Greets,
Myrle


On Thu, Jun 8, 2017 at 4:55 PM, Chris Mattmann <mattm...@apache.org> wrote:
> Makes sense to me.
>
> Cheers,
> Chris
>
>
>
>
> On 6/8/17, 1:42 AM, "Greg Stein" <gst...@gmail.com> wrote:
>
> On Thu, Jun 8, 2017 at 3:10 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Thu, Jun 8, 2017 at 10:01 AM, Raphael Bircher
> > <rbircherapa...@gmail.com> wrote:
> > > Am .06.2017, 09:43 Uhr, schrieb Bertrand Delacretaz
> > > <bdelacre...@codeconsult.ch>:
> > >> ...Am I missing something?
> > >
> > > Yea, as far as I know it is in a old version who is in the archive,
> > right. I
> > > think this makes some difference...
> >
> > Ah yes you're right, we might want to pull the old binaries from the
> > archive as well, in addition to the changes that I suggested.
> >
>
> In the specific case of Apache Ignite's invocation of that URL and passing
> along certain data ... that is no longer relevant, even for OLD versions,
> as the Foundation currently controls the ignite.run domain (and host). 
> That
> host will no longer resolve, so no HTTP request will be performed, and
> (certainly) no data will be collected from old/new versions of Apache
> Ignite.
>
> Cheers,
> Greg Stein
> Infrastructure Administrator, ASF
>
>
>
>
> -
> 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: Good examples of licensing in ASF produced web apps?

2017-05-29 Thread Myrle Krantz

Hey John,

On Sat, May 27, 2017 at 1:42 AM, John D. Ament <johndam...@apache.org> wrote:
> On Fri, May 26, 2017 at 7:39 PM Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>>
>> However, if somebody can spare me this agony -- I'd appreciate it ;-)
>>
>>
> I believe Fineract would be a good example.  I don't think they're on maven
> central, but you can download them -
> https://dist.apache.org/repos/dist/release/fineract/0.6.0-incubating/apache-fineract-0.6.0-incubating-binary.tar.gz
>
> NOTICE/LICENSE in the root of the distribution + the WAR file (in WEB-INF).
>

Apache Fineract code does not currently contain a UI.  The Mifos
Initiative did not donate the UI because of licensing issues.  Some
colleagues and I at Kuelap are working on a UI we wish to donate to
the project, but it is not yet under Apache's auspices.

Sorry, I can't be of more help,
Myrle

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

Re: Coming to ApacheCON? Showcase your project at a Podling Shark Tank!

2017-04-19 Thread Myrle Krantz

Hi JB,

Last year at ApacheCon EU a nearly graduated project presented at the shark
tank, and I found it quite helpful in starting the graduation process for
Fineract. So IMHO: yes it does make sense. Maybe less for the project
itself, and more for the audience.

Greets,
Myrle


On Wed, 19 Apr 2017 at 07:53 Jean-Baptiste Onofré <j...@nanthrax.net> wrote:

> Hi Roman,
>
> do you think it would make sense to introduce nearly graduated podling,
> explaining the project and the journey in the incubator ? I'm thinking
> about
> Apache CarbonData for example.
>
> Thoughts ?
>
> Thanks
> Regards
> JB
>
> On 04/19/2017 07:10 AM, Roman Shaposhnik wrote:
> > Hi!
> >
> > if you are (or anybody you know who's passionate about your project is)
> > going to travel to Miami for ApacheCON we've got an awesome
> > opportunity for you to showcase your project. Even if you don't have
> > talks scheduled in the regular program, consider doing a lighting talk
> > at Podling Shark Tank:
> >  https://wiki.apache.org/apachecon/ACNA17PodlingSharkTank
> >
> > You've got nothing to lose (in fact, the opposite: you're likely to get
> > a prize!) and you will get a chance to receive feedback that might
> > actually help you grow your community and ultimately graduate to the
> > TLP status. Given our awesome panel of judges:
> >  * Sally Khudairi
> >  * Jim Jagielski
> >  * Justin Mclean
> > We guarantee this to be a fun and useful event for your community!
> >
> > Please sign up on the wiki ASAP. The time is running out!
> >
> > Thanks,
> > Roman.
> >
> > P.S. If you have *any* questions whatsoever, but especially if you have
> > questions on logistics please email me directly.
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[RESULT] [VOTE] Apache Fineract podling graduation

2017-03-27 Thread Myrle Krantz

Hello Incubator,

The vote to graduate Apache Fineract from the incubator passes with 8
binding votes,  2 non-binding votes, and no down-votes

+1 binding: John D. Ament, Daniel Gruno, Bertrand Delacretaz, Roman
Shaposhnik, Niclas Hedhman, Jim Jagielski, Justin Mclean, Tom Barber
+1 non-binding: Pierre Smits, Markus Geiß

(+1 binding votes not carried over from the pre-proposal-correction
vote thread: Jean-Baptiste Onofré, Ross Gardler)

We at Apache Fineract deeply appreciate the expressions of good will
that came together with your votes.

Thank you,
Myrle


On Wed, Mar 22, 2017 at 3:11 PM, Myrle Krantz <my...@apache.org> wrote:
> Greetings Incubator,
>
> I propose that we graduate Apache Fineract from the Incubator.  The
> full text of the proposal is below.
>
> This is a restarted VOTE thread to correct an error in the resolution
> from the original thread. Here's the previous VOTE thread:
>
> [https://lists.apache.org/thread.html/1cbc738bbb4083e50b7772d5226b88d3fe321b91451303a69dbc4fa8@%3Cgeneral.incubator.apache.org%3E]
>
> And here's the DISCUSS thread:
>
> [https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E]
>
>
> Thank you,
> Myrle Krantz
>
>
> Resolution:
>
> Establish the Apache Fineract Project
>
> 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, for distribution at no charge to the
> public, related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Fineract Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby is
> responsible for the creation and maintenance of software
> related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
>
> RESOLVED, that the office of "Vice President, Apache Fineract" 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 Fineract Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Fineract 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 Fineract Project:
>
> * Vishwas Babu AJ <vishwasb...@apache.org>
> * Edward Cable <edca...@apache.org>
> * Markus Geiss <mage...@apache.org>
> * Sander van der Heijden <shey...@apache.org>
> * Ishan Khanna <ishan1...@apache.org>
> * Myrle Krantz <myrl...@apache.org>
> * Terence Monteiro <tere...@apache.org>
> * Adi Nayaran Raju <rajua...@apache.org>
> * Gaurav Saini <gsai...@apache.org>
> * Nazeer Hussain Shaik <naz...@apache.org>
> * Jim Jagielski <j...@apache.org>
> * Michael Vorburger <vor...@apache.org>
>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
> be appointed to the office of Vice President, Apache Fineract, 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 Fineract PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Fineract Project; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Fineract podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Fineract podling encumbered upon the Apache Incubator
> Project are hereafter discharged.

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

[VOTE] Apache Fineract podling graduation (restarted with corrected proposal)

2017-03-22 Thread Myrle Krantz

Greetings Incubator,

I propose that we graduate Apache Fineract from the Incubator.  The
full text of the proposal is below.

This is a restarted VOTE thread to correct an error in the resolution
from the original thread. Here's the previous VOTE thread:

[https://lists.apache.org/thread.html/1cbc738bbb4083e50b7772d5226b88d3fe321b91451303a69dbc4fa8@%3Cgeneral.incubator.apache.org%3E]

And here's the DISCUSS thread:

[https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E]


Thank you,
Myrle Krantz


Resolution:

Establish the Apache Fineract Project

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, for distribution at no charge to the
public, related to a core banking platform that provides a reliable,
robust, and affordable solution for entrepreneurs, financial
institutions, and service providers to offer financial
services to the world's underbanked and unbanked.

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

RESOLVED, that the Apache Fineract Project be and hereby is
responsible for the creation and maintenance of software
related to a core banking platform that provides a reliable,
robust, and affordable solution for entrepreneurs, financial
institutions, and service providers to offer financial
services to the world's underbanked and unbanked.

RESOLVED, that the office of "Vice President, Apache Fineract" 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 Fineract Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Fineract 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 Fineract Project:

* Vishwas Babu AJ <vishwasb...@apache.org>
* Edward Cable <edca...@apache.org>
* Markus Geiss <mage...@apache.org>
* Sander van der Heijden <shey...@apache.org>
* Ishan Khanna <ishan1...@apache.org>
* Myrle Krantz <myrl...@apache.org>
* Terence Monteiro <tere...@apache.org>
* Adi Nayaran Raju <rajua...@apache.org>
* Gaurav Saini <gsai...@apache.org>
* Nazeer Hussain Shaik <naz...@apache.org>
* Jim Jagielski <j...@apache.org>
* Michael Vorburger <vor...@apache.org>


NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
be appointed to the office of Vice President, Apache Fineract, 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 Fineract PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Fineract Project; and be it further

RESOLVED, that the Apache Fineract Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Fineract podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Fineract podling encumbered upon the Apache Incubator
Project are hereafter discharged.

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

Re: [VOTE] Apache Fineract podling graduation

2017-03-22 Thread Myrle Krantz

On Wed, Mar 22, 2017 at 12:51 PM, Jim Jagielski <j...@jagunet.com> wrote:
>
>> On Mar 21, 2017, at 1:35 PM, Myrle Krantz <my...@apache.org> wrote:
>>
>>
>> I've attached a new version of the resolution below with the WHEREAS
>> attached.  Do I need to restart the vote?
>>
>
> For completeness I would, yes, in a whole new VOTE thread.
>

You're right Jim.  Thank you to everyone who has already voted.  I
humbly request that you revote in the new thread I just opened.  This
voting thread is hereby closed without a result.

Greets,
Myrle

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

Re: [VOTE] Apache Fineract podling graduation

2017-03-21 Thread Myrle Krantz

Hi Bertrand,

On Mon, Mar 20, 2017 at 2:17 PM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi Myrle,
>
> +1 to graduating in principle but the project descriptions quoted
> below are inconsistent.
>

You are absolutely correct -- I used Geode's graduation resolution as a
template and missed that one when editing it.  Thank you for catching my
error.

I've attached a new version of the resolution below with the WHEREAS
attached.  Do I need to restart the vote?

Greets,
Myrle

Resolution:

Establish the Apache Fineract Project

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, for distribution at no charge to the
public, related to a core banking platform that provides a reliable,
robust, and affordable solution for entrepreneurs, financial
institutions, and service providers to offer financial
services to the world's underbanked and unbanked.

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

RESOLVED, that the Apache Fineract Project be and hereby is
responsible for the creation and maintenance of software
related to a core banking platform that provides a reliable,
robust, and affordable solution for entrepreneurs, financial
institutions, and service providers to offer financial
services to the world's underbanked and unbanked.

RESOLVED, that the office of "Vice President, Apache Fineract" 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 Fineract Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Fineract 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 Fineract Project:

* Vishwas Babu AJ <vishwasb...@apache.org>
* Edward Cable <edca...@apache.org>
* Markus Geiss <mage...@apache.org>
* Sander van der Heijden <shey...@apache.org>
* Ishan Khanna <ishan1...@apache.org>
* Myrle Krantz <myrl...@apache.org>
* Terence Monteiro <tere...@apache.org>
* Adi Nayaran Raju <rajua...@apache.org>
* Gaurav Saini <gsai...@apache.org>
* Nazeer Hussain Shaik <naz...@apache.org>
* Jim Jagielski <j...@apache.org>
* Michael Vorburger <vor...@apache.org>

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
be appointed to the office of Vice President, Apache Fineract, 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 Fineract PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Fineract Project; and be it further

RESOLVED, that the Apache Fineract Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Fineract podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Fineract podling encumbered upon the Apache Incubator
Project are hereafter discharged.

[VOTE] Apache Fineract podling graduation

2017-03-20 Thread Myrle Krantz

The discussion seems to have died down, so I'm calling the vote:  I propose
that we graduate Apache Fineract from the Incubator.  The full text of the
proposal is below.  The discuss thread can be found here:


[
https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E
]

Thank you,
Myrle



Resolution:

Establish the Apache Fineract Project

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, for distribution at no charge to the
public, related to a data management platform that provides
real-time, consistent access to data-intensive applications
throughout widely distributed cloud architectures.

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

RESOLVED, that the Apache Fineract Project be and hereby is
responsible for the creation and maintenance of software
related to a core banking platform that provides a reliable,
robust, and affordable solution for entrepreneurs, financial
institutions, and service providers to offer financial
services to the world's underbanked and unbanked.

RESOLVED, that the office of "Vice President, Apache Fineract" 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 Fineract Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Fineract 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 Fineract Project:

* Vishwas Babu AJ <vishwasb...@apache.org>
* Edward Cable <edca...@apache.org>
* Markus Geiss <mage...@apache.org>
* Sander van der Heijden <shey...@apache.org>
* Ishan Khanna <ishan1...@apache.org>
* Myrle Krantz <myrl...@apache.org>
* Terence Monteiro <tere...@apache.org>
* Adi Nayaran Raju <rajua...@apache.org>
* Gaurav Saini <gsai...@apache.org>
* Nazeer Hussain Shaik <naz...@apache.org>
* Jim Jagielski <j...@apache.org>
* Michael Vorburger <vor...@apache.org>


NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
be appointed to the office of Vice President, Apache Fineract, 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 Fineract PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Fineract Project; and be it further

RESOLVED, that the Apache Fineract Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Fineract podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Fineract podling encumbered upon the Apache Incubator
Project are hereafter discharged.

Re: [DISCUSS] Apache Fineract podling graduation

On Tue, Mar 14, 2017 at 1:57 PM, John D. Ament <johndam...@apache.org>
wrote:

> On Tue, Mar 14, 2017 at 8:34 AM Myrle Krantz <my...@apache.org> wrote:
>
> > Hey Jon,
> >
> > Cool.  So it'd be something like the text below.  I have a question
> > though.  As initial members, I've included the initial members of the PMC
> > rather than the full list of initial committers.  Was that correct?
> >
> >
> Yes, that is correct.  And sorry, missed the resolution in your initial
> email.


No biggie -- the rest of the incubator needed those templates, so your
harmless oversight had a very positive side-effect.

Re: [DISCUSS] Apache Fineract podling graduation

Hey Jon,

Cool.  So it'd be something like the text below.  I have a question
though.  As initial members, I've included the initial members of the PMC
rather than the full list of initial committers.  Was that correct?

Thanks again,
Myrle

(Quoted from the thread's initial e-mail)
"Establish the Apache Fineract Project


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, for distribution at no charge to the
public, related to a data management platform that provides
real-time, consistent access to data-intensive applications
throughout widely distributed cloud architectures.

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

RESOLVED, that the Apache Fineract Project be and hereby is
responsible for the creation and maintenance of software
related to a core banking platform that provides a reliable,
robust, and affordable solution for entrepreneurs, financial
institutions, and service providers to offer financial
services to the world's underbanked and unbanked.

RESOLVED, that the office of "Vice President, Apache Fineract" 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 Fineract Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Fineract 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 Fineract Project:

* Vishwas Babu AJ <vishwasb...@apache.org>
* Edward Cable <edca...@apache.org>
* Markus Geiss <mage...@apache.org>
* Sander van der Heijden <shey...@apache.org>
* Ishan Khanna <ishan1...@apache.org>
* Myrle Krantz <myrl...@apache.org>
* Terence Monteiro <tere...@apache.org>
* Adi Nayaran Raju <rajua...@apache.org>
* Gaurav Saini <gsai...@apache.org>
* Nazeer Hussain Shaik <naz...@apache.org>
* Jim Jagielski <j...@apache.org>
* Michael Vorburger <vor...@apache.org>


NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
be appointed to the office of Vice President, Apache Fineract, 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 Fineract PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Fineract Project; and be it further

RESOLVED, that the Apache Fineract Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Fineract podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Fineract podling encumbered upon the Apache Incubator
Project are hereafter discharged."

On Tue, Mar 14, 2017 at 1:28 PM, John D. Ament <johndam...@apache.org>
wrote:

> On Tue, Mar 14, 2017 at 8:18 AM John D. Ament <johndam...@apache.org>
> wrote:
>
> > On Tue, Mar 14, 2017 at 8:07 AM Myrle Krantz <my...@apache.org> wrote:
> >
> > Hey Jon,
> >
> > On Tue, Mar 14, 2017 at 11:20 AM, John D. Ament <johndam...@apache.org>
> >  wrote:
> >
> > > Understood.  I think Fineract's ready to go.  What I would recommend as
> > > next steps are to draft a proposal in private and agree to that
> proposal.
> > > Then you can start the incubator vote.  I'll point out this link to you
> > as
> > > well: http://incubator.apache.org/guides/graduation.html#toplevel
> >
> >
> > Thanks for the informal vote of confidence, and thank you for the link.
> >
> > Is the proposal that you're referring to something different than the
> > proposal I attached to start this thread?  If so, can you give an example
> > please?
> >
> >
> >
> > Give me a few.  During the last podling graduation, this question came up
> > as well and it was noted that the resolution template isn't on the
> > website.  That should be the source.
> >
> >
>
> Ok - added the template here:
> http://incubator.apache.org/guides/graduation-template.txt
> And updated
> http://incubator.apache.org/guides/graduation.html#tlp-resolution to
> include a link.
>
>
> >
> > Greets,
> > Myrle
> >
> >
>

Re: [DISCUSS] Apache Fineract podling graduation

Hey Jon,

On Tue, Mar 14, 2017 at 11:20 AM, John D. Ament <johndam...@apache.org>
 wrote:

> Understood.  I think Fineract's ready to go.  What I would recommend as
> next steps are to draft a proposal in private and agree to that proposal.
> Then you can start the incubator vote.  I'll point out this link to you as
> well: http://incubator.apache.org/guides/graduation.html#toplevel

Thanks for the informal vote of confidence, and thank you for the link.

Is the proposal that you're referring to something different than the
proposal I attached to start this thread?  If so, can you give an example
please?

Greets,
Myrle

Re: [DISCUSS] Apache Fineract podling graduation