On 27/10/2014 16:30, Bartosh, Eduard wrote: >>>>> 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.
No, it won't be the same because where you'd have 1 separate project, you'd probably get multiple prerelease projects. At least, that's the usual way we can observe: group submissions are rare and not easy to handle (you can't 'upgrade' a package in a group submission). >> 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. In this case, those submissions shouldn't be handled by REs, because we usually can't make the difference between a "real" submission and a "development" submission... And the rest of the process would differ too: why creating images if there are build errors somewhere ? why doing sanity tests on 'devel' submissions ? So you're describing another type of submissions, which should be handled by the users themselves: it'd be the same mechanisme as sandboxes in gerrit, but for builds. And when you're here, you're not far from using home projects in OBS, which is not what we want. That's why I keep thinking that we can't use prerelease builds for anything else that their primary goal. Best regards, Stéohane _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
