[Dev] [SCM] inter-package patch dependencies

Łukasz Stelmach l.stelmach at samsung.com
Fri Oct 18 15:12:55 GMT 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131018/f2d20745/attachment.sig>


More information about the Dev mailing list