@Aleksandr: it seems you are right, after my first broken commit message I was careful not to mess them up again and I didn't even notice that this check was turned off. Just curious: why was it turned off?
On Wed, Jul 29, 2015 at 11:24 AM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Guys, > > How do you suppose to know that only commit message was changed? Do > you want to implement manual comparison between patch sets?! > > Currently Gerrit checks whether patchset was changed or not by > tracking Git commit SHA1 sum, and, btw, chaning commit message will > lead to changing commit sha1 sum. > > So it looks pretty tricky to implement, and it may lead to false > positive results. > > Thanks, > Igor > > On Wed, Jul 29, 2015 at 12:06 PM, Sergii Golovatiuk > <sgolovat...@mirantis.com> wrote: > > I agree with Maciej > > > > 1. Simple change in CommitMessage shouldn't spin up CI check > > 2. There should be simple task where we check "Implements: blueprint" or > > "Closes-Bug:" or Related-Bug:" to set -1 automatically > > 3. There can be additional checks like Short Summary should be 50 or less > > symbols. Long summary should be wrapped to 80 symbols > > > > > > -- > > Best regards, > > Sergii Golovatiuk, > > Skype #golserge > > IRC #holser > > > > On Wed, Jul 29, 2015 at 10:58 AM, Aleksandr Didenko < > adide...@mirantis.com> > > wrote: > >> > >> Hi, > >> > >> > I think that checking commit message compliance to commit message > >> > guidelines (for example ending the first line with dot) is part of CI > jobs, > >> > and they will vote -1 if message is wrongly structured. > >> > >> > >> Maciej, we don't have such checks at the moment. You can craft any > commit > >> message you want and it will not cause any problems with CI. I think, > >> reviewers could do the job on commit message verification and they > already > >> do this :) > >> > >> Regards, > >> Alex > >> > >> > >> On Wed, Jul 29, 2015 at 11:23 AM, Sergey Vasilenko > >> <svasile...@mirantis.com> wrote: > >>> > >>> -1 to Maciej > >>> +1 to Sergii > >>> > >>> > >>> > >>> /sv > >>> > >>> > >>> > >>> > __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev