Please provide tags

[yann-morin-1998]

Hello!

Currently, the branches are constantly rebased on top of the corresponding
stable branches. That's nice because we can all benefit from fixes from
upstream. :-)

However, this causes some annoyance to build systems, like Buildroot,
because the branches are not stable, and there is no way to have
reproducible builds over time.

The situation now is as follows:

• either we use a branch name, and the build are non-reproducible
  because the branches change quite often, and two builds are not
  guaranteed to use the same sources;
• or we use a sha1 to refer to a specific changeset, and we have
  reproducible builds, except the sha1 would disapear next time the
  branch is rebased.

This causes quite some pain to us. For example, the Buildroot project had
a demo booth [0] at the recently ended Embedded Linux Conference, where
we were demonstrating a Raspberry Pi 2 running a firmware built with Buildroot.
Part of the demo was to point to the recipe to reproduce it [1], so interested
people can try and see by themselves. At the time we did the demo, we were
using a specific changeset on the rpi-3.19.y branch, but that changeset is
now gone.

Another example is that when Buildroot tags a release, we point to a sha1
for the Rapsberry Pi Linux kernel to use. And that is only valid for a short
period of time, which is until the corresponding branch is rebased.

I guess other build systems (Yocto, OpenWRT...) do all have the same issue.

Would it be possible that you provide tags (and that they not be over-
written), so that it is possible to provide users with dependendable
references?

If I may, I'd suggest the following scheme:

• for non-stable branches, after a rebase on an upstream version (say,
  v3.19.2), create a tag named v3.19.2-rpi-0. If there are more commits
  on that branch, you can create further tags, v3.19.2-rpi-1,
  v3.19.2-rpi-2 and so on. Then, on the next rebase (say, to v3.19.3),
  you can tag restarting the sequence to 0: v3.19.3-rpi-0, v3.19.3-rpi-1
  and so on...
• for stable branches, after merging the upstream branch (say linux-3.18.y),
  create a similarly named sequence of tags.

The tags are guaranteed to be unique, because they contain both the upstream
version and a sequence number specific to RPi.

Of course, if you prefer another naming scheme or whatever, we would all be
glad to have tags we can depend on.

Thanks you! :-)

Regards,
Yann E. MORIN.

[0] https://plus.google.com/+ThomasPetazzoni/posts/iLcjbrbP1Gi
[1] http://elinux.org/Buildroot:TechShowcase2015_Demo

[popcornmix]

The stable branches (e.g. 3.18.y) don't get rebased, so should have a linear history (including the upstream merge comits). What's the benefit of tags here?

For non-stable branches I can see the use of tags. Not sure we need a tag every commit.
I think if a tag is created before every rebase, then you should be able to see any commit ever made from each of these tags. It will also prevent github from garbage collecting, so any git hash reachable from the tags (which is every commit) should persist permanently, and can be used as external references.

[yann-morin-1998]

@popcornmix:

• stable branches: indeed, they are not rebased. What I meant was that
  providing tags on stable branches would make them "homogeneous" with
  non-stable branches. One could use tags, whether from a stable or
  non-stable branch alike. Tagging the merge is probably the best and
  easiest solution.
• non-stable branches: of course, I do not expect all commits to be
  tagged! That would be tedious and useless. Tagging before a rebase
  has the disadvantage that one can't use a stable reference untill
  there is a rebase [*]. Tagging right after the rebase is probably
  better IMHO. The best of both worlds would be to have a tag before
  and after! ;-) Of course, any tag will be greatly appreciated!

[*] Yes, sha1s topologically before the tag would still be reachable,
as you noticed. Still, if one could just be able to use tags, that
would be a "homogeneous" experience.

Thank you for the quick and positive response! :-)

Regards,
Yann E. MORIN.

[diederikdehaas]

A tag/release would also help when ppl need to have the kernel headers to build their own modules.

So if a new version of (for example) raspberrypi-bootloader package gets created and a tag is made for that same source code, then ppl can check out the tag and would be assured to have the exact code that was used to build the kernel itself.

My 0.02

[diederikdehaas]

As the releases now do get tagged, shouldn't this issue be closed?

[XECDesign]

Yup, I suppose so.