[meta-intel] Branch and tag management

[Flanagan, Elizabeth]

On Fri, Dec 7, 2012 at 2:25 PM, Tom Zanussi <tom.zanussi at intel.com> wrote:
> 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

Actually, we gpg sign tags. It's a pretty short list of folks who have
that ability. We should discuss getting either another gpg key for
meta-intel tags or getting the main gpg private key into the repo
maintainers hands.

-b

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