incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Podling releases and release policy
Date Sat, 01 Jun 2019 04:46:37 GMT

> Before putting it to the board, have we ever had a IPMC vote on the matter?

Sure if you think one is needed, but probably best to have some discussion about it first.

> So perhaps if we set an incubator policy of a podling release being a
> little more lenient

We do not own the release policy so I don’t think we can change it like that, but we could
ask the board to do so.

We are already lenient on minor issues (missing headers, missing stuff in licenses and the
like), this is more about the more serious issues, see for example the vote today on Tuweni.
I don’t think we can ignore these without board permision to ignore their release policy.
It may be that having that DISCLAIMER is good enough for them to be OK with that.

For instance a podling a few months back went directly to board when we voted -1 on their
release for including a jar in it and we’ve had some people express the opinion that everything
is allowed in a release if it's fixed before the project graduates. Again I’m not sure we
can do that without the board’s permission given it's their policy not ours. There has only
been a couple of cases where  this has come up given most podlings cancel the vote and make
another release when a serious issue is found / someone IPMC member votes  -1 on a release.

> Perhaps we need a podling disclaimer for all podling releases that
> explains more about what is a podlings and what is an incubating
> release. 

That a good idea and  having a list of know issues that are being worked on in the release
sounds like it would help. Quite often the podling may not be aware of the issues until the
IPMC finds them, possibly related to mentor engagement, or where there is a conflict of interest
that might cloud mentors judgment.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message