On Thu, Aug 18, 2016 at 10:37 AM, Eyal Edri <ee...@redhat.com> wrote:
> It will be very and and actually save the infra alot of coding and effort > to stop using this hook, > s very/very easy > 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 <sbona...@redhat.com> > wrote: > >> On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek < >> michal.skriva...@redhat.com> wrote: >> >> > >> > On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbona...@redhat.com> wrote: >> > >> > >> > >> > On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsof...@redhat.com> wrote: >> > >> >> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <ee...@redhat.com> wrote: >> >> > >> >> > >> >> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsof...@redhat.com> >> wrote: >> >> >> >> >> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <ee...@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) > -- 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)
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel