Hi,
I'm answering to this (old) thread as the new one branched up with a different
topic.
Personally, during my time in the first podling I learned a lot by doing Apache
Releases.
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.
Julian
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>
wrote:
> 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.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
