[ovirt-devel] [REQUEST FOR COMMENTS] oVirt features tracking and documentation

[Yaniv Dary]

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 at redhat.com
IRC : ydary


On Tue, Feb 21, 2017 at 1:01 PM, Sandro Bonazzola <sbonazzo at redhat.com>
wrote:

>
>
> On Tue, Feb 21, 2017 at 11:56 AM, Michal Skrivanek <
> michal.skrivanek at redhat.com> wrote:
>
>>
>> On 21 Feb 2017, at 09:36, Eyal Edri <eedri at redhat.com> wrote:
>>
>>
>>
>> On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola <sbonazzo at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <eedri at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola <sbonazzo at 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 at 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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170222/0c50455e/attachment.html>