[Dev] Enhancing development workflow

Kanevskiy, Alexander alexander.kanevskiy at intel.com
Fri Oct 24 15:02:10 GMT 2014


On 24/10/14 16:53 , "Stéphane Desneux"
<stephane.desneux at open.eurogiciel.org> 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:
>> 
>>> Hi all,
>>>
>>> +1
>>>
>>> Let me summarize (and make small adjustments on Maciej's proposal):
>>> - for "big" updates (ex: systemd), we could harmonize the naming and
>>> have a "devel_common" branch (in place of Maciej's for-next branch),
>>> submitted and built in the devel:Tizen:Common project, with images
>>> published in snapshots/devel/common. If it's a profile-specific
>>>package,
>>> the branch could be named devel_<profile>
>> 
>> for targeted upgrades of big components or something that require
>>extended
>> period of development we have for already quite long time devel:
>>hierarchy
>> of build projects and devel/* branch hierarchy in packages.
>> E.g. devel:x11:common
>> https://build.tizen.org/project/show?project=devel%3Ax11%3Acommon  ->
>> devel/x11 branches.
>> 
>> Maintainers who are planning to do such big upgrades can request devel:
>> projects based on their neeeds and then ask to kill it once this big
>>pile
>> of changed merged into normal releases.
>> 
>
>So devel_<profile> would be the right name for the git branch ? We can
>also tune the git-obs-mapping to send the submissions to the appropriate
>devel:* project

I’d prefer to have devel/* topical hierarchy instead of per profile
devel_$profile.
if we plan some big upgrades, it shouldn’t be targeted to specific
profile, but more about functionality and we must make sure that it
doesn’t break any other profile.

in other words: if we plan to upgrade let’s say “systemd” we must make
sure that same upgrade would be working solution for
ivi/mobile/wearable/etc.

>>>- correct me if I'm wrong: the above rules would work only if the
>>> upstream branch always goes forward (push --force should be forbidden
>>>on
>>> the upstream branch). Otherwise, some inconsistencies can be introduced
>>> for old tizen_x.y.z branches.
>> 
>> for upstream code generation it’s important that upstream tags are not
>> overwritten.
>> 
>> e.g. if package version 1.1-22 ($sha_1) is needed to be built, upstream
>> tag 1.1 ($sha_2) should be (grand-…)parent of $sha_1.
>> 
>> I hope Markus would be able to add more details here. But in short,
>> upstream tags are the most important things.
>> 
>
>Yes: the old accepted commits must still have ancestors on the upstream
>branch. Otherwise, gbs export won't run correctly (and old versions
>couldn't be rebuilt).

well, latest version of git-buildpackage (underlying component used by
gbs) is able to export packages correctly even if maintainer somehow
screw-up upstream branch/tags.
It wouldn’t generate nice patches, but would still be able to export
sources in buildable format based on some revision.


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

benefit of such “double maintenance” is that as developer, person has
ability to work with upstream git in best possible way and at the same
time, once package is exported to release system, then result would be
matching upstream tarball. So, if someone would like to verify
bash-4.3.tar.gz in our distributed package (src.rpm) is authentic to
upstream http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz, he/she would be able
to use http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz.sig to verify integrity
of this tarball.

>What are the guidelines here ?

Because Tizen has a lot of legacy from earlier stages, it was never
enforced rules for pristine-tar or upstream. However, it was strong
request to try putting appropriate upstream branches/tags/pristine-tars
into tizen repositories once packages are upgraded to new versions.


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

At the moment, we rarely have times when absolutely all workers are busy
with rebuilding something (well, we need to fix crosswalk builds, but that
is separate story).
Also, in Tizen OBS there are specific settings on priorities for builds,
so something that is not official builds (Tizen:*:$profile hierarchy) has
lower priority.
if we see that those temporary sandboxes causing issues, those priorities
can be adjusted even more.

So, don’t worry about that at the moment. or ping me if you notice
something wrong happening :)


-- 
Best regards, Alexander Kanevskiy.



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