[Tizen General] Why not use tags to mark releases rather than the manifest file?

VanCutsem, Geoffroy geoffroy.vancutsem at intel.com
Fri Sep 13 07:32:31 GMT 2013


> -----Original Message-----
> From: general-bounces at lists.tizen.org [mailto:general-
> bounces at lists.tizen.org] On Behalf Of Artem Bityutskiy
> Sent: Friday, September 13, 2013 9:19 AM
> To: Hanchett, Paul; Kanevskiy, Alexander
> Cc: general at lists.tizen.org
> Subject: Re: [Tizen General] Why not use tags to mark releases rather than
> the manifest file?
> On Thu, 2013-09-12 at 10:59 -0700, Hanchett, Paul wrote:
> > Why not use tags to mark a particular release, rather than the object
> > ID in the manifest file?  I see several advantages:
> >       * You get a single value that can be handed to gbs/obs to pull
> >         all of the packages as of a particular point in time; new
> >         commits have no impact on the git tag (unlike the branches we
> >         use now.)  In fact, you might not even need manifest
> >         files........
> >       * Now, it becomes dead easy to *see* in each repository the
> >         version that was actually released.  Placing tags for other
> >         significant events makes those visible in every repository.
> > I'm sure there are other advantages.  Is there a down side?  (I'm
> > relatively new to git...)
> I am not an expert in the area, let me CC Alexander.
> But I believe it is not easy to tag all the repos, and then make sure individual
> package maintainers do not accidentally remove the tag, or change it.
> Commit ID's are more persistent. Tagging is less reliable.

I'll let Sasha provide more details but from what I can see we are actually already using tags and commit IDs. The manifest files that are published along with the images (i.e. *not* the ones coming from review.tizen.org:/scm/manifest) do contain a list of all Git repos for each package and both the tag and commit ID that made it into that particular image. It's not 100% there yet (see previous mails sent to the mailing list on the subject) but that's the idea anyway.

Example (taken from http://download.tizen.org/releases/milestone/tizen/ivi/latest/images/ivi-release-mbr-i586/tizen_20130829.9-ivi-release-mbr-i586.manifest.xml): 
<project name="profile/ivi/automotive-message-broker" path="profile/ivi/automotive-message-broker" revision="submit/tizen/20130823.193320-0-gdf7c1e67ccb49257bd88e771462c70fef060d5fd"/>

In this example:
- "submit/tizen/20130823.193320" is the tag
- "df7c1e67ccb49257bd88e771462c70fef060d5fd" is the commit ID

When you initialize and then sync your dev machine using the repo tool and such manifest file, it should check out the right branch/tag/commit ID for you so you'd be building the right version of the sources.

> And yes, I do see why you do not want to use SRPMs as Joel suggested.
> Git trees with the history and the right commit ID for the release is just a lot
> more usable than SRPMs. It is easier to check the code then, do 'git log -p' or
> 'git blame', quickly hack the code and commit, etc.
> I personally really do not consider SRPMs to be useful for anything. For me
> SRPM is just a temporary thing between the git repo and the RPM.

Intel Corporation NV/SA
Kings Square, Veldkant 31
2550 Kontich
RPM (Bruxelles) 0415.497.718. 
Citibank, Brussels, account 570/1031255/09

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 General mailing list