Hi folks
On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote:
> What did I miss?
After the discussion in our meeting today, it seems I did not properly
describe the problem good enough.
> Between different branches a lot of merges happen. Between master and
> sid in both directions, so changes can be done in both places and
> changelogs show a linear history. Between sid and *-backports.
Okay, what we regularly do is merges between sid and master. Those
merges are done by hand, but could be automated to some degree. Doing
them requires the developer to take a lot of decisions in one single
step:
- The changelog could be managed automatically.
- Added patches are usually meant just for this version and thus dropped
(modified patches are unclear).
- Other changes usually remain.
But, especially for the last two, exceptions might be possible and can't
be detected without revisiting every change in between one by one. Also
those merges are not reviewed the normal way via merge requests. This
makes those merge high risk, because
- too broad changes can be merged,
- changes can vanish,
- the changes are unverified, and
- inside large merges it is way easier to hide things.
What we get from the merges is
- a linear changelog,
- the ability to select where to apply changes first, and
- the ability to use per Debian distribution branches without confusing
users.
The linear changelog will make version tracking easier. However it is
actually a lie. In certain cases it is correct (patch to 6.10 merge
window and backported to 6.9.3, bug marked as fixed in 6.9.3). But in
others it is a lie (breakage in 6.9.1, patch in 6.9.2). So it should be
better to explicitly close such bugs in both 6.9.2 and 6.10~rc1.
We also don't really need to select early where a patch should be
applied. We can just backport merge requests to different branches, and
we can even create some scripts to make it easier. Normal changes to to
master, version specific fixes directly to this version. This also
reduces the mental load for submitters, as they can always start at the
master branch.
What is not longer possible in non-confusing ways is to use branches
named after Debian distributions. We would either need to do non fast
forward or do --their merges. Both variants are highly confusing to
users and the later one even got the same problems that I just described
above.
I believe we have to remove this task that currently is only done by
three people. This is the reason why I propose branching schemes based
on actual versions and not Debian distributions.
> ## Proposal
>
> Stop merging back changes, but create version distinct branches.
> Something like that:
master: uploaded to experimental
-> debian/release/6.6: uploaded to unstable and stable releases
-> debian/backport/6.6.1-1: uploaded to backports (not really
needed in most cases)
-> debian/security/6.6.1+1: extra security releases
Bastian
--
Beam me up, Scotty, there's no intelligent life down here!
