On 27/10/2014 08:42, Lehtonen, Markus wrote: > Hi, > > On Fri, 2014-10-24 at 15:53 +0200, Stéphane Desneux wrote: >> On 24/10/2014 15:25, Kanevskiy, Alexander wrote: >>> On 24/10/14 15:58 , "Stéphane Desneux" >>> <stephane.desn...@open.eurogiciel.org> wrote: >>> >> [...SNIP...] > > >> dn't be rebuilt). >> >>>> Finally a question: do we still need pristine-tar branches ? Using >>>> upstream gits is far better IMO (even in case where the upstream branch >>>> is maintained only on tizen.org) >>> >>> >>> pristine-tar branches allows us to recreate byte-to-byte exactly same >>> tarball for components like it was published on upstream download server. >>> e.g. http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz >>> >> >> Yes, I know. But if I take your example, bash is also distributed in a >> git. So is it necessary to have a double maintainance mechanism >> (upstream branch + pristine-tar) ? What are the guidelines here ? > > What do you mean by double maintenance? The pristine-tar branch is > automatically updated by gbs import and it always needs an accompanying > upstream branch (because pristine-tar only stores delta). > > As I mentioned in some of my earlier emails, you can combine the > tracking of "real" upstream Git history and "real" upstream release > tarballs (including pristine-tar) by using the '--upstream-vcs-tag' > option of 'gbs import'. > > >> >>>> FYI, we'll have to upgrade ~100 packages soon to align with Yocto >>>> versions. This makes Maciej's proposal even more interesting ! >>> >>> I would suggest for such upgrade make a devel:xxxx:{common,ivi} projects, >>> and make sure that both common and ivi would be buildable/testable after >>> such changes. >>> and once it’s confirmed, merge changes to tizen (or tizen_ivi) branch. >>> >>> >> >> Makes sense. We also have our private OBS to prepare things. >> >>> PS. beside of devel: project, there is always possibility of agreeing with >>> release engineers that certain submission ID is used to accumulate changes >>> that includes multiple packages at same time. so, using pre-release >>> project as temporary “upgrade” sandbox. >> >> Yes. That's also an option, but it shouldn't last too long (say less >> than a week) because the prerelease builds incur some extra load on the >> infrastructure. > > Why do you think a long-lasting pre-release project would be a problem? > From what I can tell, the builder load has been pretty decent on average > and there should be reserves to carry few extra projects. >
Well, a few weeks ago, there was 40 crosswalk instances building simultaneously on the 25 hosts. This is not very efficient and keeping prerelease projects longer simply incurs more builds. I just think that we should limit the prerelease usage to what it's good for: continuous integration with low number of breakages. For big integration tasks, having a separate project (linked or not the main project) without prereleases is probably better: finally there will be a prerelease to push the work into the main project. -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
