+1 1, Each release should be provided with coverage tests. 2. Each release should be provided with vulnerability automated analysis. (sonar/coverity/etc).
El vie., 14 jun. 2019 a las 8:06, Kealan McCusker (<[email protected]>) escribió: > Hi All > > I would like to start a discussion about our contribution guidelines and > how we release the code. I am not sure what is the Apache way, so if the > mentors could please give their opinion that would be great. > > What about doing this; > > # Contributions > > 1. Check for open issues on GitHub or start a discussion around a feature > idea or a bug by sending a mail to [email protected] > 2. Fork the repository to start making your changes. Please use the > "development" branch as a basis. > 3. Write a test which shows that the bug was fixed or that the feature > works as expected. > 4. Send a pull request with a reference to the issue > > # Release > > 1. Only the PPMC members can merge code from development into master > 2. Tag the repo > > I know that their are a lot of steps for a successful release but I am > concerned here with the code base. > > By the way, at the moment I am not following this approach for the crypto > libs but that is only because master is not in a state that could be used > but I will switch to this very shortly. > > Regards > > Kealan > -- Life is a chess game - Anonymous.
