How to manage "*.changes" log files for linked projects

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How to manage "*.changes" log files for linked projects

Lee Duncan
Hi:

I maintain several packages in the OBS and in the IBS, and many of them
are linked.

For example, I am supporting the target-isns package. The newest version
of target-isns is 0.6.3 as was updated in Base:system and then in
Factory Nov 10 2015 (not by me).

So Factory and Base:System have the newest version.

But there are several other versions of this package, and they have
diverged from each other at different times:

Product Version
======== =======================
openSUSE Base:System 0.6.3
openSUSE Factory 0.6.3
openSUSE Leap 42.1 3 commits behind 0.6.3
openSUSE Leap 42.2 1 commit behind 0.6.3

SLES 12 SP1 1 commit behind 0.6.3
SLES 12 SP2 uses SP1 version


But the problem is that the "target-isns.changes" files has 4 versions
now! There are 3 versions in OBS (for openSUSE) and one other version in
IBS (for SLES).

On top of this, the new "interlocking" rules seem to require that the
version in Leap 42.2 exactly match the version in SLES 12 SP2, including
meta-data such as the SPEC file and the *.changes file.

My only problem is that I understood there was a rule that the *.changes
file for any project be strictly chronological. If that's true, then
once two *.changes file diverge, they can never be exactly the same
again, as no old entries are ever supposed to be lost.

Can anyone help me with this "catch 22"?
--
Lee Duncan
SUSE Labs
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to manage "*.changes" log files for linked projects

Lee Duncan
Note: should this have gone to opensuse-buildservice instead?

On 09/28/2016 12:57 PM, Lee Duncan wrote:

> Hi:
>
> I maintain several packages in the OBS and in the IBS, and many of them
> are linked.
>
> For example, I am supporting the target-isns package. The newest version
> of target-isns is 0.6.3 as was updated in Base:system and then in
> Factory Nov 10 2015 (not by me).
>
> So Factory and Base:System have the newest version.
>
> But there are several other versions of this package, and they have
> diverged from each other at different times:
>
> Product Version
> ======== =======================
> openSUSE Base:System 0.6.3
> openSUSE Factory 0.6.3
> openSUSE Leap 42.1 3 commits behind 0.6.3
> openSUSE Leap 42.2 1 commit behind 0.6.3
>
> SLES 12 SP1 1 commit behind 0.6.3
> SLES 12 SP2 uses SP1 version
>
>
> But the problem is that the "target-isns.changes" files has 4 versions
> now! There are 3 versions in OBS (for openSUSE) and one other version in
> IBS (for SLES).
>
> On top of this, the new "interlocking" rules seem to require that the
> version in Leap 42.2 exactly match the version in SLES 12 SP2, including
> meta-data such as the SPEC file and the *.changes file.
>
> My only problem is that I understood there was a rule that the *.changes
> file for any project be strictly chronological. If that's true, then
> once two *.changes file diverge, they can never be exactly the same
> again, as no old entries are ever supposed to be lost.
>
> Can anyone help me with this "catch 22"?
>

--
Lee Duncan
SUSE Labs
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to manage "*.changes" log files for linked projects

Lee Duncan
In reply to this post by Lee Duncan
I believe I know how to fix this problem: merge IBS and OBS teams!

OBS seems to keep adding new and more restrictive rules, but still IBS
has some rules that OBS does not. And now engineers are expected to
populate both repositories with exactly the same code?

I generally do impossible things only before lunch ... so maybe I can
figure out how to do this tomorrow.

On 09/28/2016 12:57 PM, Lee Duncan wrote:

> Hi:
>
> I maintain several packages in the OBS and in the IBS, and many of them
> are linked.
>
> For example, I am supporting the target-isns package. The newest version
> of target-isns is 0.6.3 as was updated in Base:system and then in
> Factory Nov 10 2015 (not by me).
>
> So Factory and Base:System have the newest version.
>
> But there are several other versions of this package, and they have
> diverged from each other at different times:
>
> Product Version
> ======== =======================
> openSUSE Base:System 0.6.3
> openSUSE Factory 0.6.3
> openSUSE Leap 42.1 3 commits behind 0.6.3
> openSUSE Leap 42.2 1 commit behind 0.6.3
>
> SLES 12 SP1 1 commit behind 0.6.3
> SLES 12 SP2 uses SP1 version
>
>
> But the problem is that the "target-isns.changes" files has 4 versions
> now! There are 3 versions in OBS (for openSUSE) and one other version in
> IBS (for SLES).
>
> On top of this, the new "interlocking" rules seem to require that the
> version in Leap 42.2 exactly match the version in SLES 12 SP2, including
> meta-data such as the SPEC file and the *.changes file.
>
> My only problem is that I understood there was a rule that the *.changes
> file for any project be strictly chronological. If that's true, then
> once two *.changes file diverge, they can never be exactly the same
> again, as no old entries are ever supposed to be lost.
>
> Can anyone help me with this "catch 22"?
>

--
Lee Duncan
SUSE Labs
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to manage "*.changes" log files for linked projects

Simon Lees-3
In reply to this post by Lee Duncan


On 09/29/2016 05:27 AM, Lee Duncan wrote:

> Hi:
>
> I maintain several packages in the OBS and in the IBS, and many of them
> are linked.
>
> For example, I am supporting the target-isns package. The newest version
> of target-isns is 0.6.3 as was updated in Base:system and then in
> Factory Nov 10 2015 (not by me).
>
> So Factory and Base:System have the newest version.
>
> But there are several other versions of this package, and they have
> diverged from each other at different times:
>
> Product Version
> ======== =======================
> openSUSE Base:System 0.6.3
> openSUSE Factory 0.6.3
> openSUSE Leap 42.1 3 commits behind 0.6.3
> openSUSE Leap 42.2 1 commit behind 0.6.3
>
> SLES 12 SP1 1 commit behind 0.6.3
> SLES 12 SP2 uses SP1 version
>
>
> But the problem is that the "target-isns.changes" files has 4 versions
> now! There are 3 versions in OBS (for openSUSE) and one other version in
> IBS (for SLES).
>
> On top of this, the new "interlocking" rules seem to require that the
> version in Leap 42.2 exactly match the version in SLES 12 SP2, including
> meta-data such as the SPEC file and the *.changes file.
>
> My only problem is that I understood there was a rule that the *.changes
> file for any project be strictly chronological. If that's true, then
> once two *.changes file diverge, they can never be exactly the same
> again, as no old entries are ever supposed to be lost.
>
> Can anyone help me with this "catch 22"?
>
I would normally just keep the changelog from Base:System as is so when
its pushed to openSUSE:Factory and others it becomes the changelog as
its the most active description of product development. I make it more
complicated by having a devel repo for stable point releases and a devel
repo with the alpha/beta for the next release, so normally some of the
changes entries I write for some point releases end up being removed at
some point.

**The important thing** is that if you remove a section of a .changes
file containing bugzilla or CVE references you make sure that you re add
them in a new entry otherwise several tools and scripts will complain
about bugs that were fixed not being fixed anymore. When that happens
the Maintenance team will come knocking on your door asking what happened.

But in general having 4 different .changes files is ok each is a
accurate representation of the state of that package as it sits in its
individual repo

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                            Adeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to manage "*.changes" log files for linked projects

Jordi Massaguer Pla-2

On 09/30/2016 09:57 AM, Simon Lees wrote:

>
> On 09/29/2016 05:27 AM, Lee Duncan wrote:
>> Hi:
>>
>> I maintain several packages in the OBS and in the IBS, and many of them
>> are linked.
>>
>> For example, I am supporting the target-isns package. The newest version
>> of target-isns is 0.6.3 as was updated in Base:system and then in
>> Factory Nov 10 2015 (not by me).
>>
>> So Factory and Base:System have the newest version.
>>
>> But there are several other versions of this package, and they have
>> diverged from each other at different times:
>>
>> Product Version
>> ======== =======================
>> openSUSE Base:System 0.6.3
>> openSUSE Factory 0.6.3
>> openSUSE Leap 42.1 3 commits behind 0.6.3
>> openSUSE Leap 42.2 1 commit behind 0.6.3
>>
>> SLES 12 SP1 1 commit behind 0.6.3
>> SLES 12 SP2 uses SP1 version
>>
>>
>> But the problem is that the "target-isns.changes" files has 4 versions
>> now! There are 3 versions in OBS (for openSUSE) and one other version in
>> IBS (for SLES).
>>
>> On top of this, the new "interlocking" rules seem to require that the
>> version in Leap 42.2 exactly match the version in SLES 12 SP2, including
>> meta-data such as the SPEC file and the *.changes file.
>>
>> My only problem is that I understood there was a rule that the *.changes
>> file for any project be strictly chronological. If that's true, then
>> once two *.changes file diverge, they can never be exactly the same
>> again, as no old entries are ever supposed to be lost.
>>
>> Can anyone help me with this "catch 22"?
>>
> I would normally just keep the changelog from Base:System as is so when
> its pushed to openSUSE:Factory and others it becomes the changelog as
> its the most active description of product development. I make it more
> complicated by having a devel repo for stable point releases and a devel
> repo with the alpha/beta for the next release, so normally some of the
> changes entries I write for some point releases end up being removed at
> some point.
>
> **The important thing** is that if you remove a section of a .changes
> file containing bugzilla or CVE references you make sure that you re add
> them in a new entry otherwise several tools and scripts will complain
> about bugs that were fixed not being fixed anymore. When that happens
> the Maintenance team will come knocking on your door asking what happened.
>

We, the containers team, had the same problem and the solution we took
was to keep the changelog of the obs devel project (in your case
Base:System) and just be careful not to remove any bnc or cve number, as
stated by Simon. So whenever we plan a new release, we update the
changelog in the obs devel project and then overwrite the changelogs of
the packages in the other projects/subprojectes and prepare the
maintenance request.

The only exception is when you use mbranch to fix the packages. Then you
obviously only add an entry to the changelog to the package you submit.
Just have in mind that you will have to add an entry in the obs devel
project next time you want to do an update.

regards

jordi


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]