3.6.3 bugs are wrongly moved to MODIFIED

[Tal Nisan]

This was the behavior in 3.6.2, don't know why it changed

On Thu, Jan 28, 2016 at 3:57 PM, Eyal Edri <eedri at redhat.com> wrote:

> so maybe we'll stop moving bugs to MODIFIED if they are merged on stable
> branch (i.e ovirt-engine-3.6) and only if its merged into a version branch
> (i.e ovirt-engine-3.6.3) ?
>
> On Thu, Jan 28, 2016 at 3:52 PM, Tal Nisan <tnisan at redhat.com> wrote:
>
>> It makes life easier for everyone when automation moves the bug to
>> MODIFIED, if the work is not done then the developer can always move it
>> back to POST like we sometimes do.
>> In any way, when a 3.6.3 bug is merged in 3.6.3 it should be moved to
>> MODIFIED, not a second before
>>
>>
>> On Thu, Jan 28, 2016 at 12:23 PM, Yedidyah Bar David <didi at redhat.com>
>> wrote:
>>
>>> On Thu, Jan 28, 2016 at 10:59 AM, Eyal Edri <eedri at redhat.com> wrote:
>>> >
>>> >
>>> > On Thu, Jan 28, 2016 at 10:23 AM, Yedidyah Bar David <didi at redhat.com>
>>> > wrote:
>>> >>
>>> >> On Thu, Jan 28, 2016 at 10:08 AM, Eyal Edri <eedri at redhat.com> wrote:
>>> >> > Maybe we should change the logic on moving bugs to MODIFIED,
>>> >> > Now that we moved to the version branch.
>>> >> >
>>> >> > Tal - any thoughts on a logic that SHOULD move bugs to MODIFIED that
>>> >> > we'll
>>> >> > be sure its OK?
>>> >>
>>> >> Repeating myself from a previous discussion: I think we should never
>>> move
>>> >> bugs from POST to MODIFIED. Only a developer can know if it's indeed
>>> >> ready,
>>> >> or another patch is still needed but was not yet pushed. I think it's
>>> >> safer
>>> >> to miss bugs left on POST although they could have been moved to
>>> MODIFIED,
>>> >> than the opposite - move to MODIFIED bugs that actually require more
>>> work.
>>> >>
>>> >
>>> > You're optimistic that bugs will not stay on POST, we've done it in the
>>> > past.
>>> > This has a bigger risk of bugs getting left behind on POST and
>>> increasing
>>> > the amount of
>>> > bugs that are not verified on time.
>>> >
>>> > Its the easiest solution to drop this bot, but i belive it will do more
>>> > damage than good.
>>>
>>> Perhaps, then, run it once a day and move to MODIFIED only if last patch
>>> was merged at least X hours ago? Hopefully developers will not wait more
>>> than X before pushing an additional patch for the same bug if needed.
>>>
>>> Of course, we then also have to fix the issue starting current thread.
>>>
>>> >
>>> >>
>>> >> >
>>> >> > e.
>>> >> >
>>> >> > On Thu, Jan 28, 2016 at 10:03 AM, Tal Nisan <tnisan at redhat.com>
>>> wrote:
>>> >> >>
>>> >> >> After merging a patch for a 3.6.3 bug on the ovirt-engine-3.6
>>> branch
>>> >> >> the
>>> >> >> bug is moved to MODIFIED, since the 3.6.3 branch was opened
>>> yesterday
>>> >> >> the
>>> >> >> bug should stay in POST until merged in ovirt-engine-3.6.3 branch
>>> as
>>> >> >> well
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Infra mailing list
>>> >> >> Infra at ovirt.org
>>> >> >> http://lists.ovirt.org/mailman/listinfo/infra
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Eyal Edri
>>> >> > Associate Manager
>>> >> > EMEA ENG Virtualization R&D
>>> >> > Red Hat Israel
>>> >> >
>>> >> > phone: +972-9-7692018
>>> >> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>> >> >
>>> >> > _______________________________________________
>>> >> > Infra mailing list
>>> >> > Infra at ovirt.org
>>> >> > http://lists.ovirt.org/mailman/listinfo/infra
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Didi
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Eyal Edri
>>> > Associate Manager
>>> > EMEA ENG Virtualization R&D
>>> > Red Hat Israel
>>> >
>>> > phone: +972-9-7692018
>>> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>>
>>>
>>> --
>>> Didi
>>>
>>
>>
>
>
> --
> Eyal Edri
> Associate Manager
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160128/2fd2f7d6/attachment.html>