Just wanted to file this so we don't forget about it.
11 years ago
Priority: -- → P3
I'll take a stab at this; I'm sure I'm gonna need some help with merging the code in, though.
Assignee: build → mozpreed
I took a look at this on Thursday, and found out an interesting side effect of doing a CVS import, namely that for files that do not have merge conflicts, they "magically become HEAD." That's... mostly fine, except for the fact that if you have dependencies on files that *do* have conflicts, you now have a broken state until you complete the merge (as opposed to being able to check the source in on the vendor branch, and merge it to head separately, which makes infinitely more sense). Anyway, we'll have to do this import in a coordinated fashion; I talked to rhelmer, and he says that the release automation doesn't auto-pull buildbot; he believed the try server stuff doesn't either. Bug 347947 talks about using a stable tag for tinderbox pulls, so we should probably do that for buildbot as well. I can apply a tag to the current state of the world and then do the import, and when we have a clean merge, update the production tag. That's easy enough to do, but I wanted to make sure that all the consumers of mozilla/tools/buildbot are *NOT* auto-pulling from CVS before I do this, since this is likely to break them if that's the case. rhelmer, robcee, and bhearsum: that sound correct to you?
None of the Buildbots I run auto-pull the tree. I don't know of any that do, either.
no, that shouldn't affect us. The unittest master just runs checkout on client.mk then does make -f client.mk checkout. I think we'll be ok there.
Alright, when bug 401156 gets sorted out, I'll go ahead and tag mozilla/tools/buildbot with BUILDBOT_MOZILLA_PRODUCTION, do the import, get help with the merge ;-), and then we can test 0.7.6 by pulling head, and get at (our version) of 0.7.5 by pulling the _PRODUCTION tag.
That sounds fine to me. As long as we still have access to 0.7.5 in tree, we should be good to go. I don't think any of our existing (qa) systems will need further patching to 0.7.5 and I'd just as soon start working with the newer version (and have a place to drop our own patches if needed).
Slight change of plans: there was some confusion on this, so we spent most of the day discussing the pros and cons (in little chunks on IRC). The upshot: bhearsum and I will do the import/merge tomorrow morning, and I've volunteered to create/maintain any possible 0.7.5 buildbot branch, should it become necessary; right now, the prevailing opinion is, it won't, and getting 0.7.6 in the tree is a way to merge our moz-specific 0.7.5 changes into 0.7.6, plus make more moz-specific 0.7.6 patches, if necessary. The currently deployed/working 0.7.5 code has been tagged with BUILDBOT_MOZILLA_PRODUCTION, and per CVS vendor branch procedure, upon import, non-modified files will become head. There will be no 0.7.5 branch unless it becomes necessary.
Created attachment 287555 [details] [diff] [review] 0.7.6 import conflicts merge I just checked in Buildbot 0.7.6: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=mozilla%2Ftools%2Fbuildbot&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-11-06+10%3A00&maxdate=2007-11-06+10%3A10&cvsroot=%2Fcvsroot This patch is to resolve the generated conflicts; it's pretty big, because it includes files that were deleted; the files that have actual conflicts worth looking at are: buildbot/changes/bonsaipoller.py buildbot/status/tinderbox.py buildbot/test/test_bonsaipoller.py In the case of bonsaipoller.py and tinderbox.py, I picked our versions over the 0.7.6 versions, as bhearsum said our versions are more current. In the case of test_bonsaipoller,py, I picked our revision, except for the addition of the testMissingRevisionResult method, which I would imagine couldn't hurt (but am not 100% sure; hence the r? ;-)
Comment on attachment 287555 [details] [diff] [review] 0.7.6 import conflicts merge OK. The tinderbox.py and bonsaipoller.py changes are fine. We should take our version of test_bonsaipoller.py as well, that testcase was purposely dropped (because it was wrong). I thought Brian had took those changes, but it appears he missed them. So, r+ to this w/ taking our version of test_bonsaipoller.py.
(In reply to comment #9) > So, r+ to this w/ taking our version of test_bonsaipoller.py. Landed with you, per our sanity check convo on IRC this morning. (Thanks for that :-) http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=mozilla%2Ftools%2Fbuildbot&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-11-08+10%3A00%3A00&maxdate=2007-11-08+10%3A10%3A00&cvsroot=%2Fcvsroot
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Comment on attachment 287555 [details] [diff] [review] 0.7.6 import conflicts merge Removing review to remove it from my queue.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.