It will be very and and actually save the infra alot of coding and effort to stop using this hook, 

But I really think it will introduce another problem of bugs on POST.

If we can find a logic that will be the silver bullet for all the use cases then lets do it, if not, we have to make sure ALL maintainers are aware they HAVE to monitor bugs in POST

and move then on time, probably will need a WHINE also.

On Thu, Aug 18, 2016 at 10:32 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:

On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek <
michal.skrivanek@redhat.com> wrote:

>
> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
>
>
>
> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer@redhat.com> wrote:
>
>> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri@redhat.com> wrote:
>> >
>> >
>> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer@redhat.com> wrote:
>> >>
>> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri@redhat.com> wrote:
>> >> > I still thinks its a very valuable hook and we are aware of the fact
>> it
>> >> > has
>> >> > bugs,  especially with patches on master branch and 4.0.
>> >> >
>> >> > Shlomi from the infra team is working on a solution for it as we
>> speak
>> >> > and
>> >> > we hope to have a solution in the next few days,  however it's not
>> >> > trival to
>> >> > test and requires setting up a staging env and improve loga for the
>> >> > hooks
>> >> > system.
>> >>
>> >> How do you plan to solve this?
>> >>
>> >> Only the owner of the bug knows if the all the required patches are
>> merged
>> >
>> >
>> > The authors should use Bug-Url on the main bug and related-to: on other
>> > patches that are related.
>>
>> This is not possible. Many times you need series of patches to fix a bug,
>> and
>> you the number of patches may change during development. You start with
>> one
>> patch, and later you find that you need another one, so all of them will
>> have
>> a bug url.
>>
>> Practically, you should expect that all patches in the series will
>> have a bug-url.
>> If the hook will change the bug incorrectly someone will have to fix
>> this, and
>> it is very unlikely that a developer will go to clean after the hook.
>>
>> >> and backported to the correct repositories.
>> >
>> >
>> > This is done with logic according to the bug target milestone.
>> >
>> > for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug
>> targeted to
>> > ovirt-4.0.2.
>> > The hook should check if branch 4.0.2 exists or not, if it exists then
>> the
>> > bug should NOT move to MODIFIED,
>> > since it needs still backporting to ovirt-engine-4.0.2 branch.
>>
>> This is too fragile. For example, maybe a 4.0.2 branch is created after
>> the patch was merged to 4.0 branch, and the patch will be missing,
>> although
>> the bug is already set to modified.
>>
>> Setting to modified should be done by the owner of the bug, after
>> verifying
>> that the patches exists in correct branch.
>>
>> I'm not suggesting to remove the hook, just disable the feature of making
>> a bug modified.
>>
>
> +1. On build day checking that bugs in modified not listed in Bug-Url on
> the build branch due to missing backport is a painful experience.
>
>
> it is a tradeoff. It was mentioned before that the other way around we
> would be left with too many POSTed bugs which are actually already merged

--

Eyal Edri
Associate Manager

RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)