[Dev] Enhancing development workflow
stephane.desneux at open.eurogiciel.org
Tue Oct 28 14:37:17 GMT 2014
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.
More information about the Dev