As long as a RFE is created at some point for tracking the testing and docs
I don't mind letting them in.
If no RFE is created it will get lost and no one will probably use the
feature, which will be a waste of time for the developer working on that.
Feature page can probably be a good option to automate a required url,
since this is also a good option to provide details on the work being done.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 <+972%209-769-2306>
8272306
Email: ydary(a)redhat.com
IRC : ydary
On Tue, Feb 21, 2017 at 1:01 PM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
On Tue, Feb 21, 2017 at 11:56 AM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
>
> On 21 Feb 2017, at 09:36, Eyal Edri <eedri(a)redhat.com> wrote:
>
>
>
> On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
> wrote:
>
>>
>>
>> On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <eedri(a)redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola <sbonazzo(a)redhat.com
>>> > 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
>>>> Devel(a)ovirt.org
>>>>
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
> Devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel