Hi Dmitry, do you have a specific proposal for naming convention ? The example from Sentry had a simple revised versions of patches. We have to think of release branches as well. I don't have a strong preference on the current naming convention but just want to make sure that 1. easy for contributors to follow 2. and test-patch job for trunk and release branches ( test-job for release branches are not in place yet) can identify which patch to apply which branch.
On Mon, Oct 13, 2014 at 8:17 AM, Dmitry Lysnichenko < [email protected]> wrote: > Hi all, > > As of now, at > > https://docs.google.com/a/hortonworks.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit?pli=1 > we > have the following patch naming convension: > For trunk, AMBARI-<ID>.patch[.VERSION] > For release branches, AMBARI-<ID>_[BRANCH].patch[.VERSION] > where [.VERSION] is optional but should be added for revised patches. > > The issue with this format is that software that makes use of file > extensions instead of header magic does not recognize *.patch.1 files as > patch files. For example, IntelliJ IDEA refuses to apply patch (the OK > button is disabled). I'm aware of git-apply command, but using IDE often > simplifies process. > How about changing naming conversion (e.g. other Apache project: > > https://cwiki.apache.org/confluence/display/SENTRY/How+to+Contribute#HowtoContribute-ProvidingPatches > )? > > -- > Thanks, > Dmitry > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. > -- -jun
