3.6.3 bugs are wrongly moved to MODIFIED
Eyal Edri
eedri at redhat.com
Wed Feb 3 15:04:04 UTC 2016
I've created a new spreadhsheet [1] with existing hooks.
Please review and comment on the current logic, and also on new logic or
new hooks needed.
Once we'll have everything sorted out we can plan how to update any hook if
needed.
[1]
https://docs.google.com/spreadsheets/d/1M-wiXpxX8lWtLRyOv2KZOCMlXJJLHVnWsTuh9_FBpN0/edit?usp=sharing
On Wed, Feb 3, 2016 at 9:15 AM, David Caro <dcaro at redhat.com> wrote:
> On 02/03 08:55, Eyal Edri wrote:
> > Do we have a place where all the current logic of the hooks is described?
> > I can use it as a base and adjust each one to the new logic we need.
>
> Not really, we have the code, but the task to properly document was never
> finished (in part because it's been changing quite often) and the task to
> puppetize has been in the backburner (also because gerrit itself is not in
> puppet, so it's not straight-forward).
>
> The best you can do is go to gerrit through ssh (port 22) and ls
> /home/gerrit2/review_site/git/ovirt-engine.git/hooks.
>
>
> [root at gerrit ~]# ls
> /home/gerrit2/review_site/git/ovirt-engine.git/hooks/change-abandoned.update_tracker
> change-merged.set_MODIFIED
> change-merged.update_tracker
> comment-added.propagate_review_values
> config
> patchset-created.bz.0.has_bug_url
> patchset-created.bz.1.is_public
> patchset-created.bz.2.correct_product
> patchset-created.bz.3.correct_target_milestone
> patchset-created.bz.98.set_POST
> patchset-created.bz.99.review_ok
> patchset-created.update_tracker
> patchset-created.warn_if_not_merged_to_previous_branch
> update_tracker
>
>
> For the config you have:
>
> ## Branches to take into account
> BRANCHES=('ovirt-engine-3.6' 'ovirt-engine-3.6.0' 'ovirt-engine-3.6.1'
> 'ovirt-engine-3.6.2' 'ovirt-engine-3.5' 'ovirt-engine-3.4'
> 'ovirt-engine-3.3' 'engine_3.2' 'engine_3.1' 'ovirt-engine-3.5.2'
> 'ovirt-engine-3.4.0' 'ovirt-engine-3.3.4' 'ovirt-engine-3.3.3'
> 'ovirt-engine-3.3.2' 'ovirt-engine-3.3.1')
>
> STABLE_BRANCHES="ovirt-engine-3.6 ovirt-engine-3.6.0 ovirt-engine-3.6.1
> ovirt-engine-3.6.2 ovirt-engine-3.6.3 ovirt-engine-3.5 ovirt-engine-3.4
> ovirt-engine-3.3 ovirt-engine-3.5.2 ovirt-engine-3.4.0 ovirt-engine-3.3.4
> ovirt-engine-3.3.3 ovirt-engine-3.3.2 ovirt-engine-3.3.1"
>
> CHECK_TARGET_RELEASE=("ovirt-engine-3.6|^3\.[6543210].*"
> "ovirt-engine-3.5|^3\.[543210].*" "ovirt-engine-3.4|^3\.[43210].*"
> "ovirt-engine-3.3|^3\.[3210].*" "ovirt-engine-3.4.1|^3.4.1$")
>
> CHECK_TARGET_MILESTONE=('ovirt-engine-3.6.0|^.*3\.6\.0.*$'
> 'ovirt-engine-3.6|^.*3\.6.*' 'ovirt-engine-3.5|^.*3\.5.*'
> 'ovirt-engine-3.4|^.*3\.4.*' 'ovirt-engine-3.3|^.*3\.3.*'
> 'ovirt-engine-3.4.1|^.*3.4.1.*$')
>
> PRODUCT="oVirt
>
>
> >
> > On Tue, Feb 2, 2016 at 5:19 PM, David Caro <dcaro at redhat.com> wrote:
> >
> > > On 01/28 16:17, Eyal Edri wrote:
> > > > David,
> > > > Is it something manual we need to change per version or we can add
> > > > something automatic to work on any 3.6.X branch only (exluding the
> 3.6
> > > > branch)?
> > >
> > > Can you summarize the complete checks that should be done on the hooks
> > > side? Because it's starting to be a bit of a mess as we are changing
> > > small things each time without the complete knowledge (for example,
> > > the target release was being checked before when moving to MODIFIED,
> > > and that was commented out, and there's a hook to warn if the patch is
> > > not merged yet on a previous branch, like not being merged on 3.6 if
> > > it's on 3.6.x)
> > >
> > >
> > >
> > > >
> > > > e.
> > > >
> > > > On Thu, Jan 28, 2016 at 4:00 PM, Tal Nisan <tnisan at redhat.com>
> wrote:
> > > >
> > > > > 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)
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Eyal Edri
> > > > Associate Manager
> > > > EMEA ENG Virtualization R&D
> > > > Red Hat Israel
> > > >
> > > > phone: +972-9-7692018
> > > > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > >
> > > --
> > > David Caro
> > >
> > > Red Hat S.L.
> > > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > >
> > > Tel.: +420 532 294 605
> > > Email: dcaro at redhat.com
> > > IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> > > Web: www.redhat.com
> > > RHT Global #: 82-62605
> > >
> >
> >
> >
> > --
> > Eyal Edri
> > Associate Manager
> > EMEA ENG Virtualization R&D
> > Red Hat Israel
> >
> > phone: +972-9-7692018
> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Tel.: +420 532 294 605
> Email: dcaro at redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
--
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/20160203/7d502ae7/attachment.html>
More information about the Infra
mailing list