What the new gerrit hoks will do

[Ayal Baron]

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Ayal Baron" <abaron at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "David Caro" <dcaroest at redhat.com>, arch at ovirt.org
> > Sent: Wednesday, July 31, 2013 1:05:27 PM
> > Subject: Re: What the new gerrit hoks will do
> > 
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "David Caro" <dcaroest at redhat.com>
> > > > To: "Itamar Heim" <iheim at redhat.com>
> > > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org
> > > > Sent: Wednesday, July 31, 2013 11:01:20 AM
> > > > Subject: Re: What the new gerrit hoks will do
> > > > 
> > > > On 07/31/2013 09:24 AM, Itamar Heim wrote:
> > > > > On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I don't think it is good to have auto POST/MODIFIED.
> > > > >> As there can be more than one patch per bug.
> > > > > 
> > > > > i think post is still correct.
> > > > > modified will only move if all patches with this bug-url are merged
> > > > > iiuc.
> > > > > a new patch with same bug-url will move the bug back to POST.
> > > > 
> > > > Right, I forgot to clarify that only those bugs with all their external
> > > > tracked patches closed will be changed to MODIFIED.
> > > 
> > > And if it takes 3 or 4 weeks to post the other patch?
> > 
> > If your patch does not solve the bug entirely then it should not have
> > Bug-url, rather 'Related-To: XXXXXX
> > And if this patch needs the others to complete the job then it should
> > depend
> > on them (i.e. patch set).
> > Only the last patch should be marked with bug-url as only after it (and the
> > patches it depends on) are merged the bug is really solved.  The reason is
> > that maintainer would do an even worse job than this script in tracking
> > whether all patches required for solving a bug have been merged.
> 
> Related-To are other bugs and changes that are related to the actual fixing.

Exactly, if a fix isn't solving the bug entirely but is related to it then it should have 'Related-To'.

> A fix can have many components and can be broken into smaller parts to ease
> review or even because it is split between deferent repositories.
> It also need to pull some other unrelated patches to ease rebasing.
> And finally, we are humans, and we do not always know that whatever we are
> doing is correct and last.

Not sure how all this is related to what I said. There are definitely cases where you want to write multiple patches to solve an issue, that is indeed the use case we are discussing here.
The process is very simple, makes maintainer's life simpler and reduces chances of error, plus allows for automating things:
If you have a bug which you solve in a series of patches then you make a patch set where only the last patch (which is dependent on the rest) is marked with Bug-Url and all the other patches have 'Related-To'.  This way all the confusion and errors that you discussed before disappear.


> 
> > 
> > > 
> > > > 
> > > > > 
> > > > >>
> > > > >> Alon
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "David Caro" <dcaroest at redhat.com>
> > > > >>> To: arch at ovirt.org
> > > > >>> Sent: Tuesday, July 30, 2013 10:02:46 PM
> > > > >>> Subject: What the new gerrit hoks will do
> > > > >>>
> > > > >>> Hi all!
> > > > >>>
> > > > >>> As promised here's an explanation of what the hooks will take care
> > > > >>> of:
> > > > >>>
> > > > >>> When a patch is submitted:
> > > > >>>    If the commit message has Bug-Url tag:
> > > > >>>      - for each Bug-Url:
> > > > >>>        * Check that the bug is public
> > > > >>>        * Add an external tracker to the patch if not there already
> > > > >>>        * Move the bug status to POST
> > > > >>>      - Report back the result of all the previous actions
> > > > >>>      - Review with +1 if the bug was public, -1 if it was private
> > > > >>>
> > > > >>> When a comment is added:
> > > > >>>    If the "Rerun-Hooks: all" line was added:
> > > > >>>      - Rerun all the hooks that ran when the hook was submitted
> > > > >>>
> > > > >>> When a patch is submitted:
> > > > >>>    If the commit message has Bug-Url:
> > > > >>>      - For each Bug-Url:
> > > > >>>        * Check if the product for the bug is correct
> > > > >>>        * If it was, move the bug status to MODIFIED
> > > > >>>
> > > > >>> Keep in mind that this is a first step towards automation of the
> > > > >>> whole
> > > > >>> process.
> > > > >>>
> > > > >>> Also, as always any input, ideas, or even complaints are welcome :)
> > > > >>>
> > > > >>> pd. Yes I will add this and more info to the wiki as soon as I have
> > > > >>> some
> > > > >>> spare time to do it.
> > > > >>>
> > > > >>> --
> > > > >>> David Caro
> > > > >>>
> > > > >>> Red Hat Czech s.r.o.
> > > > >>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > > >>>
> > > > >>> Tel.: +420 532 294 605
> > > > >>> Email: dcaro at redhat.com
> > > > >>> Web: www.cz.redhat.com
> > > > >>> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> > > > >>> RHT Global #: 82-62605
> > > > >>>
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> Arch mailing list
> > > > >>> Arch at ovirt.org
> > > > >>> http://lists.ovirt.org/mailman/listinfo/arch
> > > > >>>
> > > > >> _______________________________________________
> > > > >> Arch mailing list
> > > > >> Arch at ovirt.org
> > > > >> http://lists.ovirt.org/mailman/listinfo/arch
> > > > >>
> > > > > 
> > > > 
> > > > 
> > > > --
> > > > David Caro
> > > > 
> > > > Red Hat Czech s.r.o.
> > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > > 
> > > > Tel.: +420 532 294 605
> > > > Email: dcaro at redhat.com
> > > > Web: www.cz.redhat.com
> > > > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> > > > RHT Global #: 82-62605
> > > > 
> > > > 
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > 
>