[Dev] [SCM] inter-package patch dependencies

Kanevskiy, Alexander alexander.kanevskiy at intel.com
Fri Oct 18 15:30:50 GMT 2013


On 10/18/13 18:12 , "Łukasz Stelmach" <l.stelmach at samsung.com> wrote:


Łukasz, can you provide some example where in such cases package A, B, C
would be needed to submitted together and that would be not an API/ABI
change ?

As for combined submit requests - the code works that people can "join" to
the group request. 
Meaning that maintainer of A can submit his package and provide "id" to
maintainers of B and C.
Then maintainers of B and C can use same "id" to combine their changes
into one group.
It doesn't need to be done in precisely in the same time.

As for cross repository dependencies:
if we talking about just pure source code to coordinate between few people
on reviews and merges - this can be achieved by using "topic"
functionality in Gerrit.
However, if we are talking about exposing on higher abstraction level
dependencies between components -> those must be expressed as RPM
dependencies.
Otherwise we are re-inventing RPM.


And for build numbers, there are means where bumping "Release:" field in
.spec file would lead to increased predictable number in resulted
source/binary rpm in OBS.



>It was <2013-10-18 pią 14:07>, when Kanevskiy, Alexander wrote:
>> On 10/18/13 14:57 , "Łukasz Stelmach" <l.stelmach at samsung.com> wrote:
>>>
>>>I saw this problem few times before and now a teammate of mine told me
>>>he's got it too. The problem I'd like to discuss is inter-package patch
>>>dependencies.
>>>
>>>Sometimes we introduce some changes that need other packages to be
>>>changed too. So we change those too. Then, after the changes pass review
>>>and get merged they are submitted to OBS. But if they get submitted in
>>>the wrong order build-breaks occure.
>>>
>>>I wonder if we could develope some kind of dependency checking for
>>>submit requests. Commit messages could contain lines like "Requires:
>>>Iabcd*" refering to change-id (hash ids?) in different projects.
>>>Such solution might even reduce amount of work SCM need to do when they
>>>have to revert OBS commits to keep the packages OK.
>>
>> There are few things here:
>>
>> 1. API changes that are not explicitly declared.  Normally it's
>> handled that e.g. Library XYZ starts to provide new API that supposed
>> to be used by application.  API is provided in version V1. Then, best
>> practice is, if application require that API to declare build
>> dependency: BuildRequire: Library-XYZ >= V1 In such submits, if
>> Application submitted first, it will be visible to release engineers
>> that it require newer version of library.
>
>This is simple, and obvious, and might help if the release numbers were
>not generated by OBS. But because they are, and I think that it is
>good. We need something more.
>
>I am refering to situations where merely a configuration option changes
>or we introduce a patch to an upstream package, either way there is no
>point in bumping the version.
>
>> 2. Synchronised submissions: in backend there is code (but not
>> currently actively used) that would group packages if they have
>> exactly same submit tag.  Those are considered as group and decision
>> for them is taken atomically - either all of them is accepted or all
>> rejected.
>
>That is definitely useful and IMHO would help in some cases. However, it
>will be quite cumbersome to use if depending changes are made to
>packages from different domains and different people need to create the
>same tag. If there was a way for the developer who posted the depending
>changes (for both packages) to specify their dependency in the commit
>messages we'd be cooking on gas.
>
>-- 
>Łukasz Stelmach
>Samsung R&D Institute Poland
>Samsung Electronics
>


-- 
Best regards, Alexander Kanevskiy.



---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



More information about the Dev mailing list