Hi folks

The repository for the Linux kernel in Debian currently makes heavy use
of merges, which will always conflict due to changelog changes. This constitutes high cognitive busy load, for pretty small gains.

After already removing the manually modified abiname, we can drop more
manual work with that. As the now requires operarions will not longer
produce conflicts, we can easily create tools if we want.

What did I miss?

## Current state

The linux repo uses a kind of classic Debian like branch setup:
- master: for development work, uploaded to experimental
- sid: uploaded to sid
- bookworm
- bookworm-backports
- bookworm-security

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.

Those merges are done by hand. In many cases conflict with each other
due to mainly changelog changes, which needs to cleaned up by hand.

## Proposal

Stop merging back changes, but create version distinct branches.
Something like that:

master: uploaded to experimental

debian/main/6.6: uploaded to unstable and stable releases

-> debian/backport/6.6.1-1: uploaded to backports
-> debian/security/6.6.1+1: extra security releases

## Disadvantages

- All changes need to go via master, which they should do anyway.
- In case of patch backports:
- A bug will be closed multiple times.
- The exact version a change reached unstable is not longer visible.
- No automatic way for patches required in the backports suites (I have
a larger config overhaul, where we could add something for that.)

--
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin

Sadly I did not get any response.

Bastian

On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote:

Hi folks

The repository for the Linux kernel in Debian currently makes heavy use
of merges, which will always conflict due to changelog changes. This constitutes high cognitive busy load, for pretty small gains.

After already removing the manually modified abiname, we can drop more
manual work with that. As the now requires operarions will not longer produce conflicts, we can easily create tools if we want.

What did I miss?

## Current state

The linux repo uses a kind of classic Debian like branch setup:
- master: for development work, uploaded to experimental
- sid: uploaded to sid
- bookworm
- bookworm-backports
- bookworm-security

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.

Those merges are done by hand. In many cases conflict with each other
due to mainly changelog changes, which needs to cleaned up by hand.

## Proposal

Stop merging back changes, but create version distinct branches.
Something like that:

master: uploaded to experimental

debian/main/6.6: uploaded to unstable and stable releases

-> debian/backport/6.6.1-1: uploaded to backports
-> debian/security/6.6.1+1: extra security releases

## Disadvantages

- All changes need to go via master, which they should do anyway.
- In case of patch backports:
- A bug will be closed multiple times.
- The exact version a change reached unstable is not longer visible.
- No automatic way for patches required in the backports suites (I have
a larger config overhaul, where we could add something for that.)

--
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

--
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Jan 13, 2024 at 01:10:50PM +0100, Bastian Blank wrote:

Moin

Sadly I did not get any response.

I have seen it, but have not yet digged into it (in fact marked the
mail as important and unread/todo).

How would in the new scheme typical workflow look like? Maybe this
could help better understand the proposed changes. As you know in my
focus is mainly working on the stable branches, be it to rebase to
more recent stable upstream version, then targetting in either point
releases or security uploads, but as well picking single needing fixes
(for instance targetted security fixes).

It would help how the current work on e.g. the bookworm or
bookworm-security branches would work with the scheme. From importing
newer 6.1.y version (and rebasing rt patches) to cherry-pick single
fixes as needed. How then merge viceversa the security and stable
branches for instance.

(work on the branch for unstable is similar, though we have there no disitinction about the target upload).

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

On Sun, Jan 14, 2024 at 09:07:07PM +0100, Salvatore Bonaccorso wrote:

How would in the new scheme typical workflow look like? Maybe this
could help better understand the proposed changes. As you know in my
focus is mainly working on the stable branches, be it to rebase to
more recent stable upstream version, then targetting in either point
releases or security uploads, but as well picking single needing fixes
(for instance targetted security fixes).

Adding patches to all:
- Via merge request to master
- Can be cherry picked to other release branches down the chain
unstable, stable, security as necessary

Adding patches only required for release:
- Via merge request to debian/release/6.6
- Can be cherry picked further down the same way

Adding new upstream releases for unstable, stable:
- Import new upstream release into debian/release/6.6

Adding new upstream releases for security or even go back from current
state of release branch (this is an emergency procedure):
- Create debian/security/6.6.9 from the nearest tag
- Import new upstream release

Targeted fixes for security:
- Create debian/security/6.6.9 from debian/6.6.9-1 tag
- Choose new version (6.6.9+1-1)
- Add patches. We can also try the GitLab feature for private merge
requests then

Uploads to backports:
- Create debian/backport/6.6.9-1+deb13u1 from debian/6.6.9-1+deb13u1 tag
- Choose new version (6.6.9-1+deb13u1~bpo12+1)
- (For now: change things like compiler)
- Release from there

In the end creating branches on releases needs the operator to find a
suitable ancestor, which might be a tag. These branches are then thrown
away when they served their purpose.

It would help how the current work on e.g. the bookworm or
bookworm-security branches would work with the scheme. From importing
newer 6.1.y version (and rebasing rt patches) to cherry-pick single
fixes as needed. How then merge viceversa the security and stable
branches for instance.

No merges between release branches are ever performed. Only merge
requests can be merged into those and then cherry picked further down.
You create a new branch from a suitable state.

(work on the branch for unstable is similar, though we have there no disitinction about the target upload).

Uploads to testing directly are pretty rare and reserved for security
updates. So you would use the same procedure are stable security fixes:
branch to debian/security/6.6.9 and go from there.

I hope that makes it more clear.

Regards,
Bastian

--
You're too beautiful to ignore. Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 2024-01-15 01:14, Diederik de Haas wrote:

On Thursday, 21 December 2023 17:30:26 CET Bastian Blank wrote:

- All changes need to go via master, which they should do anyway.

I think this as a general rule, with few clearly defined exceptions (like stable release updates), would be a good thing. Now it feels like targeting 'sid' is a way to (quickly) 'sneak' in some changes.
Moreover targeting 'sid' or 'master' seems rather arbitrary atm.

A partial explanation for the confusion is that right now the master
branch is where you land changes that target experimental, while the sid
branch is for changes targeting sid. However, obviously not all commits
end up in Debian experimental - but the guideline is to always send
changes to master anyways.

This double role of the master branch, namely landing branch for all
changes and branch meant for experimental, is what confuses me at least.
Maybe a better approach could be creating an additional branch for experimental, enforcing that all changes go via master, and then merging
from master to the "target distribution" branch as needed?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I don't feel qualified on the general topic, but ...

On Thursday, 21 December 2023 17:30:26 CET Bastian Blank wrote:

- All changes need to go via master, which they should do anyway.

I think this as a general rule, with few clearly defined exceptions (like stable release updates), would be a good thing. Now it feels like targeting 'sid' is a way to (quickly) 'sneak' in some changes.
Moreover targeting 'sid' or 'master' seems rather arbitrary atm.
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZaUhuQAKCRDXblvOeH7b bpAGAP9BYK3YiUVXQ8fvPc+QzV0S5+lD7R2AZzBBRx9npC6eHgD/WVNJVO79x0VR bn+anHVuUKEphfSPYOLAgmop7Mmkyws=
=H7/O
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 15 January 2024 14:07:42 CET Emanuele Rocca wrote:

A partial explanation for the confusion is that right now the master
branch is where you land changes that target experimental, while the sid branch is for changes targeting sid. However, obviously not all commits
end up in Debian experimental -

And my proposal is that 'all' changes (refactorings/new modules) target the master branch which then land in Experimental first. And when the time is right (usually around version .0/.1/.2), then it gets uploaded to Sid.
But imo new features/modules should NOT go directly to Sid.

but the guideline is to always send changes to master anyways.

I don't think such a guideline exists, at least not 'formally'.
There currently is just 1 (old) MR targeting Sid, but there have been more in the past.
I just checked the merged MRs and the current practice does seem to be targeting master, but there are some older ones (>4 months) which went
directly to Sid which I think they shouldn't.
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZaU3gwAKCRDXblvOeH7b bqQQAQDewcF/T2gq05Sq1fBfsKfaUWgUecaJkv1jjFStSdF3jgEA+hzwOCjz9P+2 lSXeLz3u3zQvguo/e/PSZZbWH7ZNYg4=
=GGlc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jan 17, 2024 at 08:06:18PM +0100, Bastian Blank wrote:

On Wed, Jan 17, 2024 at 07:18:27PM +0100, Ben Hutchings wrote:

On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote:

The repository for the Linux kernel in Debian currently makes heavy use of merges, which will always conflict due to changelog changes. This constitutes high cognitive busy load, for pretty small gains.

I agree that this is a waste of time and resources for feature
branches. We ought to avoid that by automating changelog updates for changes to the Debian packaging (gbp dch or somethign similar).

Feature branches are not affected here.

Okay, I was not clear enough. But I was only talking about release
branches right now.

For feature branches we use merge requests, where GitLab can do what you
tell it to. But merges there are fine.

If we're going to change branch naming then we should be moving towards DEP-14, but this seems to diverge further.

I don't find any branches with version in DEP-14. So this is not even applicable here.

Well, DEP-14 defines debian/<suite>. Then suite is main/6.6 and so it
fits perfectly.

Bastian

--
Superior ability breeds superior ambition.
-- Spock, "Space Seed", stardate 3141.9

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jan 17, 2024 at 07:18:27PM +0100, Ben Hutchings wrote:

On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote:

The repository for the Linux kernel in Debian currently makes heavy use of merges, which will always conflict due to changelog changes. This constitutes high cognitive busy load, for pretty small gains.

I agree that this is a waste of time and resources for feature
branches. We ought to avoid that by automating changelog updates for
changes to the Debian packaging (gbp dch or somethign similar).

Feature branches are not affected here.

But I've never found these conflicts to be a big problem when merging
between different branches.

I always do. Which part needs to come from where? debian/changelog
from both, debian/config from both, but don't try to get debian/patches
from both sides.

Stop merging back changes, but create version distinct branches. Something like that:

master: uploaded to experimental

debian/main/6.6: uploaded to unstable and stable releases

-> debian/backport/6.6.1-1: uploaded to backports
-> debian/security/6.6.1+1: extra security releases

## Disadvantages

- All changes need to go via master, which they should do anyway.
- In case of patch backports:
- A bug will be closed multiple times.
- The exact version a change reached unstable is not longer visible.
- No automatic way for patches required in the backports suites (I have
a larger config overhaul, where we could add something for that.)

If we're going to change branch naming then we should be moving towards DEP-14, but this seems to diverge further.

I don't find any branches with version in DEP-14. So this is not even applicable here.

Do you see any advantages to this beyond avoiding conflicts?

It removed useless work.

Bastian

--
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

I have one small last minute modification: don't use main, but release.
Overall I did not see any voices against the concept itself. Nor did I
see any counter proposals to the layout.

This means:
- The current sid branch will end with 6.6 and be cleaned up later
- No more merges will be done up the chain
- I will branch to debian/release/6.7 after !1011 is in
- I will annonce 6.7 upload to unstable pretty soon

On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote:

master: uploaded to experimental

-> debian/release/6.6: uploaded to unstable and stable releases

-> debian/backport/6.6.1-1: uploaded to backports
-> debian/security/6.6.1+1: extra security releases

Bastian

--
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, "Patterns of Force", stardate 2534.7

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ben

On Mon, Jan 29, 2024 at 03:37:37PM +0100, Ben Hutchings wrote:

On Sun, 2024-01-28 at 21:37 +0100, Bastian Blank wrote:

I have one small last minute modification: don't use main, but release. Overall I did not see any voices against the concept itself. Nor did I
see any counter proposals to the layout.

I oppose this change and I propose to switch to DEP-14 branches
instead.

Okay. Please provide a real description. DEP-14 does not specify
workflow, only layout. And git does not like non fast-forward branches
at all, so how do you intend to fix that?

As this comes only after five weeks, please don't do that again.

Bastian

--
It would be illogical to kill without reason.
-- Spock, "Journey to Babel", stardate 3842.4

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Bastian,

On Thu, 2024-06-13 at 20:48 +0200, Bastian Blank wrote:

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.

And then we had another discussion in last week's meeting, and I think
we finally reached some rough agreement on this. I'm going to try to
set out how I understand this would work.

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:

I agree that we should stop doing this. We'll need to close bugs on
both branches in some cases.

[...]

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.

For testing/unstable and for stable-backports suites I agree we
shouldn't do this any more. The -backports changes will need to
rebased when switching from e.g. 6.10.x to 6.11.x.

Having said that, a rebase isn't much more reviewable than a merge, so
I would prefer not to rebase -backports for upstream stable updates.
While merges for such updates are not automatic, the conflicts are in
practice trivial.

For stable and stable-security I think we could continue using
codenames as we don't expect to move to a new upstream stable branch
(at least, not often).


[...]

## Proposal

Stop merging back changes, but create version distinct branches.
Something like that:

master: uploaded to experimental

Call this debian/latest so we follow DEP-14 as far as possible.

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)

As I pointed out in the meeting, backports do sometimes need extra
patches or kconfig changes so we can't treat them as automatic, even
with the proposed changes to add suite-dependent config.

And as stated above, I don't want to rebase -backports for every stable
update.

-> debian/security/6.6.1+1: extra security releases

I would prefer to use suite names in these branch names, to make
itclearer what the branches correspond to. So those would be:

- debian/6.6/unstable
- debian/6.6/bookworm-backports
- debian/6.6.1+1/booxie-security [*]

(swapping the release and suite so that they don't actually conflict
with DEP-14 branch names).

Ben.

* booxie is the little-known Debian release between bookworm and trixie
that included Linux 6.6. :-)

--
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmbq6VUACgkQ57/I7JWG EQn4yQ//VobTkiJmwsfQTWYRq7cbwbaIAOjf2Fr8JLeigUwX9Fk1DsNYk1PQBBLh pAOhTThevhF+QKcogd0Ew5Oqnsw0KWBy4l14wp3QUQVBuu6Cr+4xstbiORreoR9y 4ekkraEEeQ92mMYwh1IxyGca4ryQJhDPdVzDLaGoZjtge5Yrph4VTzLNpUYYU6Hn O4DQKYa+n874rttj4pVUJdPc1zvzIdelKu9WNdgJ5PN1Ahg+/YLL7iKo0t0Ad2Q0 7WFwwIwvFilM8uQ+l/xOmrN4bSYzizO/jnyXBZnMifbaTpqukwmANXgK4N72PmsX gAbQNpq8KwLphKu17D83j07dGvm+3Ei4XfhCyttlwcOZYeeQz27CDOQnHV6YyczA 04VJ2DO2+po6uOyWueEn/jrimFLuw6kJpakW/W/xPd3F2WX/u0ji3y+D3WOpbpoK 8xh1RSIklJGxd3bk4dveUUZeU2FFXNYvFMCxjRiJq6gn5qH676h/52rIAxk5tE1O pRf/RJq61zpvJBlOEqYRvUr0ARotSfgTHlyT+RXAuGcZs2H+7ZrlYYZUg3M5uFe5 9Y3khcH8QFH1FDF19bowmV/ZhENMfPFvfMcO89l0uM0Ct7IK5HQycxHmpMNxlRWf UlNx+lmR48UO4KWtT72ez1ru+VPNsW4ZsjBQtwoPUrQR6m3xtO4=
=i8Ee
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

On Wed, Sep 18, 2024 at 04:53:09PM +0200, Ben Hutchings wrote:

On Thu, 2024-06-13 at 20:48 +0200, Bastian Blank wrote:

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.

For testing/unstable and for stable-backports suites I agree we
shouldn't do this any more. The -backports changes will need to
rebased when switching from e.g. 6.10.x to 6.11.x.

Okay. We can then still work on reducing the differences and maybe at
same time we only have a single changelog entry left. But this is for
another day.

Having said that, a rebase isn't much more reviewable than a merge, so
I would prefer not to rebase -backports for upstream stable updates.
While merges for such updates are not automatic, the conflicts are in practice trivial.

Those are forward merges, not in both directions and not including huge
version ranges. So that should be way easier manageable.

## Proposal

Stop merging back changes, but create version distinct branches. Something like that:

master: uploaded to experimental

Call this debian/latest so we follow DEP-14 as far as possible.

I'm a bit reluctant on the latest, but well. The rest of the world
agreed on main.

debian/release/6.6: uploaded to unstable and stable releases

-> debian/security/6.6.1+1: extra security releases

I would prefer to use suite names in these branch names, to make
itclearer what the branches correspond to. So those would be:
- debian/6.6/unstable

How do you think the transition to stable will happen? Just leave it
this way?

I would prefer to directly use the release name, aka
"debian/6.6/trixie", because this is what the package is destined for.
That it is uploaded to unstable (or to (testing-)proposed-updates) is
part of the technical implementation, but it does not change our policy
for it (same version range etc, or did I miss some differences?).

- debian/6.6/bookworm-backports
- debian/6.6.1+1/booxie-security [*]
(swapping the release and suite so that they don't actually conflict
with DEP-14 branch names).

Okay.

We can then also use "debian/6.6/experimental" or "debian/6.6/latest",
if necessary.

Bastian

--
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
stardate 3468.1.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2024-09-20 at 18:53 +0200, Bastian Blank wrote:

Hi

On Wed, Sep 18, 2024 at 04:53:09PM +0200, Ben Hutchings wrote:

On Thu, 2024-06-13 at 20:48 +0200, Bastian Blank wrote:

[...]

## Proposal

Stop merging back changes, but create version distinct branches. Something like that:

master: uploaded to experimental

Call this debian/latest so we follow DEP-14 as far as possible.

I'm a bit reluctant on the latest, but well. The rest of the world
agreed on main.

I know, but this is the Debian way.

debian/release/6.6: uploaded to unstable and stable releases

-> debian/security/6.6.1+1: extra security releases

I would prefer to use suite names in these branch names, to make
itclearer what the branches correspond to. So those would be:
- debian/6.6/unstable

How do you think the transition to stable will happen? Just leave it
this way?

I would prefer to directly use the release name, aka
"debian/6.6/trixie", because this is what the package is destined for.

I think that's also OK.

That it is uploaded to unstable (or to (testing-)proposed-updates) is
part of the technical implementation, but it does not change our policy
for it (same version range etc, or did I miss some differences?).

- debian/6.6/bookworm-backports
- debian/6.6.1+1/booxie-security [*]
(swapping the release and suite so that they don't actually conflict
with DEP-14 branch names).

Okay.

We can then also use "debian/6.6/experimental" or "debian/6.6/latest",
if necessary.

When would we need those? Are you thinking about how we would switch
upstream version in experimental during a freeze?

Ben.

--
Ben Hutchings
Man invented language to satisfy his deep need to complain.
- Lily Tomlin


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmbt2pAACgkQ57/I7JWG EQkVDQ/9HlAKGYGmDzkgbVfb9hX/jEBgZ+IHwox6i7mZDCmQ2SlVPCDHhraystX3 7u1adhgTH6xawOT0DuZzYNljMNUq98LjsZQE2mAf+U8jLXjpz67LG+OlQQEw+QSn UjOBLqPjB8rg8mlOvjoW01zlfvNbi2tHOJ31ETKRpVPzp0KVDjuahhwER9PtS0N4 OkiZBip5PJG/j/m4icmtmjUMWsrr0yfR8/VbB0DXmA2p++bAD7NmTpBAWxS80tev qP18Nnx7ty1XdPZXWM6xxzoXV9ONVKgtS28LsDuEZAAD+oX40LN+5lgxN1GldshB jZL69hw7yqGQmQIdz/L9hI6k1yxwsYBiVL80S1kHRDDE+ABidZ+5enH1xVjUtph+ 1cNbaUZ1dddY8J8rqq4E4XwMDtDuc/vE3Gw0B/5e2miI5mXH68jbfoHBryh1bAIo daj/9C9hui3jTT69ZBDTou2SIv7vg/Ah1yB4XrKz0PrCpoQRwNELRXVRKEcSXJZL oGhtASwMSkYvVY52ZeBOh/EKOxSgAHm0/j9+Vfv8c8lYT21/A4piWQoA8YwfNHF7 63ymdfZF38GqFE4HhrZV7NerqWZrv5Bnv3H6F9lsqRR+egkatHt3vL0B09CG3daf E89khgcQI3UWE3KlTRwc6iR+tPM/iIzpIY9TKKYP2CTnHmD2FiY=
=0l5C
-----END PGP SIGNATURE-----

--- SoupGate-Wi