[Ksummit-discuss] Stable and delay backports

[Ksummit-discuss] Stable and delay backports

[James Bottomley]

I'm still not clear, even after all the discussion, whether there's any
value left to annotating the cc to stable with a delay backport.  I'm
getting ready to post a fix to our block size calculations which make
them completely accurate instead of within 5% like they were before.
Technically this is a bug fix because people get distressed even over
apparently losing 5% of their space, so it will have to be backported,
but the algorithm has increased in complexity, so it would be better to
incubate in main line for a while to make sure there are no further
complaints.

So the question: I think I heard Greg say you're automatically delaying
merge window backports anyway, so there's no real need to add a separate
delay tag, or is there?

James

Re: [Ksummit-discuss] Stable and delay backports

[Jens Axboe]

On 11/03/2015 10:02 AM, James Bottomley wrote:
> I'm still not clear, even after all the discussion, whether there's any
> value left to annotating the cc to stable with a delay backport.  I'm
> getting ready to post a fix to our block size calculations which make
> them completely accurate instead of within 5% like they were before.
> Technically this is a bug fix because people get distressed even over
> apparently losing 5% of their space, so it will have to be backported,
> but the algorithm has increased in complexity, so it would be better to
> incubate in main line for a while to make sure there are no further
> complaints.
>
> So the question: I think I heard Greg say you're automatically delaying
> merge window backports anyway, so there's no real need to add a separate
> delay tag, or is there?

Or you could just do it manually. Don't mark it stable, get it in 
mainline. Then send stable@ and email when you feel it's safe, asking 
them to pickup that commit.

-- 
Jens Axboe

Re: [Ksummit-discuss] Stable and delay backports

[Greg Kroah-Hartman]

On Tue, Nov 03, 2015 at 09:02:35AM -0800, James Bottomley wrote:
> I'm still not clear, even after all the discussion, whether there's any
> value left to annotating the cc to stable with a delay backport.  I'm
> getting ready to post a fix to our block size calculations which make
> them completely accurate instead of within 5% like they were before.
> Technically this is a bug fix because people get distressed even over
> apparently losing 5% of their space, so it will have to be backported,
> but the algorithm has increased in complexity, so it would be better to
> incubate in main line for a while to make sure there are no further
> complaints.
> 
> So the question: I think I heard Greg say you're automatically delaying
> merge window backports anyway, so there's no real need to add a separate
> delay tag, or is there?

If you want to ensure that I don't instantly pick it up, sure, put a
"add to stable after XXX" marking on the patch, or do like Jens
suggested, either will work.

thanks,

greg k-h

Re: [Ksummit-discuss] Stable and delay backports

[James Bottomley]

On Tue, 2015-11-03 at 10:08 -0700, Jens Axboe wrote:
> On 11/03/2015 10:02 AM, James Bottomley wrote:
> > I'm still not clear, even after all the discussion, whether there's any
> > value left to annotating the cc to stable with a delay backport.  I'm
> > getting ready to post a fix to our block size calculations which make
> > them completely accurate instead of within 5% like they were before.
> > Technically this is a bug fix because people get distressed even over
> > apparently losing 5% of their space, so it will have to be backported,
> > but the algorithm has increased in complexity, so it would be better to
> > incubate in main line for a while to make sure there are no further
> > complaints.
> >
> > So the question: I think I heard Greg say you're automatically delaying
> > merge window backports anyway, so there's no real need to add a separate
> > delay tag, or is there?
> 
> Or you could just do it manually. Don't mark it stable, get it in 
> mainline. Then send stable@ and email when you feel it's safe, asking 
> them to pickup that commit.

Actually, that's the worst of both worlds because I'd have to remember
there's a patch to backport with no marker.  If I were going to do my
own stable patches, I'd follow the DaveM process because then at least
I'd be collecting all the stable patches into my trees so there'd be
external visibility and a marker for me not to forget.  However, I was
just after low overhead ...

Anyway, I have the answer: do it as before.

James