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

[Sandro Bonazzola]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170221/ea8624c5/attachment-0001.html>