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