Error on PRINC

Error on PRINC

[Holger Hans Peter Freyther]

Dear Richard,

I went through the diff and show your commit to turn having a
PRINC into an error. For our GSM BTS we are using Poky for the
base-system. We are currently shipping edison and dora based
images and I am working on tracking master because our internal
stabilisation period was always too long (e.g. the gcc compiler
issue, systemd journald performance, issues with creating source
tarballs for GPL compliance).

On top of OE-Core/Poky we have two layers, one is a BSP layer
and the other is all the opensource GSM bits we use and offer
to the customers. We do not use different release branches as
our software is portable enough to work across different versions
of gcc and such.

Even supporting a BSP for Edison, Dora and master is not so
much of an issue. And now back to the point. So we still need
to use PRINC for providing updates to edison, we want to use
PRINC on dora as things like CONFFILES_${PN} were not correctly
tracked but at the same time I want to track master to not end
up with the situation of spending 6 months in integration and
then be on an old version of Poky. The way I track master is
having a jenkins job that will take */master of everything and
build. Now when you turn the warning in an error the build will
be considered broken.

a.) Can you undo the change and give us enough time to cease
out our edison users?

b.) Would you accept a patch with something like "known" usage
of deprecated features? KNOWN_DEPRECATED="princ bla"? This way
I know about PRINC and decide to postpone but can will not see
other deprecated things?

kind regards
	holger

Re: Error on PRINC

[Richard Purdie]

Hi Holger,

On Sun, 2014-11-09 at 15:13 +0100, Holger Hans Peter Freyther wrote:
> I went through the diff and show your commit to turn having a
> PRINC into an error. For our GSM BTS we are using Poky for the
> base-system. We are currently shipping edison and dora based
> images and I am working on tracking master because our internal
> stabilisation period was always too long (e.g. the gcc compiler
> issue, systemd journald performance, issues with creating source
> tarballs for GPL compliance).
> 
> On top of OE-Core/Poky we have two layers, one is a BSP layer
> and the other is all the opensource GSM bits we use and offer
> to the customers. We do not use different release branches as
> our software is portable enough to work across different versions
> of gcc and such.
> 
> Even supporting a BSP for Edison, Dora and master is not so
> much of an issue. And now back to the point. So we still need
> to use PRINC for providing updates to edison, we want to use
> PRINC on dora as things like CONFFILES_${PN} were not correctly
> tracked

I honestly thought we'd backported that fix to dora. I see we did not
and I've therefore just done so.

>  but at the same time I want to track master to not end
> up with the situation of spending 6 months in integration and
> then be on an old version of Poky. The way I track master is
> having a jenkins job that will take */master of everything and
> build. Now when you turn the warning in an error the build will
> be considered broken.
> 
> a.) Can you undo the change and give us enough time to cease
> out our edison users?

I think at this point we do need to show the error so this leads us to:

> b.) Would you accept a patch with something like "known" usage
> of deprecated features? KNOWN_DEPRECATED="princ bla"? This way
> I know about PRINC and decide to postpone but can will not see
> other deprecated things?

We do have the WARN_QA and ERROR_QA variables which effectively work
like this. I'll accept a patch to make this conditional on those
settings, as long as the default remains to error so that users are
aware of the problem.

Cheers,

Richard