[Dev] Enhancing development workflow
eduard.bartosh at intel.com
Tue Oct 28 17:05:04 GMT 2014
From: Stéphane Desneux [mailto:stephane.desneux at open.eurogiciel.org]
Sent: Tuesday, October 28, 2014 4:37 PM
To: Bartosh, Eduard; Lehtonen, Markus
Cc: dev at lists.tizen.org
Subject: Re: [Dev] Enhancing development workflow
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).
I was talking about group submissions of course. There is no reason to use individual submission when developing something more or less complex. All individual submissions will fail because of API incompatibility.
>> 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 ?
True those submissions should be ignored by RE until devs are done with them, i.e. until they're ready to be integrated into the product. Why to create images and test them? To make developer's life easier. They don't need to do it themselves and will clearly see when their work is ready for integration. How would you do it another way?
> 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.
Yeah, it would be good to isolate this types of submissions in another namespace (home:devel: or something like that). However, I don't agree that prerelease projects can't be used for this purpose right away. The only thing which needs to be done is to agree with RE that they don't touch submission until devs say it's ok to integrate it. Not a big deal from my point of view.
> That's why I keep thinking that we can't use prerelease builds for anything else that their primary goal.
I'm still not convinced.
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.
More information about the Dev