I'm answering to this (old) thread as the new one branched up with a different 
Personally, during my time in the first podling I learned a lot by doing Apache 
First, as contributor, then as PPMC and finally as RM.
And this is something valuable and if a project wants to become a TLP something 
people have to learn.
And not only one or two but better every PPMC member (and some even able to RM).

So I suggest to encourage Podlings as much as possible to to ASF releases.
I would suggest to solve all the current issues by setting the rules up in a 
way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC Vote 
which are then carried over and make the IPMC Vote basically "lazy consensus".

To do this I would suggest to set up / change the "Mentor Guideline" that a 
Mentor "should" vote on PPMC releases.
Furthermore, in addition to 3 (active?!) Mentors we could add 2-3 "assessors" 
or "observers" (from the IPMC) who do not help actively but are on the list and 
whos dutie is to support Releases.
That would make a pool of 5-6 IPMC members for each podling which should be 
encouraged to VOTE on releases.

Then, we could, step by step, tackle podlings to bring their Vote to the IPMC 
only if they have 3 +1 votes.

This would allow us to keep all global rules of the ASF as is and only change 
Incubator "internals".
I think we should really start to see Mentoring as something which needs time 
and work and which people should only call in if they feel like they can do.
For everything else we could have this "observer" role where people that find 
the project interesting could simply take to watch and monitor it but with 
their Votes also help the incubator a lot.


Am 12.08.19, 02:46 schrieb "Greg Stein" <gst...@gmail.com>:

    On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <jus...@classsoftware.com>
    > Hi,
    > > I see no problem with using our infrastructure to distribute F/OSS
    > > materials. Why would the Foundation want to be against that? If it is
    > > labeled properly, then ... roll with it.
    > It often isn’t labelled properly.  There’s a reasonable risk that some of
    > what would be placed there and distributed isn’t actually F/OSS.
    And what would be the blowback of something on our server with incorrect
    information? Very little. Mostly, we'd just move on. Maybe we delete it.
    > I can point you to several example of this. I’m not sure how the incubator
    > (or the board) would feel about that risk, so that would be something we
    > would be need to consider further. Also
    Welp. Then I will pose that question, rather than this endless
    pontificating about "risk".
    > while Jane and John may be fine with that, a lot of companies that use
    > Apache releases may not be.
    I already acknowledged that. Many people could use software regardless of
    its licensing. The license typically only matters in *redistribution*
    scenarios. Things like the AGPL affect *usage*, but that is very, very
    atypical. I'd think 99% of downstream could use our software, even with
    gummed-up licensing.
    > > You're conflating *learning* with *releases*. These can be handled
    > separately.
    > How exactly?
    You're saying that releases are the control point to learning. I say just
    let the releases go.
    You want to teach? Then you can use the releases like "that wasn't good.
    next time: do A and B". Over time, releases will get fixed. But the IPMC
    should not have to manage the releases.

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

Reply via email to