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. > The maintainer is typically not the assignee so if you e.g. merge the last > patch on Thursday afternoon it takes some time to gets attention, in the > meantime there is a build which won’t consider that bug. > > The other way around is having a modified bugs which should have been in post being considered in the build, moved to QE, failing QE, move back to assigned. Not sure it's much better. > > > > >> >> Nir >> > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
