[meta-intel] Branch and tag management

[Flanagan, Elizabeth]

On Fri, Dec 7, 2012 at 12:36 PM, Tom Zanussi <tom.zanussi at intel.com> wrote:
> On Fri, 2012-12-07 at 11:26 -0800, Darren Hart wrote:
>> I discussed branching and tagging with Beth today.
>>
>> Beth uses branches for milestones as they sometimes change before the
>> final milestone build is complete. For reasons largely based in
>> paranoia, she would like to retain the milestone tags as long as the
>> milestones can be downloaded from the website, which is about 6 months.
>>
>> So, what this means for meta-intel is the following. We will continue to
>> use branches for milestones and replace them with tags once the final
>> milestone is built. THIS MEANS THAT MILESTONE BRANCHES MUST TRACK MASTER
>> EXACTLY. NO CHERRY PICKING, FAST FORWARDS ONLY. If we don't do that, the
>> branch must stay around as it won't be exactly reproducible with a tag
>> once the branch is removed.
>>
>> For the existing branches which do not have their HEAD also in master,
>> they will have to remain until the download is remove. This means that
>> eventually we will be able to purge the static milestone branches. The
>> only permanent branches will be master and one branch per release (no
>> release-next) branches should be needed.
>>
>> I haven't replaced any of the old branches with tags quite yet as I
>> wanted this group to have a chance to respond or raise concerns before
>> we put this into effect. Any additional thoughts?
>>
>
> Up until the 1.4 M1 milestone RCs, nobody but Beth had anything to do
> with the milestone (or release) branching and tagging (which also
> explains why nobody has any clue about the current set of tags and
> branches in there), so I'm not sure what we really need here.
>

Let me explain what we currently have, why we currently have it, and
what the path forward is. I think this should clarify things a bit and
help folks understand things.

We currently require that all repos that the autobuilder uses to
generate releases maintain milestone and release branches that are the
same as those in poky. The reasons behind this is that the autobuilder
is repo ignorant. It knows little about layers, only that when it
builds, say, from the poky 1.4_M1 branch, that it should utilize the
1.4_M1 branch for all repos. This is problematic for a few reasons,
but given the limitations of buildbot at the time, it was the best
solution to a sticky problem.

What this meant for repo maintainers is that we were dictating
branching and tagging policy. I've never been particularly happy about
that and have been wanting to make the autobuilder more layer aware
for some time now, to enable repo maintainers to have their own
branching and tagging policy. It's obviously not sustainable in the
long run, but, again, at the time it was the least worst solution.

With the latest version of buildbot, we now have the ability to do
some interesting things, like customize the force build page. One of
the things I'm working on now is this upgrade. During the upgrade, I'm
planning on making the autobuilder layer aware. So when a person goes
to kick off a buildset, the autobuilder has knowledge of all layers
within that buildset and can allow people to "mix and match" the
different layers. Think being able to select each layers
repo/branch/tag/git hash independently.

Unfortunately, this doesn't help us now as I don't anticipate this
being finished until M4. What this means is that, for the time being,
I will still need milestone branches for meta-intel. As long as these
branches track master, once they are done, we can tag them and remove
them. If they don't track master, then they have to stick around.

> For the past couple RCs, Beth has asked me to create an RC branch for
> the RC, which is fine, but all I did was simply take what was in master
> at the time and create new branch with the current contents of master.
> Why can't we just have this happen automatically, or for that matter,
> just have the milestone build process create a tag at the current HEAD
> of master as a record of what was built.

Because we generally don't tag until after the build. The reason why
is that I've hit too many "kill the build, we forgot xyz" to make me
want to tag prior to build. As tags do not move, having 1.4_M5.rc9 due
to a misbuild is something I want to avoid.

> Or if that won't work for some
> reason, at least have a scheduled date and time for each RC or release
> that we have to have whichever branch ready for the build - I don't
> think the current ad hoc tracking down repo maintainers to create a new
> branch will really work well over time.

I agree. It's why I'm planning the autobuilder mix and match. That
will take some time unfortunately, but once it's in place, we won't
have a need for the tracking down of repo maintainers.

>
> Other than cherry-picking fixes and BSP-specific commits into the
> official release branches following a release, I don't see why we have
> to worry about the details of the branching or tagging for milestones or
> releases.
>
> Also, are people expecting certain tags for the final releases?  Again,
> not having been involved in the branching and tagging before, I don't
> know, but Song apparently has already received complaints about missing
> tags.

This would be the 1.3 tag. Sorry about the delay, but I'm still
playing a bit of catchup. The tags have been created and pushed.

> Which tags are those and what are they supposed to look like?
> The current set in both meta-intel and poky don't seem consistent, so
> hard to tell from that...
>
> Tom
>

-b

-- 
Elizabeth Flanagan
Yocto Project
Build and Release