RE: pip executable expected as part of plugin install.

[D Jayachandran]

Hi Ran,

Sorry I had missed to answer this thread. Just to answer your question wagon 
also expects pip as a binary "/usr/bin/pip".  The above path may not be the 
same for al distros of linux and when the path varies we run into the issue/
As I already told we could probably fix this issue by using pip as library 
instead of a 3PP. 
Please let me know if we can also apply the same fix with wagon as well.

Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Sunday, August 20, 2017 12:40 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: pip executable expected as part of plugin install.

Can you try to explain again what's the issue you're seeing with the way Wagon 
works right now?
We could create a pull request for Wagon as well, but I'm not sure I understand 
the problem at the moment.

On Wed, Aug 16, 2017 at 6:04 PM, D Jayachandran  wrote:

> Even if we fix the issue in ARIA. Wagon library still uses the same 
> logic in finding the pip path and it is wrong.
> Am not sure how to fix this with wagon.
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Thursday, August 03, 2017 5:00 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: pip executable expected as part of plugin install.
>
> Thanks Avia, I will open an issue.
>
> Regards,
> DJ
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Thursday, August 03, 2017 4:01 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: pip executable expected as part of plugin install.
>
> Hi DJ,
> It seems you are correct, I don't see a reason for not using the pip 
> library.
> Maybe it was that way since we didn't want to add pip as a dependency 
> explicitly (this code is from the beginning of ARIA).
>
> Feel free to open an issue about that =)
>
> On Wed, Aug 2, 2017 at 10:19 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Am using a Ubuntu version of linux for my development and ARIA does 
> > not find the correct path of pip during the plugin install.
> > To be precise this happens when pip freeze is executed.
> >
> > @staticmethod
> > def _pip_freeze():
> > """Run pip freeze in current environment and return the output"""
> > bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
> > pip_path = os.path.join(sys.prefix, bin_dir,
> > 'pip{0}'.format('.exe' if os.name ==
> 'nt'
> > else ''))
> > pip_freeze = subprocess.Popen([pip_path, 'freeze'],
> > stdout=subprocess.PIPE)
> > pip_freeze_output, _ = pip_freeze.communicate()
> > assert not pip_freeze.poll()
> > return pip_freeze_output
> >
> > Now the question is why are we executing a pip command directly and 
> > not using pip as a library.
> >
> >
> > Regards,
> > DJ
> >
>

Re: retiring/removal of committers

[Thomas Nadeau]

Jakob/John/Suneel:

Thanks for the perspective. Its important for the community
to understand the philosophy of how Apache operates, which
your notes have done - at least for me. 

—Tom



> On Nov 29, 2017, at 8:57 PM, Jakob Homan  wrote:
> 
> This was an explanation I had previously sent to another podling I mentor:
> 
> 
> (Merit never expiring)  is not a bug.  As ASF sees it, this is a feature:
> https://www.apache.org/dev/committers.html (search for Merit Never
> Expires, an ASF axiom).  As a volunteer organization, we cannot
> require anyone to do anything on any time frame.  Inactive committers
> are in no way a drag on the community.  Instead they are a resource
> that can often be activated when needed with a simple ping.  By virtue
> of having been elected committers or PMCers, they are trusted to know
> when and how to engage with the community when they are able to and in
> such a way that keeps it healthy.  For example, if you've not been
> active for a year, suddenly showing up and +1ing a megabyte patch in a
> bit of code you were never involved in would be a jerk thing to do and
> committers are trusted not to be jerks.  A very large pool of
> committers, of varying activity and contribution is the goal here -
> not a tight, exclusionary group of focused (probably paid) 10x-ers...
> 
> -Jakob
> 
> On 29 November 2017 at 14:42, John D. Ament  wrote:
>> There is one out.  When a podling graduates, its customary to keep everyone
>> on.  However, if there are people who are no longer interested in the
>> project and the project chooses to not include them, its not uncommon that
>> they be left off the graduation.  They would still be open to be included
>> later on if they contribute once again.
>> 
>> John
>> 
>> On Wed, Nov 29, 2017 at 4:26 PM Thomas Nadeau  wrote:
>> 
>>> 
>>>I think that is why we were having it - no one knew about Apache’s
>>> rules around this.
>>> That seems to settle the matter: once you are in, you are in.
>>> 
>>>—Tom
>>> 
>>> 
 On Nov 29, 2017, at 3:42 PM, Suneel Marthi 
>>> wrote:
 
 Fyi... committership never expires in ASF, unless the committer chooses
>>> to
 go Emeritus. So not sure if this discussion is needed.
 
 On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
 wrote:
 
> 
>   One action I took from the last grooming meeting was to
> investigate with the community, what process and policies we want to use
> around the retirement and/or removal of Committers on the project. As
>>> our
> mentors have told us before, the community here is empowered to decide
>>> the
> criteria for how people are voted as committers, and the implication is
> that the reverse is true too. However, after discussing this on our call
> this week, it doesn’t seem there is any criteria defined; therefore, I
> wanted to open up the discussion on this.
> 
>   To start, The Apache PMC guide says this about removal of
> Committers/PMC members:
> 
> [http://www.apache.org/dev/pmc.html#pmc-removal <
> http://www.apache.org/dev/pmc.html#pmc-removal>]
> 
> Projects can establish their own policy on handling inactive members, as
> long as it is applied consistently.
> 
> It is not a problem to retain members of the PMC who have become
>>> inactive,
> and it can make it easier for them to stay in touch with the project if
> they choose to become active again.
> 
> Typically, PMC members who are no longer able to participate will resign
> from the PMC. However, if a PMC chooses to remove one of its members
>>> (i.e.
> without that member's consent), then it must request the Board to make
>>> that
> decision (which is typically done with a resolution at the Board's next
> meeting). The PMC chair should send and email to the board@ mailing
>>> list
> detailing the request for removal and the justification the PMC has for
> that removal, and cc: the project's private@ list.
> 
> 
>   So with that in mind, it looks like we need to augment the
> guidelines Tal started on the wiki [https://cwiki.apache.org/
> confluence/display/ARIATOSCA/Becoming+a+Committer <
> 
>>> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
 ]
> to include removal/retirement/inactive PMC/committers.
> To get the ball rolling, I wanted to make some suggestions for
> (de)selection criteria that I’ve used in other OSS projects:
> 
>   Open Daylight uses this process:
> 
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
> 
>   OPNFV uses this:
> 
> https://wiki.opnfv.org/display/DEV/Committer+Removal <
>