On 3/6/19 4:47 PM, Ross Gardler wrote:
Merit does not expire. People who are not active today should be able to become
active tomorrow without having to jump through approval hoops.
In projects there is no concept of emeritus PMC. Here in the IPMC the issue is
very different. Most people earn merit transitively - become a member, become a
mentor, become an IPMC member. It's different.
Please don't use what is being discussed here as being transitive to a PMC
based entirely on directly earned merit.
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.
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Dmitriy Pavlov <dpav...@apache.org>
Sent: Tuesday, March 5, 2019 4:46:09 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs
check (was: .... introduce "[DISCUSS]" threads for podling ... release
candidates))
I absolutely agree with Greg Stein. I can't find any single reason to keep
unsubscribed members of IPMC in the roster. These members can be asked to
subscribe, and if they do, then ok; if don't - it is perfectly ok to remove.
Similarly, I don't see reasons for having inactive TLP PMC members. I've
suggested the same change in Apache Ignite, but I don't clearly understand
why remained members resisting this change.
пн, 4 мар. 2019 г. в 09:58, Ross Gardler <r...@gardler.me>:
That's right Greg. And since we are filling in gaps for people...
I was originally against the pTLP concept (though I supported the
experiments) or any of the derivatives that came from it. I think I have
changed my position. Largely based on the fact that every single project
I've discussed the ASF with in the last 3-5 years has had a very inaccurate
perception of how the ASF works. I believe a large part of this is due, in
part, to the issues being discussed in this thread.
I do not understand how a foundation which prides itself in having very
little bureaucratic red tape can be seen as having so much red tape. The
projects I talk to just want to build software. It used to be that the ASF
focused on running the legal and operational aspects of the foundation
projects and developers on projects wrote code. I'm not sure that's true
anymore.
We need to fix it.
I look forward to hearing how the IPMC will seek to strip down the
bureaucracy and get back to mentoring the incoming projects on how the ASF
is structured so they can get (relatively) quick and clear answers to their
questions.
Ross
________________________________________
From: Greg Stein <gst...@gmail.com>
Sent: Sunday, March 3, 2019 10:19 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
... release candidates))
On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <r...@gardler.me> wrote:
If a podling is a committee in its own right then it can be empowered to
act on behalf of the board and this its releases can be an act of the
foundation.
...
Podlings would only become full TLPs once they have demonstrated their
ability to do formal releases.
The above pair of concepts was offered in $priorCycle as "provisional TLPs"
(pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
trusted, then why not just call it a TLP and trust it to label its releases
appropriately? Thus, just create TLPs immediately for a "podling"
[ I know Ross knows this; but for $others who may want to look at
historical proposals, and compare/contrast to current discussion ... search
for "pTLP" ]
Cheers,
-g
---------------------------------------------------------------------
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
