[prev in list] [next in list] [prev in thread] [next in thread]
List: vdsm-devel
Subject: Re: [ovirt-devel] [REQUEST FOR COMMENTS] oVirt features tracking and documentation
From: Yaniv Dary <ydary () redhat ! com>
Date: 2017-02-26 13:53:02
Message-ID: CACKMAy-8vviv=-6vh2hNtwkHV++-=SEn=9Bb6UrsbHZyGatBsQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
If we want users to touch features we need someone at some point to open a
BZ on it. It doesn't have to be the contributor.
GitHub pull requests or any other code related tracking is good only to the
developer level, not docs\user\QE.
Thanks,
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary@redhat.com
IRC : ydary
On Wed, Feb 22, 2017 at 5:26 PM, Martin Sivak <msivak@redhat.com> wrote:
> How are we going to track possible contributions from the community?
> Those won't have any bugzilla associated in general. And we want them
> and we want to lower the hurdle for other people to contribute.
> Especially for the side projects we have (the engine is quite a beast,
> but we have smaller or new projects where it is not that hard to
> contribute).
>
> Projects using GitHub track everything using pull requests. Those
> generally serve as the umbrella for all the associated changes and
> issues. We do not have anything like that. Bugzilla maps to issues and
> Gerrit changes map to the code part of pull requests. We do not have
> the documentation and design in the sources either so we can't check
> for those to be provided together with the patch.
>
> --
> Martin Sivakl
> oVirt / SLA
>
> On Wed, Feb 22, 2017 at 3:43 PM, Yaniv Dary <ydary@redhat.com> wrote:
> > 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
> > 8272306
> > Email: ydary@redhat.com
> > IRC : ydary
> >
> >
> > On Tue, Feb 21, 2017 at 1:01 PM, Sandro Bonazzola <sbonazzo@redhat.com>
> > wrote:
> >>
> >>
> >>
> >> On Tue, Feb 21, 2017 at 11:56 AM, Michal Skrivanek
> >> <michal.skrivanek@redhat.com> wrote:
> >>>
> >>>
> >>> On 21 Feb 2017, at 09:36, Eyal Edri <eedri@redhat.com> wrote:
> >>>
> >>>
> >>>
> >>> On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola <
> sbonazzo@redhat.com>
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <eedri@redhat.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola
> >>>>> <sbonazzo@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@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
> >>>>> 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
> >>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >>> _______________________________________________
> >>> Devel mailing list
> >>> Devel@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@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
[Attachment #5 (text/html)]
<div dir="ltr">If we want users to touch features we need someone at some point to \
open a BZ on it. It doesn't have to be the contributor.<div>GitHub pull requests \
or any other code related tracking is good only to the developer level, not \
docs\user\QE.</div><div><br></div><div>Thanks,<br><div class="gmail_extra"><div><div \
class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72"><span \
style="font-family:arial,helvetica,sans-serif">Yaniv Dary Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: <a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Feb 22, 2017 at 5:26 PM, Martin Sivak <span \
dir="ltr"><<a href="mailto:msivak@redhat.com" \
target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">How are we going to track possible contributions \
from the community?<br> Those won't have any bugzilla associated in general. And \
we want them<br> and we want to lower the hurdle for other people to contribute.<br>
Especially for the side projects we have (the engine is quite a beast,<br>
but we have smaller or new projects where it is not that hard to<br>
contribute).<br>
<br>
Projects using GitHub track everything using pull requests. Those<br>
generally serve as the umbrella for all the associated changes and<br>
issues. We do not have anything like that. Bugzilla maps to issues and<br>
Gerrit changes map to the code part of pull requests. We do not have<br>
the documentation and design in the sources either so we can't check<br>
for those to be provided together with the patch.<br>
<br>
--<br>
Martin Sivakl<br>
oVirt / SLA<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On Wed, Feb 22, 2017 at 3:43 PM, Yaniv Dary <<a \
href="mailto:ydary@redhat.com">ydary@redhat.com</a>> wrote:<br> > As long as a \
RFE is created at some point for tracking the testing and docs<br> > I don't \
mind letting them in.<br> > If no RFE is created it will get lost and no one will \
probably use the<br> > feature, which will be a waste of time for the developer \
working on that.<br> > Feature page can probably be a good option to automate a \
required url, since<br> > this is also a good option to provide details on the \
work being done.<br> ><br>
> Yaniv Dary<br>
> Technical Product Manager<br>
> Red Hat Israel Ltd.<br>
> 34 Jerusalem Road<br>
> Building A, 4th floor<br>
> Ra'anana, Israel 4350109<br>
><br>
> Tel : <a href="tel:%2B972%20%289%29%207692306" value="+97297692306">+972 (9) \
7692306</a><br> > 8272306<br>
> Email: <a href="mailto:ydary@redhat.com">ydary@redhat.com</a><br>
> IRC : ydary<br>
><br>
><br>
> On Tue, Feb 21, 2017 at 1:01 PM, Sandro Bonazzola <<a \
href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>><br> > wrote:<br>
>><br>
>><br>
>><br>
>> On Tue, Feb 21, 2017 at 11:56 AM, Michal Skrivanek<br>
>> <<a href="mailto:michal.skrivanek@redhat.com">michal.skrivanek@redhat.com</a>> \
wrote:<br> >>><br>
>>><br>
>>> On 21 Feb 2017, at 09:36, Eyal Edri <<a \
href="mailto:eedri@redhat.com">eedri@redhat.com</a>> wrote:<br> >>><br>
>>><br>
>>><br>
>>> On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola <<a \
href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>><br> >>> \
wrote:<br> >>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <<a \
href="mailto:eedri@redhat.com">eedri@redhat.com</a>> wrote:<br> \
>>>>><br> >>>>><br>
>>>>><br>
>>>>> On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola<br>
>>>>> <<a \
href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>> wrote:<br> \
>>>>>><br> >>>>>> Hi,<br>
>>>>>> I'm facing a new challenge today, I see new features \
getting pushed to<br> >>>>>> oVirt gerrit intentionally out of \
bugzilla.<br> >>>>>> The specific case is not really relevant, but \
just for reference:<br> >>>>>> <a \
href="https://gerrit.ovirt.org/#/c/65761/" rel="noreferrer" \
target="_blank">https://gerrit.ovirt.org/#/c/<wbr>65761/</a> .<br> \
>>>>>> Looks like we'll see features getting merged without any \
RFE opened in<br> >>>>>> bugzilla for them.<br>
>>><br>
>>><br>
>>> this is a common case for master, many patches do not have Bug-Url<br>
>>> including features initially<br>
>>><br>
>>>>>> With current workflow, auto-generating release notes from \
bugzilla<br> >>>>>> doc-texts. this means they won't ever be \
documented.<br> >>><br>
>>><br>
>>> true. Typically they don't have to be as for user consumable \
features<br> >>> there is typically many patches, and eventually the final \
part of feature do<br> >>> have proper tracking, RFE and so on.<br>
>>><br>
>>>>>><br>
>>>>>> I'd like to open this public discussion getting comments \
about how<br> >>>>>> things will be handled.<br>
>>>>><br>
>>>>><br>
>>>>> We can start enforcing bug-url in master branch as well, maybe \
under<br> >>>>> certain conditions.<br>
>>><br>
>>><br>
>>> I do not see the current practice as problematic<br>
>>><br>
>>>><br>
>>>> The issue here is that the decision is to not use bugzilla and \
use<br> >>>> something different like trello.<br>
>>>> So enforcing bug-url will collide with the decision from the \
feature<br> >>>> owner team.<br>
>>><br>
>>><br>
>>> If there is an official decision ( I havn't heard on such ) to move \
to<br> >>> another issue tracker for some of the projects then it needs to \
be planned,<br> >>><br>
>>><br>
>>> Some of the projects decided not to use bugzilla. It's a project<br>
>>> decision, not an "official" decision affecting other projects.<br>
>>> In this case the reason is that a supposed feature triggered a code<br>
>>> change in a side project using bugzilla.<br>
>><br>
>><br>
>> Fair enough for me.<br>
>><br>
>><br>
>>><br>
>>> I would say in that case it either deserves a bugzilla on that side<br>
>>> project, or we decide it's not important, not a substantial part of \
the<br> >>> whole feature, and therefore doesn't need to be \
documented/tracked in that<br> >>> side project and use Bug-Url-less commit \
to master.<br> >>><br>
>>> and maybe consider adding tools/verification for the new tools.<br>
>>><br>
>>><br>
>>> But it doesn't make sense to start supporting more than one \
issue<br> >>> tracker, we have too many systems already, so if we move, then \
all projects<br> >>> needs to move.<br>
>>><br>
>>><br>
>>> github issue is fairly common so if we want to support something else \
in<br> >>> addition to bugzilla Bug-Url this would be a good candidate<br>
>>><br>
>>> Thanks,<br>
>>> michal<br>
>>><br>
>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Sandro Bonazzola<br>
>>>>>> Better technology. Faster innovation. Powered by \
community<br> >>>>>> collaboration.<br>
>>>>>> See how it works at <a href="http://redhat.com" \
rel="noreferrer" target="_blank">redhat.com</a><br> >>>>>><br>
>>>>>> ______________________________<wbr>_________________<br>
>>>>>> Devel mailing list<br>
>>>>>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>>>>>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" \
rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Eyal Edri<br>
>>>>> Associate Manager<br>
>>>>> RHV DevOps<br>
>>>>> EMEA ENG Virtualization R&D<br>
>>>>> Red Hat Israel<br>
>>>>><br>
>>>>> phone: <a href="tel:%2B972-9-7692018" \
value="+97297692018">+972-9-7692018</a><br> >>>>> irc: eedri (on #tlv \
#rhev-dev #rhev-integ)<br> >>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Sandro Bonazzola<br>
>>>> Better technology. Faster innovation. Powered by community<br>
>>>> collaboration.<br>
>>>> See how it works at <a href="http://redhat.com" rel="noreferrer" \
target="_blank">redhat.com</a><br> >>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Eyal Edri<br>
>>> Associate Manager<br>
>>> RHV DevOps<br>
>>> EMEA ENG Virtualization R&D<br>
>>> Red Hat Israel<br>
>>><br>
>>> phone: <a href="tel:%2B972-9-7692018" \
value="+97297692018">+972-9-7692018</a><br> >>> irc: eedri (on #tlv \
#rhev-dev #rhev-integ)<br> >>> \
______________________________<wbr>_________________<br> >>> Devel mailing \
list<br> >>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" \
target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br> \
>>><br> >>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Sandro Bonazzola<br>
>> Better technology. Faster innovation. Powered by community \
collaboration.<br> >> See how it works at <a href="http://redhat.com" \
rel="noreferrer" target="_blank">redhat.com</a><br> >><br>
>> ______________________________<wbr>_________________<br>
>> Devel mailing list<br>
>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" \
target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br> ><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" \
target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br> \
</div></div></blockquote></div><br></div></div></div>
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic