On Fri, 2014-08-01 at 18:59 -0400, Kevin A. McGrail wrote:
> On 8/1/2014 6:43 PM, Karsten Bräckelmann wrote:

> > That's trunk only. IMHO this should also be committed to the current
> > stable (3.4) branch.
> 
> In a normal process, yes but right now, there is no difference

Worse. There are already other easy fixes [1], which have been committed
to trunk only, despite an explicit Target Milestone of 3.4.1.

> and I plan on likely blowing away the 3.4.0 branch and releasing trunk
> as 3.4.1 to be honest.

I don't like "likely" in this context. Either that is a definite plan,
and there won't be any heavy changes to trunk before cutting 3.4.1, or
we'd need to commit more patches to both stable and trunk.

Also, what do you mean "blowing away" the 3.4 branch? Recreating from
trunk once? Or cutting stable releases from trunk always, until you
"branch" (rather release) the next minor version 3.5.0 from trunk? Which
would mean backporting important fixes becomes almost impossible,
because there simply is no branch other than trunk...

I'm quiet uneasy just thinking about that. Probably worth shifting over
to the dev@ list...


[1] Using plural in a general and kind of extrapolating way. In fact,
    this is based on bug 7065, which I just came across wading through
    dev@ backlog.

-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Reply via email to