Moving these will be a change for the better, I believe. It will let us
import new versions of Buildbot without the hassle of CVS and in the
case of buildbotcustom, let others work on it more easily.
If anyone has objections to this plan please respond to this post. If I
don't hear anything by Tuesday, January 27th I will proceed with this.
I was wondering whether a git repo on github would be more like it for
buildbot. There is a bit of an additional learning curve, but it had the
advantage that our buildbot code would be exposed at the place where
I was pondered this. It would certainly make keeping in sync with
upstream easier. From a security standpoint I'm more comfortable having
it hosted inside of Mozilla's network. And selfishly, it would make it
more difficult for RelEng, as we'd have to go install git on 50 or 60
I don't think it's tough to import the Buildbot releases when they come
out, and we tend to only land patches that have landed upstream already
these days, so there's probably not big wins with this.
After doing some initial tests I think that we'd be better off to keep
mozilla/tools/buildbot and start fresh and import the current tip of
that to Mercurial. Two reasons for this:
1) The CVS history here is littered with vendor branches and other
branches. We're not going to get a good, clean import here.
2) Talos still uses the BUILDBOT_0_7_5_BRANCH so we need to keep that
I'll move forward with this tomorrow barring objections.
I recall that one of you guys had a patch of our tip vs buildbot, can we
get that into the repo? If feasible, even per-task?
I would think that if we had:
- a tagged import of vanilla buildbot
- on top, our version we use
we could import new buildbot releases by doing a
hg update -r BUILDBOT_0_7_9_RELEASE
dump the new tarball, hg addremove
which might make things easier.
Yeah, we have one, maybe two patches on upstream? I certainly planned on
including them. It's not much work to import vanilla then our patches,
as you suggest so I'll do that.