incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: [DISCUSS] IPMC votes on releases
Date Mon, 12 Aug 2019 13:41:16 GMT
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.feinauer@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" <gstein@gmail.com>:
>
>     On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <
> justin@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message