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

[Khem Raj]

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

>
> On 19 April 2016 at 03:17, Christopher Larson  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
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Burton, Ross]

On 19 April 2016 at 03:17, Christopher Larson  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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Christopher Larson]

On Mon, Apr 18, 2016 at 5:50 PM Khem Raj  wrote:

>
> On Apr 18, 2016 3:51 PM, "Richard Purdie" <
> richard.pur...@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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Khem Raj]

On Apr 18, 2016 3:51 PM, "Richard Purdie" <
richard.pur...@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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Burton, Ross]

On 18 April 2016 at 18:35, Khem Raj  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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Khem Raj]

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"  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-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto