opensuse / firefox-scripts Goto Github PK

Find a possibility to have create-tar.sh work for both FF and TB.
If not, sync them as close as possible in order to merge updates from one to the other quickly.

Currently, we copy the whole of create-tar.sh into OBS.
So there is the chance that changes to one create-tar.sh do not get merged to other OBS branches, having several similar but different scripts hanging around (which is the state I started from).

In principle, this github repo here should prevent this.
But there are two problems I see:

1. Keeping this repo conflict free will probably be a bit challenging, if we only copy the final create-tar.sh into it from whatever FF or TB version we just built. The main content stays the same, but RELEASE_TAG, VERSION and so on change, which will probably lead to some merge conflicts.
   This is not too bad, but would cause some workflow-friction nonetheless.
2. There are 2 additional step right now: copying create-tar.sh to your build-dir, and after editing and running, copy it back to this repo. This final step can easily be forgotten and thus possible changes lost, or at least made branches inconsistent.

To prevent this, I propose to split off the first few lines from create-tar.sh, so basically contain only the "source stamp info". Lets call it something like tar_stamps, which would look like:

$ cat tar_stamps
PRODUCT="firefox"
CHANNEL="esr68"
FF_RELEASE_TAG=""
PREV_VERSION="68.0"
PREV_VERSION_SUFFIX="b11"
VERSION="68.0"
VERSION_SUFFIX="b14"

The rest of create-tar.sh would simply go into your $PATH and get this stamp-file as a commandline argument, source it, and start working.

firefox-scripts would not get these stamp-files, but firefox-maintenance and OBS would (but would not get create-tar.sh)

With that approach accidental "lost/unmerged changes" to create-tar.sh will get very unlikely, as it will not be copied anymore at all, but lives in the repo, which should be part of your $PATH.

For a new version, you only copy the tar_stamps from the last version and adapt those 7 lines.

Comments?

Once Thunderbird is going to be in firefox-maintenance, sync_ff needs a way to handle this.
Possibly by checking MozillaThunderbird.spec vs. MozillaFirefox.spec or something like this.

create-tar.sh already parses which build-candidate is the release (which is done stupidly, but I know of no direct way to do this), so it could also directly parse the timestamp for the spec-file from:
http://ftp.mozilla.org/pub/firefox/candidates/68.2.0esr-candidates/build1/linux64_info.txt

Seems that nowadays the correct mozilla branch and revision for a TB release is encoded in the file .gecko_rev.yml within the comm repository. We could possibly use this.

Writing the changelogs by hand (copying from the webpage) is cumbersome.
Add a script like for mfsa, to parse the release notes in https://github.com/mozilla/release-notes

Thunderbird moved their release notes from https://github.com/mozilla/release-notes to https://github.com/thundernest/thunderbird-notes

Unfortunately, they also changed the format to YAML.
It might be difficult to distinguish now automatically between MFSAs and TB-releasenotes.

Add a check whether ./.osc exists and add a warning if not (but probably allow to continue)