>>>> 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.
I don't understand your reasoning here as amount of builds is the same in prerelease or in separate project as both are linked to main project. >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. I agree that it makes sense to create separate project for big tasks. However, using prerelease project for not so big tasks makes it easy for developers to debug their submissions, get repos and images and keep them up to date until submission is ready. Regards, Ed -----Original Message----- From: Dev [mailto:[email protected]] On Behalf Of Stephane Desneux Sent: Monday, October 27, 2014 4:29 PM To: Lehtonen, Markus Cc: [email protected] Subject: Re: [Dev] Enhancing development workflow 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" >>> <[email protected]> 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 [email protected] https://lists.tizen.org/listinfo/dev --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
