[oe] bp flag added to bug tracker (org.openembedded.stable)

[Leon Woestenberg]

Koen, Richard,

On Wed, May 7, 2008 at 5:47 PM, Koen Kooi <k.kooi at student.utwente.nl> wrote:
> Richard Purdie wrote:
> > On this note, I would like to raise the question of whether a new
> > 'stable' branch may make sense and make a better target to organise
> > effort around?
> >
>
Maybe it's better to put effort in working towards a *planned* new
base point for the next stable branch-off.

Koen, thanks for re-establishing that branching off too often is not
good, I retract my 2008.6 question :-)

 > > I guess a useful question to ask at this point is "Whats brewing
> > for .dev in the next six months?"
> >
> > > From my perspective I see the following *possible* ideas which have the
> > >
Your perspective is widely recognized as broad and good :-)

> > potential for disruption:
> >
> > * a new bitbake release and making this the minimum version for .dev
> > * make multimachine.bbclass the default
> > * make packaged-staging opt-out
> > * resolve some issues I've just noticed with pkgconfig[1]
> > * libtool experimentation[2]
> >
> > [1] pkgconfig.bbclass and autotools.bbclass are now overlapping
> > functionality. We can probably drop pkgconfig.bbclass now or at least
> > split the staging bit into a separate class since autotools shouldn't
> > need it anymore. The functionality in autotools.bbclass should be
> > opt-out, not opt-in as it is at present IMO though.
> >
> > [2] I've been meaning to mail about this for a while. Poky has upgraded
> > from 1.5.10 to 2.2.2 and then 2.2.4. This has to be one of the most
> > painful things I've ever done. On the plus side, we're down to two
> > libtool patches now. I did find two bugs in the 2.2.2 release but these
> > have been fixed upstream after I reported them. For .dev, I propose
> > adding Poky's recipes as DEFAULT_PREFERENCE = "-1" and then brave souls
> > can enable it and fix up their favourite targets or at least report the
> > issues. The fixes in Poky should provide a good start.
> >
> > So all things considered, there isn't anything too disruptive in that
> > list IMO. I don't know if anyone else has any infrastructure changes
> > planned?
> >
>
>  For the stable branch "disruptive" is not really a good metric, "how well
> tested are the changes across the complete OE metadata" is a better one.
>
What if we plan to have the disruptive changes breed and sit in .dev
first until the devs are fine with them, plan towards a branch-off (a
few weeks of keeping infrastructure changes in our .dev metadata,
package recipe work is always fine of course) and branch off then?

Regards,
-- 
Leon