[Dev] [SCM] inter-package patch dependencies

Krzysztof Opasiak k.opasiak at samsung.com
Fri Oct 18 12:21:52 GMT 2013


> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-
> bounces at lists.tizen.org] On Behalf Of Kanevskiy, Alexander
> Sent: Friday, October 18, 2013 2:07 PM
> To: Lukasz Stelmach; dev at lists.tizen.org
> Subject: Re: [Dev] [SCM] inter-package patch dependencies
> 
> On 10/18/13 14:57 , "Łukasz Stelmach" <l.stelmach at samsung.com>
> wrote:
> 
> 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.

Here you are talking about library versioning. I think that definitely
it would be necessary to have such mechanism on our platform and to have
repositories for this. This would allow other packages to request for a
certain version of library not only the newer one as is now.

> 
> 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.

Maybe this mechanism could be used. Please let me highlight current
issue:

We are trying to fix up build breaks on our platform. To do this we need
to fix up package A which is unable to build. While investigation we
found out that to fix this package we have to update packages B and C.
We create all three patches and submit it in Gerrit. The change for
package A is merged first and submitted in OBS but changes B and C are
still pending in Gerrit or has not been submitted already, what means
that package A won't build in GBS.

There should be some mechanism that allow me as a committer to show that
changes B and C has to be merged and submitted before changes in A.

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
k.opasiak at samsung.com







More information about the Dev mailing list