This observer IPMC role sounds interesting. That would make it less intimidating for people who can help verify a generic release but are unfamiliar with the domain itself.
On Mon, Aug 12, 2019 at 03:37, Julian Feinauer <j.feina...@pragmaticminds.de> wrote: > 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 > -- Matt Sicker <boa...@gmail.com>
