[Dev] Enhancing development workflow

Bartosh, Eduard eduard.bartosh at intel.com
Mon Oct 27 15:30:51 GMT 2014


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

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

Regards,
Ed 

-----Original Message-----
From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Stephane Desneux
Sent: Monday, October 27, 2014 4:29 PM
To: Lehtonen, Markus
Cc: dev at lists.tizen.org
Subject: Re: [Dev] Enhancing development workflow

On 27/10/2014 08:42, Lehtonen, Markus wrote:
> Hi,
> 
> On Fri, 2014-10-24 at 15:53 +0200, Stéphane Desneux wrote:
>> On 24/10/2014 15:25, Kanevskiy, Alexander wrote:
>>> On 24/10/14 15:58 , "Stéphane Desneux"
>>> <stephane.desneux at open.eurogiciel.org> wrote:
>>>
>> [...SNIP...]
> 
> 
>> dn't be rebuilt).
>>
>>>> Finally a question: do we still need pristine-tar branches ? Using 
>>>> upstream gits is far better IMO (even in case where the upstream 
>>>> branch is maintained only on tizen.org)
>>>
>>>
>>> pristine-tar branches allows us to recreate byte-to-byte exactly 
>>> same tarball for components like it was published on upstream download server.
>>> e.g. http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
>>>
>>
>> Yes, I know. But if I take your example, bash is also distributed in 
>> a git. So is it necessary to have a double maintainance mechanism 
>> (upstream branch + pristine-tar) ? What are the guidelines here ?
> 
> What do you mean by double maintenance? The pristine-tar branch is 
> automatically updated by gbs import and it always needs an 
> accompanying upstream branch (because pristine-tar only stores delta).
> 
> As I mentioned in some of my earlier emails, you can combine the 
> tracking of "real" upstream Git history and "real" upstream release 
> tarballs (including pristine-tar) by using the '--upstream-vcs-tag'
> option of 'gbs import'.
> 
> 
>>
>>>> FYI, we'll have to upgrade ~100 packages soon to align with Yocto 
>>>> versions. This makes Maciej's proposal even more interesting !
>>>
>>> I would suggest for such upgrade make a devel:xxxx:{common,ivi} 
>>> projects, and make sure that both common and ivi would be 
>>> buildable/testable after such changes.
>>> and once it’s confirmed, merge changes to tizen (or tizen_ivi) branch.
>>>
>>>
>>
>> Makes sense. We also have our private OBS to prepare things.
>>
>>> 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.

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.


--
Stéphane Desneux
Intel OTC - Vannes/FR
gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726
_______________________________________________
Dev mailing list
Dev at lists.tizen.org
https://lists.tizen.org/listinfo/dev
---------------------------------------------------------------------
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 mailing list