-
Notifications
You must be signed in to change notification settings - Fork 5
Build Service Structure
How the sources and different versions are organized in OBS
- OBS: openSUSE Build Service at build.opensuse.org
- IBS: Internal Build Service at build.suse.de
- osc: Build Service command-line tool
-
isc:
alias isc='osc -A https://api.suse.de'(you may name this alias differently)
The openSUSE build service command-line tool (osc) is used in several examples in this document. However, when working with the IBS (Internal Build Service) an additional parameter is required so osc knows what location to look in, otherwise it defaults to OBS (openSUSE Build Service).
Full names tend to be very long, therefore we generally shorten the name tokens to first letters when unambiguous.
Devel:Desktop:Mozilla:SLE-11-SP3:next → DDM:SLE-11-SP3:n or DDM:11.3:n → DDM:n if version is clear from context
SUSE:SLE-11-SP3:Update → SS:11.3:U → SSU if version is clear from context
home:YOU:Devel:Desktop:Mozilla:SLE-X:next ─► Devel:Desktop:Mozilla:SLE-X:next ─┬─► Devel:Desktop:Mozilla:SLE-X:current ─► SUSE:SLE-X:Update
home:YOU:Devel:Desktop:Mozilla:SLE-X:current ──────────────────────────────────┘
Development happens at Devel:Desktop:Mozilla:SLE-X, where X is the SLE-Version.
Where the development of the current ESR-version happens.
Individual packagers should branch from these projects to their home. That allows for
- better synchronisation among several people working on updates
- reviewing the submit in a neutral territory (when there is time for it)
These are intended as a common place to put work or reasonably self-contained WIP on the next ESR release.
Since the ESR have 3 months (2 cycles) overlap, it is possible (and desirable) to have the next ESR release ready before the current one is EOLed. Given that Beta releases are (supposed to be) rather stable, we should aim at working on the Beta builds as soon as they are available, which is roughly 4.5 months (18 weeks) before the EOL of the current ESR version.
Before the Beta is tagged, it may be a good idea to build Nightly (mozilla-central). On the other hand, given the speed of development the need to have these builds at any cost is probably not justifiable. Thus we'll probably try to do it "from time to time".
When the time comes to actually release these next ESR versions, we will want to copy the sources locally from :n to :c and submit as usually. This a rare case when working directly on the :c packages (and not via another proxy branch in one's home project) may be reasonable (that doesn't mean the proxy method is bad).
Main Mozilla openSUSE community repository to usually contain stable versions of many packages based on the Mozilla source platform. Most of the time totally in sync with what ends up in Factory/Tumbleweed and SLE but installable on all supported distributions as backports.
This repo can hold beta versions. Currently mostly inactive.
Repository which used to hold Aurora and Dev Edition packages. Currently not active.
Repository to test certain new major changes if required and too risky to hit production.
Source package archive which is not necessarily built but holds old obsolete source package for archiving reasons if anybody wants to create binaries out of it.
This is the Factory/Tumbleweed devel repository. Everything which will eventually end up in Factory/Tumbleweed is staged there.
Repository to contain Firefox addons. Currently it still holds old-style addons which are not supported anymore in recent versions of Firefox.
Understanding source structures
Packaging
Debugging
Debugging Firefox with QtCreator
Additional info