> -----Original Message----- > From: [email protected] [mailto:dev- > [email protected]] On Behalf Of Kanevskiy, Alexander > Sent: Friday, October 18, 2013 2:07 PM > To: Lukasz Stelmach; [email protected] > Subject: Re: [Dev] [SCM] inter-package patch dependencies > > On 10/18/13 14:57 , "Łukasz Stelmach" <[email protected]> > 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 [email protected] _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
