I really like the way "buildsymbols" and "uploadsymbols" works on trunk. I'd love to be able to call the following targets in a consistent way: package/uploadpackage installer/uploadinstaller fullupdate/uploadfullupdate I'd really love to be able to put these behind a "release" target, so a release could be a matter of: 1) adjust mozconfig 2) make release Right now, "installer" breaks on Linux. If we really don't want to do anything, we should probably just no-op on this platform so we can have a consistent set of release steps. Either that, or have this "make release"-type target make this kind of decision. There's no simple "update" target (must do something like "make -C tools/update-packaging full-update STAGE_DIR=../../dist DIST=../../dist AB_CD=en-US". The build system should provide reasonable defaults for these).

(In reply to comment #0) > Right now, "installer" breaks on Linux. If we really don't want to do anything, > we should probably just no-op on this platform so we can have a consistent set > of release steps. Either that, or have this "make release"-type target make > this kind of decision. I'm all for a no-op in this case.

> I really like the way "buildsymbols" and "uploadsymbols" works on trunk. I'd Well... :-( buildsymbols stores it's symbols in the "magic directory" $(topsrcdir)/../$(BUILDID) which is very sucky. I don't mind the general idea of pushing some/all of the upload logic into the build system from the release system, but we need to be smarter about it. > 1) adjust mozconfig > 2) make release Note that the current upload process depend on environment variables, not mozconfig variables, and this is probably the correct behavior. > Right now, "installer" breaks on Linux. If we really don't want to do anything, > we should probably just no-op on this platform so we can have a consistent set > of release steps. Either that, or have this "make release"-type target make > this kind of decision. I do not think "make installer" should be a no-op: in particular you don't end up with a target file like you normally would, which can be confusing. I think it makes more sense to have a "make release" uber-step which picks the correct substeps based on configuration. > There's no simple "update" target (must do something like "make -C > tools/update-packaging full-update STAGE_DIR=../../dist DIST=../../dist > AB_CD=en-US". The build system should provide reasonable defaults for these). Looks to me like it has reasonable defaults already... what happens if you don't set those vars?

(In reply to comment #2) > > I really like the way "buildsymbols" and "uploadsymbols" works on trunk. I'd > > Well... :-( > > buildsymbols stores it's symbols in the "magic directory" > $(topsrcdir)/../$(BUILDID) which is very sucky. I don't mind the general idea > of pushing some/all of the upload logic into the build system from the release > system, but we need to be smarter about it. Oh right, bent has a patch to fix this somewhere, but we were going to push the logic into tinderbox client, which sort of sucks. I'm not sure what the right solution really is in that case.

(In reply to comment #2) > buildsymbols stores it's symbols in the "magic directory" > $(topsrcdir)/../$(BUILDID) which is very sucky. I don't mind the general idea > of pushing some/all of the upload logic into the build system from the release > system, but we need to be smarter about it. Is this sucky because it doesn't get cleaned out, or some other reason? What if it was in e.g. dist/symbols (or something like that)? Was the idea behind this to keep the symbols around for a while in case they didn't get uploaded correctly, like Tinderbox does? > > 1) adjust mozconfig > > 2) make release > > Note that the current upload process depend on environment variables, not > mozconfig variables, and this is probably the correct behavior. > > > Right now, "installer" breaks on Linux. If we really don't want to do anything, > > we should probably just no-op on this platform so we can have a consistent set > > of release steps. Either that, or have this "make release"-type target make > > this kind of decision. > > I do not think "make installer" should be a no-op: in particular you don't end > up with a target file like you normally would, which can be confusing. I think > it makes more sense to have a "make release" uber-step which picks the correct > substeps based on configuration. I think that'd simplify things a lot. We could start using it for nightlies right away, but I think it'd take a while to get the verification we use for real releases all in place so we might call individual targets at least in the short term. > > There's no simple "update" target (must do something like "make -C > > tools/update-packaging full-update STAGE_DIR=../../dist DIST=../../dist > > AB_CD=en-US". The build system should provide reasonable defaults for these). > > Looks to me like it has reasonable defaults already... what happens if you > don't set those vars? Mea culpa, I tried it on branch and hit problems, it works fine for me on trunk, nevermind :)

(In reply to comment #3) > (In reply to comment #2) > > > I really like the way "buildsymbols" and "uploadsymbols" works on trunk. I'd > > > > Well... :-( > > > > buildsymbols stores it's symbols in the "magic directory" > > $(topsrcdir)/../$(BUILDID) which is very sucky. I don't mind the general idea > > of pushing some/all of the upload logic into the build system from the release > > system, but we need to be smarter about it. > > Oh right, bent has a patch to fix this somewhere, but we were going to push the > logic into tinderbox client, which sort of sucks. I'm not sure what the right > solution really is in that case. > IMHO these should probably go into e.g. dist/symbols, and if something above the buildsystem wants to keep them then it can go ahead and copy the contents somewhere else.

Right, that was bug 392909, and it has a patch. We could totally just check that in to fix buildsymbols.

This bug is pretty generic, should be more of a tracking bug for specific activities such as bug 406098.

I think mach solves this problem nicely.