HI, > 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. Thanks, Justin --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
