>> Instead of having to actually DO releases, at least Release Candidates >> should be created ... this would prove the general ability to do a release, >> but not actually DO it. Of course if these RCs contain bad things, they >> should not pass. > > I suspect in some cases there are repos that maybe never have a > release. In zipkin we felt like we had to do all work and it was a bad > taste to see all this high friction efforts then projects go for > graduation with dozens of repos.. probably some not even looked at. > Whatever it is, I think it should become fair at some point.
In OpenWhisk we do in fact have some repos which will never be released and eventually archived/retired. It’s easier and faster for new ideas to be explored on their own without some of the oversight and reviewer commitments that come with more mature code bases. So creating release candidates prematurely makes no sense in such instances. (Tangentially, working across multiple repos has its own overheads which we have tried to address with better tooling but we aren’t “there” yet.) We have also in OpenWhisk automated a lot of the steps for preparing release candidate and doing some of the mundane checks for verifying a release. I think this has helped evaluators spend their time better judging a release candidate. The feedback has been useful to address how much we automate. -r --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
