9:20 a.m.
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.
With current workflow, auto-generating release notes from bugzilla
doc-texts. this means they won't ever be documented.
I'd like to open this public discussion getting comments about how things
will be handled.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9:31 a.m.
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.
With current workflow, auto-generating release notes from bugzilla
doc-texts. this means they won't ever be documented.
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.
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
irc: eedri (on #tlv #rhev-dev #rhev-integ)
9:34 a.m.
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.
> With current workflow, auto-generating release notes from bugzilla
> doc-texts. this means they won't ever be documented.
>
> 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.
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.
> 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
9:36 a.m.
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.
>> With current workflow, auto-generating release notes from bugzilla
>> doc-texts. this means they won't ever be documented.
>>
>> 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.
>
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,
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.
>
>
>> 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
irc: eedri (on #tlv #rhev-dev #rhev-integ)
11:56 a.m.
--Apple-Mail=_25F658FA-7A8F-4E5F-B6D3-C6FEFEDB3167
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 21 Feb 2017, at 09:36, Eyal Edri <eedri(a)redhat.com> wrote:
=20
=20
=20
On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola =
<sbonazzo(a)redhat.com
<mailto:sbonazzo@redhat.com>> wrote:
=20
=20
On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri <eedri(a)redhat.com =
<mailto:eedri@redhat.com>> wrote:
=20
=20
On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola =
<sbonazzo(a)redhat.com
<mailto: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/ =
<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=E2=80=99t 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.
=20
I'd like to open this public discussion getting comments about how =
things
will be handled.
=20
We can start enforcing bug-url in master branch as well, maybe under =
certain
conditions.=20
I do not see the current practice as problematic
=20
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.
=20
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=E2=80=99s a project =
decision, not an =E2=80=9Cofficial=E2=80=9D decision affecting other =
projects.
In this case the reason is that a supposed feature triggered a code =
change in a side project using bugzilla.=20
I would say in that case it either deserves a bugzilla on that side =
project, or we decide it=E2=80=99s not important, not a substantial part =
of the whole feature, and therefore doesn=E2=80=99t 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.
=20
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=20
needs to move.=20
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
=20
=20
=20
=20
Thanks,
=20
--=20
Sandro Bonazzola
Better technology. Faster innovation. Powered by community =
collaboration.
See how it works at redhat.com <http://redhat.com/>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org <mailto:Devel@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
=20
=20
=20
--=20
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
=20
phone: +972-9-7692018 <tel:+972%209-769-2018>
irc: eedri (on #tlv #rhev-dev #rhev-integ)
=20
=20
=20
--=20
Sandro Bonazzola
Better technology. Faster innovation. Powered by community =
collaboration.
See how it works at redhat.com <http://redhat.com/>
=20
=20
--=20
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
=20
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_25F658FA-7A8F-4E5F-B6D3-C6FEFEDB3167
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 21 Feb 2017, at 09:36, Eyal Edri <<a =
href=3D"mailto:eedri@redhat.com"
class=3D"">eedri(a)redhat.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><div =
dir=3D"ltr" class=3D""><br class=3D""><div
class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Tue, Feb 21, 2017 at
10:34 AM, =
Sandro Bonazzola <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:sbonazzo@redhat.com" target=3D"_blank" =
class=3D"">sbonazzo(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D""><br class=3D""><div
class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote"><span class=3D"">On Tue, Feb 21, 2017
at 9:31 AM, =
Eyal Edri <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:eedri@redhat.com" target=3D"_blank" =
class=3D"">eedri(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D""><br class=3D""><div
class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote"><span class=3D"">On Tue, Feb 21, 2017
at 10:20 AM, =
Sandro Bonazzola <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:sbonazzo@redhat.com" target=3D"_blank" =
class=3D"">sbonazzo(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D"">Hi,<div class=3D"">I'm facing a new challenge
today, I see =
new features getting pushed to oVirt gerrit intentionally out of =
bugzilla.</div><div class=3D"">The specific case is not really
relevant, =
but just for reference: <a =
href=3D"https://gerrit.ovirt.org/#/c/65761/" target=3D"_blank" =
class=3D"">https://gerrit.ovir<wbr
class=3D"">t.org/#/c/65761/</a> =
.</div><div class=3D"">Looks like we'll see features getting
merged =
without any RFE opened in bugzilla for =
them.</div></div></blockquote></span></div></div></div></blockquote></span=
</div></div></div></blockquote></div></div></div></div></blockquote><div>=
<br class=3D""></div>this is a common case for master, many
patches do =
not have Bug-Url including features initially</div><div><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div
class=3D"gmail_quote"><span =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div
class=3D"gmail_quote"><span =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D""><div class=3D"">With current workflow,
auto-generating =
release notes from bugzilla doc-texts. this means they won't ever be =
documented.</div></div></blockquote></span></div></div></div></blockquote>=
</span></div></div></div></blockquote></div></div></div></div></blockquote=
<div><br class=3D""></div>true. Typically
they don=E2=80=99t 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.</div><div><br class=3D""><blockquote
type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div
class=3D"gmail_quote"><span =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div
class=3D"gmail_quote"><span =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D""><div class=3D""><br
class=3D""></div><div class=3D"">I'd like =
to open this public discussion getting comments about how things will be =
handled.</div></div></blockquote><div class=3D""><br
=
class=3D""></div></span><div class=3D"">We can
start enforcing bug-url =
in master branch as well, maybe under certain =
conditions. </div></div></div></div></blockquote></span></div></div><=
/div></blockquote></div></div></div></div></blockquote><div><br
=
class=3D""></div>I do not see the current practice as =
problematic</div><div><br class=3D""><blockquote
type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr"
class=3D""><div =
class=3D"gmail_extra"><div
class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span
class=3D""><div =
class=3D""><br class=3D""></div></span><div
class=3D"">The issue here is =
that the decision is to not use bugzilla and use something different =
like trello.</div><div class=3D"">So enforcing bug-url will collide
with =
the decision from the feature owner =
team.</div></div></div></div></blockquote><div
class=3D""><br =
class=3D""></div><div class=3D"">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,</div></div></div></div></div></blockquote><div><br
=
class=3D""></div>Some of the projects decided not to use bugzilla. =
It=E2=80=99s a project decision, not an =E2=80=9Cofficial=E2=80=9D =
decision affecting other projects.</div><div>In this case the reason is =
that a supposed feature triggered a code change in a side project using =
bugzilla. </div><div>I would say in that case it either deserves a =
bugzilla on that side project, or we decide it=E2=80=99s not important, =
not a substantial part of the whole feature, and therefore doesn=E2=80=99t=
need to be documented/tracked in that side project and use Bug-Url-less =
commit to master.</div><div><br class=3D""><blockquote
type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr"
class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div
class=3D"">and =
maybe consider adding tools/verification for the new =
tools.</div></div></div></div></div></blockquote></div><div><blockquote
=
type=3D"cite" class=3D""><div class=3D""><div
dir=3D"ltr" class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div
class=3D""><br =
class=3D""></div><div class=3D"">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 </div><div
class=3D"">needs=
to
move. </div></div></div></div></div></blockquote><div><br
=
class=3D""></div>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</div><div><br =
class=3D""></div><div>Thanks,</div><div>michal</div><div><br
=
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div
class=3D""> </div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span
class=3D""><div =
class=3D""><br class=3D""></div><div
class=3D""> </div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div =
class=3D""> </div><blockquote
class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D"">Thanks,</div><span =
class=3D"m_-7207547829882275409m_-2730009894664891844HOEnZb"><font =
color=3D"#888888" class=3D""><div class=3D""><br
class=3D""></div><div =
class=3D"">-- <br class=3D""><div =
class=3D"m_-7207547829882275409m_-2730009894664891844m_-770263900948989439=
2gmail_signature"><div dir=3D"ltr" class=3D""><div
class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D""><div
dir=3D"ltr" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D"">Sandro
Bonazzola<br =
class=3D"">Better technology. Faster innovation. Powered by community =
collaboration.<br class=3D"">See how it works at <a =
href=3D"http://redhat.com/" target=3D"_blank" =
class=3D"">redhat.com</a></div></div></div></div></div></div></div></div>
</div></font></span></div>
<br class=3D""></span>______________________________<wbr =
class=3D"">_________________<br class=3D"">
Devel mailing list<br class=3D"">
<a href=3D"mailto:Devel@ovirt.org" target=3D"_blank" =
class=3D"">Devel(a)ovirt.org</a><br class=3D"">
<a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">http://lists.ovirt.org/mailman<wbr =
class=3D"">/listinfo/devel</a><span =
class=3D"m_-7207547829882275409HOEnZb"><font color=3D"#888888"
=
class=3D""><br
class=3D""></font></span></blockquote></div><span
=
class=3D"m_-7207547829882275409HOEnZb"><font color=3D"#888888"
=
class=3D""><br class=3D""><br clear=3D"all"
class=3D""><div class=3D""><br=
class=3D""></div>-- <br class=3D""><div =
class=3D"m_-7207547829882275409m_-2730009894664891844gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"
class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"">Eyal Edri<br
class=3D"">Associate =
Manager</div><div class=3D"">RHV DevOps<br
class=3D"">EMEA ENG =
Virtualization R&D<br class=3D"">Red Hat Israel<br
class=3D""><br =
class=3D"">phone: <a href=3D"tel:+972%209-769-2018"
value=3D"+97297692018"=
target=3D"_blank" class=3D"">+972-9-7692018</a><br
class=3D"">irc: =
eedri (on #tlv #rhev-dev =
#rhev-integ)</div></div></div></div></div></div></div>
</font></span></div></div>
</blockquote></span></div><span class=3D""><br
class=3D""><br =
clear=3D"all" class=3D""><div class=3D""><br
class=3D""></div>-- <br =
class=3D""><div class=3D"m_-7207547829882275409gmail_signature"
=
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"
class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D""><div dir=3D"ltr"
class=3D"">Sandro =
Bonazzola<br class=3D"">Better technology. Faster innovation. Powered by
=
community collaboration.<br class=3D"">See how it works at <a =
href=3D"http://redhat.com/" target=3D"_blank" =
class=3D"">redhat.com</a></div></div></div></div></div></div></div></div>
</span></div></div>
</blockquote></div><br class=3D""><br
clear=3D"all" class=3D""><div =
class=3D""><br class=3D""></div>-- <br
class=3D""><div =
class=3D"gmail_signature"
data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr" class=3D""><div class=3D""><div
dir=3D"ltr" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D"">Eyal Edri<br =
class=3D"">Associate Manager</div><div class=3D"">RHV
DevOps<br =
class=3D"">EMEA ENG Virtualization R&D<br
class=3D"">Red Hat =
Israel<br class=3D""><br class=3D"">phone:
+972-9-7692018<br =
class=3D"">irc: eedri (on #tlv #rhev-dev =
#rhev-integ)</div></div></div></div></div></div></div>
</div></div>
_______________________________________________<br class=3D"">Devel =
mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org"
=
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
</div><br class=3D""></body></html>=
--Apple-Mail=_25F658FA-7A8F-4E5F-B6D3-C6FEFEDB3167--
12:01 p.m.
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
3:43 p.m.
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
4:26 p.m.
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(a)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(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
>>>> 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(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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2:53 p.m.
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(a)redhat.com
IRC : ydary
On Wed, Feb 22, 2017 at 5:26 PM, Martin Sivak <msivak(a)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(a)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(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
>>>>> 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(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
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
2621
days inactive
2626
days old
8 comments
5 participants
participants (5)
-
Eyal Edri -
Martin Sivak -
Michal Skrivanek -
Sandro Bonazzola -
Yaniv Dary