[RFC] policy proposal: INC_PR

[RFC] policy proposal: INC_PR

[Dmitry Eremin-Solenikov]

Hello, colleagues,

While debugging some stuff in oe-core & company I've noticed that
lot's of packages
either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then
.bb just defines PR = "rX").

From my previous experience with oe-dev, I found INC_PR very usefull
and error-prone feature.
What about making usage of INC_PR a policy decision, demanding that
all new packages should use INC_PR for their recipes, if .inc files
are used. And then define a grace period
during which all remaining packages should be converted to INC_PR (3
months? Next release? I really don't know).

I'm sorry if this issue was already discussed somewhere and I'm
duplicating the efforts
or proposing already discarded idea.

-- 
With best wishes
Dmitry

Re: [RFC] policy proposal: INC_PR

[Mark Hatle]

On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote:
> Hello, colleagues,
> 
> While debugging some stuff in oe-core & company I've noticed that
> lot's of packages
> either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then
> .bb just defines PR = "rX").

I've noticed similar things.  I'd agree, we should define and use INC_PR for
items that have .inc files.  There have been many times that I need to fix a bug
in the .inc file and end up manually updating the PR is 2 or 3 recipes that use
the .inc.

One question though, how do we handle packages with multilib .inc files?

INC_PR += ...  (or is it .=)

--Mark

> From my previous experience with oe-dev, I found INC_PR very usefull
> and error-prone feature.
> What about making usage of INC_PR a policy decision, demanding that
> all new packages should use INC_PR for their recipes, if .inc files
> are used. And then define a grace period
> during which all remaining packages should be converted to INC_PR (3
> months? Next release? I really don't know).
> 
> I'm sorry if this issue was already discussed somewhere and I'm
> duplicating the efforts
> or proposing already discarded idea.
> 

Re: [RFC] policy proposal: INC_PR

[Richard Purdie]

On Tue, 2011-09-20 at 14:10 -0500, Mark Hatle wrote:
> On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote:
> > Hello, colleagues,
> > 
> > While debugging some stuff in oe-core & company I've noticed that
> > lot's of packages
> > either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but then
> > .bb just defines PR = "rX").
> 
> I've noticed similar things.  I'd agree, we should define and use INC_PR for
> items that have .inc files.  There have been many times that I need to fix a bug
> in the .inc file and end up manually updating the PR is 2 or 3 recipes that use
> the .inc.
> 
> One question though, how do we handle packages with multilib .inc files?
> 
> INC_PR += ...  (or is it .=)

I'm going to disagree here. I'd actually like to see the whole PR thing
become irrelevant. Its insane we have to spend so much time doing
something the system should be able to figure out for itself. It
currently serves two purposes:

1. Triggers rebuilds of packages when they change
2. Handles package feed upgrades correctly

For 1, we can use the sstate checksums and for 2, we can use some kind
of PR server, either local or networked.

I'm therefore proposing that after the current release is finished, we
enable the BasicHash signature generator (which adds the sstate
checksums to the stamp files) and stop bumping PR values (so INC_PR can
die and PR values can likely fade out of recipes). If the tooling we
have for 2 isn't enough we'll then just simply have to improve it and
make it work.

Comments?

Cheers,

Richard

Re: [RFC] policy proposal: INC_PR

[Koen Kooi]

Op 20 sep 2011, om 22:30 heeft Richard Purdie het volgende geschreven:

> On Tue, 2011-09-20 at 14:10 -0500, Mark Hatle wrote:
>> On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote:
>>> Hello, colleagues,
>>>
>>> While debugging some stuff in oe-core & company I've noticed that
>>> lot's of packages
>>> either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but  
>>> then
>>> .bb just defines PR = "rX").
>>
>> I've noticed similar things.  I'd agree, we should define and use  
>> INC_PR for
>> items that have .inc files.  There have been many times that I need  
>> to fix a bug
>> in the .inc file and end up manually updating the PR is 2 or 3  
>> recipes that use
>> the .inc.
>>
>> One question though, how do we handle packages with multilib .inc  
>> files?
>>
>> INC_PR += ...  (or is it .=)
>
> I'm going to disagree here. I'd actually like to see the whole PR  
> thing
> become irrelevant. Its insane we have to spend so much time doing
> something the system should be able to figure out for itself. It
> currently serves two purposes:
>
> 1. Triggers rebuilds of packages when they change
> 2. Handles package feed upgrades correctly
>
> For 1, we can use the sstate checksums and for 2, we can use some kind
> of PR server, either local or networked.
>
> I'm therefore proposing that after the current release is finished, we
> enable the BasicHash signature generator (which adds the sstate
> checksums to the stamp files) and stop bumping PR values (so INC_PR  
> can
> die and PR values can likely fade out of recipes). If the tooling we
> have for 2 isn't enough we'll then just simply have to improve it and
> make it work.
>
> Comments?

Judging from the previous big changes in OE-core, can we have the  
tooling actually work before abolishing PR?
AFAICT the PR 'syncing' across all builders for a distro hasn't been  
solved properly yet. With the current tooling it is impossible for  
people to rebuild a tag and get the same PRs as the master build had  
at the time of the tag.

Re: [RFC] policy proposal: INC_PR

[Richard Purdie]

On Tue, 2011-09-20 at 22:36 +0200, Koen Kooi wrote:
> Op 20 sep 2011, om 22:30 heeft Richard Purdie het volgende geschreven:
> 
> > On Tue, 2011-09-20 at 14:10 -0500, Mark Hatle wrote:
> >> On 9/20/11 2:04 PM, Dmitry Eremin-Solenikov wrote:
> >>> Hello, colleagues,
> >>>
> >>> While debugging some stuff in oe-core & company I've noticed that
> >>> lot's of packages
> >>> either don't use INC_PR, or misuse it (e.g. .inc has INC_PR, but  
> >>> then
> >>> .bb just defines PR = "rX").
> >>
> >> I've noticed similar things.  I'd agree, we should define and use  
> >> INC_PR for
> >> items that have .inc files.  There have been many times that I need  
> >> to fix a bug
> >> in the .inc file and end up manually updating the PR is 2 or 3  
> >> recipes that use
> >> the .inc.
> >>
> >> One question though, how do we handle packages with multilib .inc  
> >> files?
> >>
> >> INC_PR += ...  (or is it .=)
> >
> > I'm going to disagree here. I'd actually like to see the whole PR  
> > thing
> > become irrelevant. Its insane we have to spend so much time doing
> > something the system should be able to figure out for itself. It
> > currently serves two purposes:
> >
> > 1. Triggers rebuilds of packages when they change
> > 2. Handles package feed upgrades correctly
> >
> > For 1, we can use the sstate checksums and for 2, we can use some kind
> > of PR server, either local or networked.
> >
> > I'm therefore proposing that after the current release is finished, we
> > enable the BasicHash signature generator (which adds the sstate
> > checksums to the stamp files) and stop bumping PR values (so INC_PR  
> > can
> > die and PR values can likely fade out of recipes). If the tooling we
> > have for 2 isn't enough we'll then just simply have to improve it and
> > make it work.
> >
> > Comments?
> 
> Judging from the previous big changes in OE-core, can we have the  
> tooling actually work before abolishing PR?
> AFAICT the PR 'syncing' across all builders for a distro hasn't been  
> solved properly yet. With the current tooling it is impossible for  
> people to rebuild a tag and get the same PRs as the master build had  
> at the time of the tag.

This is the first time that problem has been specifically rasied to my
knowledge so yes, we need to have a solution for that I agree.

Likely, the best way to handle it is going to be to dump the PR server's
database into an include file which sets the PR values as needed and
then the include file can be included in the tagged release.

This would mean that anyone building the checkout would then have the
correct set of base PR values to be consistent with the main package
repo as released.

Alternatives would be including the PR database itself somehow but it
probably makes sense to start a separate discussion about this.

Are there any other problems that need to get fixed? I still think we
are going to need to switch sooner than later so we can start to find
and address issues as if we continue to wait, few people actually test
and figure them out sadly :(

Cheers,

Richard