[Dev] Enhancing development workflow

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Tue Oct 28 18:06:51 GMT 2014

On 28/10/2014 18:05, Bartosh, Eduard wrote:
> -----Original Message-----
> 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
> 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.

But you'll agree that group submissions are less handy than linked
projects, because we still can't do a few things in the prerelease
projects: trigger rebuilds, drop a package, update a revision of a
package without resubmitting a whole group etc.

Well, we *will* be able to do it, but right now it's not possible.

>>> 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?

The only problem we (as RE) have is that we don't identify those 'devel'
submissions - such concept, namespace, ... doesn't exist yet. Otherwise
it looks good.

Also, I don't mean that we shouldn't create images for the developer :)
 I say that creating an image while there are some build errors is
useless, and that making sanity tests on those images is also useless.
Even creating a snapshot is questionable... But if everything builds
fine, let's create the snapshot, then assemble the images and finally
run the tests !

>> 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.

Isolating in another queue would be better IMO. You'd have less human

With or without "namespaces", I volunteer to test that on upcoming
upgrades: we'll have ~100 base packages to align with Yocto :) If it
doesn't work well with prerelease builds, we can still switch to the
good old method...

>> 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.

If some things are adjusted, it's different :)


More information about the Dev mailing list