bugzilla.yoctoproject.org policy for bugs against multiple releases

bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Hi,

At the moment we don't really have a policy for oe-core bugs in
bugzilla.yoctoproject.org that apply to multiple releases, for example
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9400.  This is a CVE bug
that should be fixed in all supported branches, and indeed Sona has sent
patches for Fido/Dizzy/Jethro/master.  Of course now we've got to track
where these patches are in the submission process and ensure that we don't
drop any of these, but bugzilla only has a single target milestone for each
bug.

I propose that for bugs such as this we file a bug report for master and
then clone it (there's a Clone This Bug button at the bottom) for each
stable release that is affected.  Then each bug can have it's own target
milestone set and we can be sure that the patches don't get left out of
being merged and that QA can effectively verify each branch.

Any objection or feedback? (the first person to suggest moving to Jira gets
to manually review all CVEs from CVE-1999-0001 onwards are fixed in
krogoth).

Ross

[-- Attachment #2: Type: text/html, Size: 1290 bytes --]

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[akuster]

On 04/18/2016 03:26 AM, Burton, Ross wrote:
> Hi,
> 
> At the moment we don't really have a policy for oe-core bugs in
> bugzilla.yoctoproject.org that apply to multiple releases, for example
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9400.  This is a CVE bug
> that should be fixed in all supported branches, and indeed Sona has sent
> patches for Fido/Dizzy/Jethro/master.  Of course now we've got to track
> where these patches are in the submission process and ensure that we don't
> drop any of these, 

If the worry is about patches being left out than every change requires
a bug number and needs to be managed to ensure a clone is created for
any branch affected by the fix.

but bugzilla only has a single target milestone for each
> bug.
> 
> I propose that for bugs such as this
 we file a bug report for master and
> then clone it (there's a Clone This Bug button at the bottom) for each
> stable release that is affected.

This also means maintainers who cherry-pick fixes from another branch
would have to amend the commit to change the bug number. Do we really
want to add to the workload of the maintainers?

  Then each bug can have it's own target
> milestone set and we can be sure that the patches don't get left out of
> being merged and that QA can effectively verify each branch.
> 
> Any objection or feedback? 

This is why I stopped opening Yocto Bugs. I would rather spend my time
fixing things than managing them.

- Armin

(the first person to suggest moving to Jira gets
> to manually review all CVEs from CVE-1999-0001 onwards are fixed in
> krogoth).

> 
> Ross
> 
> 
> 

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

Can we have a possibility to select  field like "affected version" and have
it such that multiple versions can be specified
On Apr 18, 2016 3:27 AM, "Burton, Ross" <ross.burton@intel.com> wrote:

> Hi,
>
> At the moment we don't really have a policy for oe-core bugs in
> bugzilla.yoctoproject.org that apply to multiple releases, for example
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9400.  This is a CVE
> bug that should be fixed in all supported branches, and indeed Sona has
> sent patches for Fido/Dizzy/Jethro/master.  Of course now we've got to
> track where these patches are in the submission process and ensure that we
> don't drop any of these, but bugzilla only has a single target milestone
> for each bug.
>
> I propose that for bugs such as this we file a bug report for master and
> then clone it (there's a Clone This Bug button at the bottom) for each
> stable release that is affected.  Then each bug can have it's own target
> milestone set and we can be sure that the patches don't get left out of
> being merged and that QA can effectively verify each branch.
>
> Any objection or feedback? (the first person to suggest moving to Jira
> gets to manually review all CVEs from CVE-1999-0001 onwards are fixed in
> krogoth).
>
> Ross
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

[-- Attachment #2: Type: text/html, Size: 2170 bytes --]

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

Can we have a possibility to select  field like "affected version" and have
it such that multiple versions can be specified
On Apr 18, 2016 3:27 AM, "Burton, Ross" <ross.burton@intel.com> wrote:

> Hi,
>
> At the moment we don't really have a policy for oe-core bugs in
> bugzilla.yoctoproject.org that apply to multiple releases, for example
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9400.  This is a CVE
> bug that should be fixed in all supported branches, and indeed Sona has
> sent patches for Fido/Dizzy/Jethro/master.  Of course now we've got to
> track where these patches are in the submission process and ensure that we
> don't drop any of these, but bugzilla only has a single target milestone
> for each bug.
>
> I propose that for bugs such as this we file a bug report for master and
> then clone it (there's a Clone This Bug button at the bottom) for each
> stable release that is affected.  Then each bug can have it's own target
> milestone set and we can be sure that the patches don't get left out of
> being merged and that QA can effectively verify each branch.
>
> Any objection or feedback? (the first person to suggest moving to Jira
> gets to manually review all CVEs from CVE-1999-0001 onwards are fixed in
> krogoth).
>
> Ross
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

[-- Attachment #2: Type: text/html, Size: 2170 bytes --]

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On 18 April 2016 at 18:35, Khem Raj <raj.khem@gmail.com> wrote:

> Can we have a possibility to select  field like "affected version" and
> have it such that multiple versions can be specified
>

You'd then need to have the ability to set multiple target versions, and
track each of those independently.  Without this you won't gain anything
beyond leaving a comment saying "needs to be fixed in fido" or "patch sent
for fido", there's no tracking.

Ross

[-- Attachment #2: Type: text/html, Size: 848 bytes --]

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On 18 April 2016 at 18:35, Khem Raj <raj.khem@gmail.com> wrote:

> Can we have a possibility to select  field like "affected version" and
> have it such that multiple versions can be specified
>

You'd then need to have the ability to set multiple target versions, and
track each of those independently.  Without this you won't gain anything
beyond leaving a comment saying "needs to be fixed in fido" or "patch sent
for fido", there's no tracking.

Ross

[-- Attachment #2: Type: text/html, Size: 848 bytes --]

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[Richard Purdie]

On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> Can we have a possibility to select  field like "affected version"
> and have it such that multiple versions can be specified

That doesn't really allow us to mark version X as merged and version Y
as pending review though and as I understand it, that is the real issue
atm :/.

Cheers,

Richard

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Richard Purdie]

On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> Can we have a possibility to select  field like "affected version"
> and have it such that multiple versions can be specified

That doesn't really allow us to mark version X as merged and version Y
as pending review though and as I understand it, that is the real issue
atm :/.

Cheers,

Richard

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Apr 18, 2016 3:51 PM, "Richard Purdie" <
richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> > Can we have a possibility to select  field like "affected version"
> > and have it such that multiple versions can be specified
>
> That doesn't really allow us to mark version X as merged and version Y
> as pending review though and as I understand it, that is the real issue
> atm :/.

May be bugzilla can be programmed to have such triggers. Having separate
bug is not a good looking solution
>
> Cheers,
>
> Richard

[-- Attachment #2: Type: text/html, Size: 801 bytes --]

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Apr 18, 2016 3:51 PM, "Richard Purdie" <
richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> > Can we have a possibility to select  field like "affected version"
> > and have it such that multiple versions can be specified
>
> That doesn't really allow us to mark version X as merged and version Y
> as pending review though and as I understand it, that is the real issue
> atm :/.

May be bugzilla can be programmed to have such triggers. Having separate
bug is not a good looking solution
>
> Cheers,
>
> Richard

[-- Attachment #2: Type: text/html, Size: 801 bytes --]

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Mon, Apr 18, 2016 at 5:50 PM Khem Raj <raj.khem@gmail.com> wrote:

>
> On Apr 18, 2016 3:51 PM, "Richard Purdie" <
> richard.purdie@linuxfoundation.org> wrote:
> >
> > On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> > > Can we have a possibility to select  field like "affected version"
> > > and have it such that multiple versions can be specified
> >
> > That doesn't really allow us to mark version X as merged and version Y
> > as pending review though and as I understand it, that is the real issue
> > atm :/.
>
> May be bugzilla can be programmed to have such triggers. Having separate
> bug is not a good looking solution
>

I'd agree that it's not ideal, but it's definitely a *common* solution in
many bug tracking systems, since it's usually the only way to maintain
separate states for each version. I know I've seen it done that way in
bugzilla, jira, and others over the years.

There may be something better out there, and if we can find it, great, but
I think separate issues is better than not addressing the issue at all, but
only if the tooling is good enough to help reduce overhead on the part of
the devs dealing with it. Issue tracker overhead gets pretty frustrating at
times.

[-- Attachment #2: Type: text/html, Size: 1706 bytes --]

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Mon, Apr 18, 2016 at 5:50 PM Khem Raj <raj.khem@gmail.com> wrote:

>
> On Apr 18, 2016 3:51 PM, "Richard Purdie" <
> richard.purdie@linuxfoundation.org> wrote:
> >
> > On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> > > Can we have a possibility to select  field like "affected version"
> > > and have it such that multiple versions can be specified
> >
> > That doesn't really allow us to mark version X as merged and version Y
> > as pending review though and as I understand it, that is the real issue
> > atm :/.
>
> May be bugzilla can be programmed to have such triggers. Having separate
> bug is not a good looking solution
>

I'd agree that it's not ideal, but it's definitely a *common* solution in
many bug tracking systems, since it's usually the only way to maintain
separate states for each version. I know I've seen it done that way in
bugzilla, jira, and others over the years.

There may be something better out there, and if we can find it, great, but
I think separate issues is better than not addressing the issue at all, but
only if the tooling is good enough to help reduce overhead on the part of
the devs dealing with it. Issue tracker overhead gets pretty frustrating at
times.

[-- Attachment #2: Type: text/html, Size: 1706 bytes --]

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On 19 April 2016 at 03:17, Christopher Larson <clarson@kergoth.com> wrote:

> There may be something better out there, and if we can find it, great, but
> I think separate issues is better than not addressing the issue at all, but
> only if the tooling is good enough to help reduce overhead on the part of
> the devs dealing with it. Issue tracker overhead gets pretty frustrating at
> times.
>

There may be a way of dealing with this using flags.  If we had a flag for
each release then we could add a flag for each release which is impacted by
the bug, and track when they're resolved by changing flag state.

Ross

[-- Attachment #2: Type: text/html, Size: 1034 bytes --]

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On 19 April 2016 at 03:17, Christopher Larson <clarson@kergoth.com> wrote:

> There may be something better out there, and if we can find it, great, but
> I think separate issues is better than not addressing the issue at all, but
> only if the tooling is good enough to help reduce overhead on the part of
> the devs dealing with it. Issue tracker overhead gets pretty frustrating at
> times.
>

There may be a way of dealing with this using flags.  If we had a flag for
each release then we could add a flag for each release which is impacted by
the bug, and track when they're resolved by changing flag state.

Ross

[-- Attachment #2: Type: text/html, Size: 1034 bytes --]

Re: bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

See how gcc project manages it. May be that is sufficient for us too
On Apr 19, 2016 9:41 AM, "Burton, Ross" <ross.burton@intel.com> wrote:

>
> On 19 April 2016 at 03:17, Christopher Larson <clarson@kergoth.com> wrote:
>
>> There may be something better out there, and if we can find it, great,
>> but I think separate issues is better than not addressing the issue at all,
>> but only if the tooling is good enough to help reduce overhead on the part
>> of the devs dealing with it. Issue tracker overhead gets pretty frustrating
>> at times.
>>
>
> There may be a way of dealing with this using flags.  If we had a flag for
> each release then we could add a flag for each release which is impacted by
> the bug, and track when they're resolved by changing flag state.
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1421 bytes --]

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

See how gcc project manages it. May be that is sufficient for us too
On Apr 19, 2016 9:41 AM, "Burton, Ross" <ross.burton@intel.com> wrote:

>
> On 19 April 2016 at 03:17, Christopher Larson <clarson@kergoth.com> wrote:
>
>> There may be something better out there, and if we can find it, great,
>> but I think separate issues is better than not addressing the issue at all,
>> but only if the tooling is good enough to help reduce overhead on the part
>> of the devs dealing with it. Issue tracker overhead gets pretty frustrating
>> at times.
>>
>
> There may be a way of dealing with this using flags.  If we had a flag for
> each release then we could add a flag for each release which is impacted by
> the bug, and track when they're resolved by changing flag state.
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1421 bytes --]