[meta-intel] Branch and tag management

[Tom Zanussi]

On Fri, 2012-12-07 at 13:53 -0800, Flanagan, Elizabeth wrote:
> 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.
> 

OK, thanks for the explanation.  I don't see any problem with that for
the time being, so we can just continue with the status quo - it's
normally a simple matter of creating a new branch from master at any
given point in time anyway, but it's nice to have a heads-up a day or so
ahead of time just in case it's not...

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

OK, makes sense.

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

OK, thanks for doing that.  I could have done it myself but it wasn't
until I tracked down Rahul's e-mail to find the git hash he sent out
that it noticed the tag and then it dawned on me...

Tom

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