
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Martin Sivak" <msivak@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, September 16, 2014 7:10:48 PM Subject: Re: [ovirt-devel] Stable branch gerrit hook and Related-To: bug
On Tuesday, September 16, 2014 11:22:11 AM Martin Sivak wrote:
Well Related-To means exactly what you are proposing where I came from (the platform group, distgit, errata..) :)
But whatever suits you.
Martin
-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
----- Original Message -----
----- Original Message -----
From: "Martin Sivak" <msivak@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "David Caro" <dcaroest@redhat.com>, devel@ovirt.org Sent: Tuesday, September 16, 2014 3:53:53 PM Subject: Re: [ovirt-devel] Stable branch gerrit hook and Related-To: bug
What if gerrit used the dependency info and would not -1 patches that are dependency of a patch with a bug url?
That is not a bad idea, but there is one use case you do not consider.. it would mean that feature cannot be merged before it is completed.
I like my patches to be merged as soon as possible. Of course if the patches leave the tree in working state.
Right
The patchset that started this thread already depends on about 15 patches that were merged to master two moths ago.
So how about:
Required-For: https://bugzilla.redhat.com/1096197
You must merge this to get the bug fixed, but the bug status is not changed when merged.
The hook can add the patch to the bug as a tracker.
David, can we easily add such tag? stuff that's
No problem, but can you please summarize what needs to be done for each? If you open a track ticket with that info even better :)
- When patch created (move bug to POST, add external tracker, other....) - When patch merged (move bug to post if not more open external patches) - Same checks that with Bug-Url (good product, target release for stable branch, public bug, ...)
* About the Related-To tag * About the Required-For tag
The Related-To is enough, there's no need for such over-head, it will just create unnecessary extra work for David/Marin and confusion between the specific tag usage. Let's keep it simple. Sometimes we just write patches that don't fix the bug, but we need them merged in order to write more patches that actually fix the bug. We just need to define what we need them to do, which is - 1. Adding the patches as a tracker to the bz is a nice-to-have. 2. We must be able to merge them into the stable branch. 3. They may change the bz to post but never to modified. Let's not forget that in special cases we can always manually change the bz state. The common case for the Related-To patches can be handled as mentioned above. Vered
Thanks!
NIr
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel