[Dev] Enhancing development workflow

Lehtonen, Markus markus.lehtonen at intel.com
Mon Oct 27 07:42:46 GMT 2014


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. 

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