Handling bugs which are fixed in upstream, but not released yet

[Igor Gnatenko]

Hi,

I have question, how you handle bugs where fix already available in
upstream, but you don't want to backport that fix yet. What you do
with bug in our trash-box (bugzilla.redhat.com)?

Probably you use whiteboard to indicate where it was fixed, close bug
and write into comment that it will be fixed in next upstream release
or ...?
-- 
-Igor Gnatenko

[Josh Boyer]

On Wed, Sep 14, 2016 at 8:41 AM, Igor Gnatenko <ignatenko(a)redhat.com&gt; wrote:
>  Hi,
>
>  I have question, how you handle bugs where fix already available in
>  upstream, but you don't want to backport that fix yet. What you do
>  with bug in our trash-box (bugzilla.redhat.com)? 
Why don't you want to backport it?

>  Probably you use whiteboard to indicate where it was fixed, close
> bug
>  and write into comment that it will be fixed in next upstream release
>  or ...? 
CLOSED->UPSTREAM or CLOSED->NEXTRELEASE both exist, but honestly I
would probably put the bug in DEFERRED if you plan to fix it but can't
yet for some reason.  A comment describing the timeline for when the
fix will hit Fedora is probably sufficient.  The key for any of these
states is to remember to actually do the fix.

josh

[Igor Gnatenko]

On Wed, Sep 14, 2016 at 2:45 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Wed, Sep 14, 2016 at 8:41 AM, Igor Gnatenko
> <ignatenko(a)redhat.com&gt; wrote:
> > Hi,
> >
> > I have question, how you handle bugs where fix already available in
> > upstream, but you don't want to backport that fix yet. What you do
> > with bug in our trash-box (bugzilla.redhat.com)?
>
>  Why don't you want to backport it? 
Sometimes it's too much work to backport
if there are merge conflicts.
> > Probably you use whiteboard to indicate where it was fixed, close bug
> > and write into comment that it will be fixed in next upstream release
> > or ...?
>
>  CLOSED->UPSTREAM or CLOSED->NEXTRELEASE both exist, but honestly I
>  would probably put the bug in DEFERRED if you plan to fix it but can't
>  yet for some reason.  A comment describing the timeline for when the
>  fix will hit Fedora is probably sufficient.  The key for any of these
>  states is to remember to actually do the fix.
>
>  josh
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/admin/lists/[e-mail] 


-- 
-Igor Gnatenko

[Florian Weimer]

On 09/14/2016 02:41 PM, Igor Gnatenko wrote:

>  I have question, how you handle bugs where fix already available in
>  upstream, but you don't want to backport that fix yet. What you do
>  with bug in our trash-box (bugzilla.redhat.com)?
>
>  Probably you use whiteboard to indicate where it was fixed, close bug
>  and write into comment that it will be fixed in next upstream release
>  or ...? 
I tend to upload the fixed version to rawhide and resolve the bug as 
CLOSED/RAWHIDE.

Florian

[Josh Boyer]

On Wed, Sep 14, 2016 at 9:12 AM, Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  On 09/14/2016 02:41 PM, Igor Gnatenko wrote:
>
> > I have question, how you handle bugs where fix already available in
> > upstream, but you don't want to backport that fix yet. What you do
> > with bug in our trash-box (bugzilla.redhat.com)?
> >
> > Probably you use whiteboard to indicate where it was fixed, close bug
> > and write into comment that it will be fixed in next upstream release
> > or ...?
>
>
>  I tend to upload the fixed version to rawhide and resolve the bug as
>  CLOSED/RAWHIDE. 
Also a fine alternative and less error prone in forgetting to actually fix it.

I think all of these solutions simply illustrate that there is no
fixed process for Fedora bugs, so common sense to the situation needs
to be used.

josh

[Matěj Cepl]

On 2016-09-14, 12:41 GMT, Igor Gnatenko wrote:
>  Probably you use whiteboard to indicate where it was fixed, 
>  close bug and write into comment that it will be fixed in next 
>  upstream release or ...? 
Either External Trackers (if the tracker is defined), or "See 
Also" with URL of the ticket.

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl(a)ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
  
Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
     -- Tim Hansel

[Stephen Gallagher]

On 09/14/2016 08:41 AM, Igor Gnatenko wrote:
>  Hi,
>  
>  I have question, how you handle bugs where fix already available in
>  upstream, but you don't want to backport that fix yet. What you do
>  with bug in our trash-box (bugzilla.redhat.com)?
>  
>  Probably you use whiteboard to indicate where it was fixed, close bug
>  and write into comment that it will be fixed in next upstream release
>  or ...?
>   
Many projects use the POST state for this. What it means in that context is that
a patch exists and is waiting to be added to a package. Ideally, a comment or
See Also link would be added to the BZ to let any interested party know where it
could be found if they needed to.

A comment to the effect of "patch is available upstream, but due to the
complexity it won't hit Fedora until the next upstream release" would be useful
as well.

This allows the bug to also stay open, so when you go to submit a Bodhi update,
it's going to show up in the list of possible BZs to close with this update,
which will remind you to mark it or pull it in if you haven't done so yet.