> 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] > <mailto:[email protected]>> wrote: > > > On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <[email protected] > <mailto:[email protected]>> wrote: > > > On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola <[email protected] > <mailto:[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/ <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. 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 <http://redhat.com/> > _______________________________________________ > Devel mailing list > [email protected] <mailto:[email protected]> > http://lists.ovirt.org/mailman/listinfo/devel > <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 <tel:+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 <http://redhat.com/> > > > -- > 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
