potiuk commented on PR #28: URL: https://github.com/apache/airflow-client-go/pull/28#issuecomment-1368540897
I actually feel a bit uneasy about it - I strongly believe we should change the approach here. And very same with the python client. (@DrFaust92 it's not that I do not trust you personally, but I think in this case we are violating some basica principles of the ASF security rules). It makes very litle sense to generate and commit the code for the clients as part of this repo. It is impossible to review manually and there might be some code that is manually modifed by whoever generates the code. And if we release it officially, we should be able to track provenence of that code - so the whole toolchain should be running automaticaly WHEN we release Airflow automatically, rather than having code kept in a separate repository. I believe we are simply not compliant with Apache Release process - we should never release a code that has not been verified by a human - and this code is not verifiable. We do not know if it has been fully generated or someone has tampered with it. Also I think it goes hand-in-hand with what has been discussed by @pierrejeambrun in https://github.com/apache/airflow/pull/28521 IMHO all client generation scripts MUST be part of the airflow code and both generation of all the code and package we release MUST be done automatically by the release process and release manager should do it as parat of the release. Otherwise we will have to deal with those kind of unreviewable PRs that contain POSSIBLY automatically generated code - but we do not know it for sure. If it was the same as for DOC on our website, that would be no problem - but this code is released to our users as "apache" code and put in the hands of our users so IMHO we cannot release such package if it is not automatically generated by the release manager. It the code is submitted as unreviewable PR by someone who could have tampered with it and we have no way to reasonably verify it, we should not release it. IMHO. Since the code is automatically generated anyway, adding automated pipeline to generate those is the only way to do it "properly". I think the only way is to generate the clients as part of our CI in Airflow repo (to verify it works), and also make it part of release-management process to build such packages rather than submit the code as PR to the "airflow-client-go" or "airflow-client-python" repos (possibly as another `breeze release-mangement` command). @msumit @jedcunningham @ephraimbuddy @eladkal @pierrejeambrun @ashb @kaxil - as previous or current release managers or people involved with it WDYT about it? IMHO we've been ignoring it for a while, but since @pierrejeambrun raised the devlist discussion about it and we already have LAZY CONSENSUS about it https://lists.apache.org/thread/1zp9wdxl9y1nnrsvk4yn9rd1r10xx5yj - I think we cannot ignoree it any more and we should do it "well" according to the ASF rules (and common sense regarding the security - because in this case I think there is no other choice). Unless, of course, somoene has an idea how to solve it differently? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
