On 28/10/2014 18:05, Bartosh, Eduard wrote: > -----Original Message----- > From: Stéphane Desneux [mailto:[email protected]] > Sent: Tuesday, October 28, 2014 4:37 PM > To: Bartosh, Eduard; Lehtonen, Markus > Cc: [email protected] > 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 errors... 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 :) BR Stéphane _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
