On Tue, Feb 21, 2017 at 11:56 AM, Michal Skrivanek < [email protected]> wrote:
> > On 21 Feb 2017, at 09:36, Eyal Edri <[email protected]> wrote: > > > > On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola <[email protected]> > wrote: > >> >> >> On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <[email protected]> wrote: >> >>> >>> >>> On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola <[email protected]> >>> wrote: >>> >>>> Hi, >>>> I'm facing a new challenge today, I see new features getting pushed to >>>> oVirt gerrit intentionally out of bugzilla. >>>> The specific case is not really relevant, but just for reference: >>>> https://gerrit.ovirt.org/#/c/65761/ . >>>> Looks like we'll see features getting merged without any RFE opened in >>>> bugzilla for them. >>>> >>> > this is a common case for master, many patches do not have Bug-Url > including features initially > > With current workflow, auto-generating release notes from bugzilla >>>> doc-texts. this means they won't ever be documented. >>>> >>> > true. Typically they don’t have to be as for user consumable features > there is typically many patches, and eventually the final part of feature > do have proper tracking, RFE and so on. > > >>>> I'd like to open this public discussion getting comments about how >>>> things will be handled. >>>> >>> >>> We can start enforcing bug-url in master branch as well, maybe under >>> certain conditions. >>> >> > I do not see the current practice as problematic > > >> The issue here is that the decision is to not use bugzilla and use >> something different like trello. >> So enforcing bug-url will collide with the decision from the feature >> owner team. >> > > If there is an official decision ( I havn't heard on such ) to move to > another issue tracker for some of the projects then it needs to be planned, > > > Some of the projects decided not to use bugzilla. It’s a project decision, > not an “official” decision affecting other projects. > In this case the reason is that a supposed feature triggered a code change > in a side project using bugzilla. > Fair enough for me. > I would say in that case it either deserves a bugzilla on that side > project, or we decide it’s not important, not a substantial part of the > whole feature, and therefore doesn’t need to be documented/tracked in that > side project and use Bug-Url-less commit to master. > > and maybe consider adding tools/verification for the new tools. > > > But it doesn't make sense to start supporting more than one issue tracker, > we have too many systems already, so if we move, then all projects > needs to move. > > > github issue is fairly common so if we want to support something else in > addition to bugzilla Bug-Url this would be a good candidate > > Thanks, > michal > > > >> >> >> >>> >>> >>>> Thanks, >>>> >>>> -- >>>> Sandro Bonazzola >>>> Better technology. Faster innovation. Powered by community >>>> collaboration. >>>> See how it works at redhat.com >>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> [email protected] >>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>> >>> >>> >>> -- >>> Eyal Edri >>> Associate Manager >>> RHV DevOps >>> EMEA ENG Virtualization R&D >>> Red Hat Israel >>> >>> phone: +972-9-7692018 <+972%209-769-2018> >>> irc: eedri (on #tlv #rhev-dev #rhev-integ) >>> >> >> >> >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com >> > > > > -- > Eyal Edri > Associate Manager > RHV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 <+972%209-769-2018> > irc: eedri (on #tlv #rhev-dev #rhev-integ) > _______________________________________________ > Devel mailing list > [email protected] > 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 [email protected] http://lists.ovirt.org/mailman/listinfo/devel
