It was <2013-10-18 pią 17:30>, when Kanevskiy, Alexander wrote: > On 10/18/13 18:12 , "Łukasz Stelmach" <[email protected]> wrote: > > > >>It was <2013-10-18 pią 14:07>, when Kanevskiy, Alexander wrote: >>> On 10/18/13 14:57 , "Łukasz Stelmach" <[email protected]> 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, 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 ? This depends on how broad is our definition of ABI. For example, it may include list of image (png) files provided by a package built with different options passed to the configure script. > 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. But it depends on how fast the SR for A is accepted. If the SR for A is accepted before maintainers of B and C push their tags. Then it won't work. Am I right? If the development model is going to be more open, then we may expect it to be quite common that a single developer posts a few patches for different packages (yes, topics, see below). > 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. Do you mean pushing with %topic= as described here[fn:1]. Looks good. I can push patches to different repositories and mark them as related. Is there any logic that prevents gerrit from generating SR in OBS after pushing a submit-tag onto a single patch until all the patches for a particular topic has been merged? Do maintainers need to push a submit-tags for all changes in the topic. > 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. I agree. > 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. Sounds promising. How can I post two patches to two different packages (A and B) and describe their relationship. A won't work (Requires) and/or build (BuildRequires) until B.rpm, rebuilt with the patch, is available. Footnotes: [fn:1] https://review.tizen.org/gerrit/Documentation/user-upload.html#_git_push -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpj0SdW_kB_w.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
