Hi Ted,
dont get me wrong, I'm rather new to the ASF, the incubator and especially the
IPMC. So my perspective might be different. But, I understand the frustration
that some may have and I leant that there have been many trials to change
things which didn’t go the way we wanted.
The "fear" or concerns I have is that loosening some requirements feels a bit
like resigning which would be a horrible thing as the incubator is one of the
(if not the) most important projects in the ASF.
And I don’t object that much with having different classes of releases (its not
elegant but acceptable IMHO) but the thing I'm really concerned about is the
lack of possibilities to learn for podlings.
If we come at the end to the modus operandi of "Yeah, simply release as is but
use this disclaimer or that NOTICE and later in the project we will do it
'right'" that would be pretty bad.
But perhaps I'm too spoiled as I had the luck to be in several podlings with
Justin and Chris Dutz who both took lots of time and did an excellent job in
helping me and all other freshmen to really learn what this Apache Release
policy is about and how to do it right.
And this is something so important that I want every other podling / newcomers
to the ASF to experience.
I know that this might sound provocative and perhaps some people might disagree
but perhaps, if we know that we have not enough "mentor-power" we should be
more careful about picking up new projects in the incubator if we are not sure
how to bring them to TLP successful?
Julian
Am 12.08.19, 17:34 schrieb "Ted Dunning" <ted.dunn...@gmail.com>:
Julian,
I love the sentiment, but increasing the probability of mentor-only
approval by 10x is going to take a lot of something that we haven't had the
last five times we have tried to do this. The current system is a bit
frustrating, but having what amounts to mentors-at-large like Justin and a
few others is the only way we have right now to solve the problem of
inspecting releases (and helping to improve them).
And regarding two level of artifacts, we already have two kinds of podling
release artifacts. Those are releasable and defective (and thus not
releasable). That can't change since it is inherent in the release ground
rules and the fact that incoming podlings don't know the ground rules. The
only change is to make the defective artifacts provisionally releasable.
On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:
> Hi Ted,
>
> but instead of questioning the Bylaws or introducing two classes of
> artifacts I would rather try to improve mentor votes as this is something
> we can do incubator internal.
> And its always better to cure the cause then the symptoms : )
>
> Julian
>
> Am 12.08.19, 16:44 schrieb "Ted Dunning" <ted.dunn...@gmail.com>:
>
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski <j...@jagunet.com>
wrote:
>
> > ...
> > This does NOT mean that the IPMC should be gatekeepers though...
> Just as
> > PMC chairs are the "eyes and ears of the board", mentors are the
> "eyes and
> > ears of the IPMC". The IPMC "vote" should be little more than a
> formality.
> > IMO, if mentors are IPMC members, and there are at least 3 binding
> votes on
> > the podling list, and the mentors are acting as IPMC members when
> they
> > vote, then any other additional vote in the IPMC is not required...
> in
> > essence, consider it like extending the vote for a lazy consensus,
> so to
> > speak:
> >
> >
> > "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> > pointers here). We have 3 (or more) binding votes from mentors. We
> are
> > giving the IPMC and additional 72 hours to vote on said release."
> >
>
>
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
>
> The 10% that do have enough votes can easily follow this process.
>
>
>
