Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Jonathan Dowland]

Hi,

Whilst I really welcome progress on this DEP, as I believe it's really
important to codify best practice, and that's what you're trying to do
:-),

On Sat, Aug 29, 2020 at 01:01:09AM +0200, Raphael Hertzog wrote:
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
> 
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.

These two paragraphs seem to contradict each other.

I would not object to the DEP moving to ACCEPTED if it was the case that
it was effectively in-use, and no changes were necessary; but you are
*are* changing the DEP, specifically, replacing debian/master with
debian/latest.

Clearly there's some debate as to whether debian/latest is appropriate.
I don't think it's reasonable to consider that matter settled.

So I would argue you should honour the DEP procedure and at most move it
to CANDIDATE, but probably better stick with DRAFT — perhaps commit the
debian/latest change and leave it in DRAFT status whilst we debate that
point (since I believe there is consensus to move away from master, at
least, so land that change now)


Best wishes,

-- 
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Andreas Metzler]

On 2020-08-29 Raphael Hertzog  wrote:
> +URL: https://dep-team.pages.debian.net/deps/dep14/
[...]

| When a package targets any release that is not one of the usual
| development releases (i.e. stable releases or a frozen development
| release), it should be prepared in a branch named with the codename of
| the target distribution. In the case of Debian, that means for example
| debian/jessie, debian/wheezy, debian/wheezy-backports, etc. We
| specifically avoid "suite" names because those tend to evolve over
| time ("stable" becomes "oldstable" and so on).

Hello

I had been doing this (well, without the debian/ prefix).  Naturally I
rarely touched theses stable or oldstable branches and whenever I did
I ended up googling the release number [1] for the release name since I
needed it for the Debian version number of the upload.  This was not a
welcome distraction when handling security issues. I have now switched
to using 09_stretch, 10_buster, etc. which was a huge improvement.

cu Andreas


[1] I know that the info is available in file /some/where/release in a
package called something lsb-release-info, but resolving this link
takes even longer than google/wikipedia.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Geert Stappers]

On Sun, Sep 13, 2020 at 10:32:36AM -0700, Sean Whitton wrote:
> Hello,
> 
> > On Sat, 12 Sep 2020, Sean Whitton wrote:
> >> There are arguments both ways here but as you're the person driving
> >> this, I'm still keen to hear more from you about why debian/unstable is
> >> to be preferred over debian/sid giving the existing convention
> >> established by dgit.  Thanks.
> >
> > I don't have figures about their respective usage and I have no time to
> > look into collecting such statictics. However I have been convinced by
> > Simon Mc Vittie's request to document some sort of preference.
> >
> > debian/unstable better matches what we put in the changelog: we
> > put unstable for upload to the development release (and we put a codename
> > for stable uploads).

In https://lists.debian.org/msgid-search/871rjnu3r9@hope.eyrie.org
is that also said by Russ Allbery.


> > debian/unstable is more expressive than debian/sid for persons who
> > are not very familiar with the debian release naming scheme.
> 
> Okay, thanks.

Yes, we are closer to consensus.  Other warm feeling I have is that this
discussion learnt me that DEP-14 was originally written with Upstream
in mind.


Regards
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Sean Whitton]

Hello,

> On Sat, 12 Sep 2020, Sean Whitton wrote:
>> There are arguments both ways here but as you're the person driving
>> this, I'm still keen to hear more from you about why debian/unstable is
>> to be preferred over debian/sid giving the existing convention
>> established by dgit.  Thanks.
>
> I don't have figures about their respective usage and I have no time to
> look into collecting such statictics. However I have been convinced by
> Simon Mc Vittie's request to document some sort of preference.
>
> debian/unstable better matches what we put in the changelog: we
> put unstable for upload to the development release (and we put a codename
> for stable uploads).
>
> debian/unstable is more expressive than debian/sid for persons who
> are not very familiar with the debian release naming scheme.

Okay, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

Hi,

On Sat, 12 Sep 2020, Sean Whitton wrote:
> There are arguments both ways here but as you're the person driving
> this, I'm still keen to hear more from you about why debian/unstable is
> to be preferred over debian/sid giving the existing convention
> established by dgit.  Thanks.

I don't have figures about their respective usage and I have no time to
look into collecting such statictics. However I have been convinced by
Simon Mc Vittie's request to document some sort of preference.

debian/unstable better matches what we put in the changelog: we
put unstable for upload to the development release (and we put a codename
for stable uploads).

debian/unstable is more expressive than debian/sid for persons who
are not very familiar with the debian release naming scheme.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Sean Whitton]

Hello Raphael,

On Sat 05 Sep 2020 at 04:31PM -07, Sean Whitton wrote:

> Hello Raphael,
>
> On Sun 30 Aug 2020 at 10:02AM -07, Sean Whitton wrote:
>
>> I think we should recommend debian/sid because for some years dgit has
>> been generating branches called dgit/sid.  I think it would smooth the
>> integration between branches on salsa and branches on dgit.debian.org
>> if both always used codenames.
>
> Haven't heard back from you on this -- do you happen to know whether
> debian/sid or debian/unstable is in greater use on salsa right now?  I
> would agree on standardising on d/unstable if it is already in
> significantly wider use.

There are arguments both ways here but as you're the person driving
this, I'm still keen to hear more from you about why debian/unstable is
to be preferred over debian/sid giving the existing convention
established by dgit.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Richard Laager wrote on 06/09/2020:

On 8/31/20 8:53 AM, Raphael Hertzog wrote:

I already agreed that we can tweak the wording to document that it's


I don't think the people on the list saw that message, as it had an
attachment. It's below (unabridged).


OK to use debian/unstable as default branch even if you are not a
complex package that require multiple branches, provided that you will
not use debian/unstable when you decide to push something to
experimental.


I do not see why we have to prohibit occasional uploads to experimental
from debian/unstable. If this is permitted, then that also avoids the
busywork of creating debian/experimental in that scenario.

On 8/30/20 4:27 PM, Raphael Hertzog wrote:

Hello,

On Sun, 30 Aug 2020, Richard Laager wrote:

You could use debian/experimental all the time and then merge down to
debian/unstable only when you're ready to upload and have chosen
unstable. But I suspect your objection would be: that's unnecessary
busywork. And I see that point. I would probably make the same
objection, which means I think I agree with the debian/latest concept in
your situation.


You perfectly understood my reasoning. Thank you for making that effort.


I'm not sure if most package maintainers are doing this or not. I've
always assumed that most people are targetting only unstable most of the
time and that use of experimental is relatively rare. I could easily be
wrong on that.


I don't think that you are wrong. Most packages definitely only target
unstable and never use experimental.


Then why give up the simplicity of only one choice and the clarity (and
tooling advantages) of debian/unstable as the typical case, in favor of
debian/latest?


But most packages also never need to maintain two development branches
in parallel. Only very big packages, linux or django for example, will
maintain different upstream versions in two parralel branches.

Another thing that's quite certain is that you never know what the future
will bring you. And while you never had to use experimental, you might
have to at some point.

In that sense, I find debian/latest more future-proof but I also
agree that for the few cases where we would have to use experimental,
it's not a big deal to have to create debian/experimental.

Another thing to take into account is that DEP-14 has been drafted
as a vendor-neutral recommendation. I use it in the context of Kali
and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
only has codenames even for their development release.


What's wrong with kali/kali-dev?

I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would
be better there. From my point of view (as someone who occasionally SRUs
something in Ubuntu), having ubuntu/ is the right choice. When
a new development release opens up, you would branch e.g. ubuntu/focal
into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs
(stable release updates). To me, my proposed branching model feels like
it matches the Ubuntu development model 1:1.


Thus /latest is a better default for tools like git-buildpackage
and it makes sense for DEP-14 to endorse such a default branch as the
recommended name.


That is, I'm generally always targetting unstable and _not_ regularly
using multiple releases, so the DEP-14 language "prohibits" me from
using debian/unstable. This is what feels backwards to me. If I'm always
targetting unstable, debian/latest (and previously debian/master) is
less clear than debian/unstable.

At a minimum, can we rework this in some way so the language does not
require me to be regularly using multiple releases to use
debian/unstable as a branch name?


That seems entirely reasonable, yes. Can you try to make a proposal ?

I attach the current markdown file with my not-yet pushed change that I
submitted for review here.

Cheers,

DEP-14 starts this section with a broad, "In general, packaging branches
should be named according to the codename of the target distribution."
On that, I think we all agree. Then it continues, "We differentiate
however the case of development releases from other releases."
Fundamentally, the scope of that exception is what we are discussing.

Diffs available here (since this list refuses attachments and I can't
figure out how to disable line wrapping in Thunderbird):
https://paste.debian.net/1162793/

Proposal "A":

My original position was that we limit that exception to using
"unstable" and "experimental" instead of "sid" and what (I later
learned) may or may not be "rc-buggy". This has the advantages that
there is only one recommended default (instead of two or three) and the
branch name (sans vendor) _always_ matches the changelog.

Proposal "B":

Raphael Hertzog, Russ Allbery, et al. upload to unstable or experimental
depending on various factors, which notably may not be known a priori.
In this case, it would be annoying busywork to have to switch from
debian/unstable to debian/experimental when the decision is made to

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 9/7/20 5:33 AM, Raphael Hertzog wrote:
> On Sat, 05 Sep 2020, Richard Laager wrote:
>> I do not see why we have to prohibit occasional uploads to experimental
>> from debian/unstable. If this is permitted, then that also avoids the
>> busywork of creating debian/experimental in that scenario.
> 
> To me it feels awkward to allow this. You can't really get it both ways
> IMO. If you decide to use codename-based branches, then you should use
> debian/experimental for an experimental upload.

That view is: A > B.

FWIW, my justification for B > CD is:

Since the parallel branch scenario is already debian/unstable &
debian/experimental, then I'll take a small inconsistency for the
occasional upload to experimental to be able to use a strict subset of
those choices (debian/unstable) as the normal scenario, rather than a
whole new thing (debian/{master,latest}).

> The "clarity" of debian/unstable is limited to Debian developers, upstream
> developers might not know that unstable is the development branch. Random
> outsiders neither.

Whatever it is called, the main development branch will normally be the
HEAD, so an unqualified `git clone` will give that branch. (Exceptions
include when the repository is mixed upstream and packaging.) That
probably covers the upstreams and random outsiders.

> But what I meant is that "unstable" is only applicable to Debian and
> that derivatives have different models and that we should not impose
> too much to make sure we cater to the needs of derivatives too.

I think you were following, but to be clear, the proposal isn't
/unstable, it's /. So
debian/unstable, ubuntu/groovy (changes as time moves on),
kali/kali-dev, etc.

I do acknowledge that /latest is undoubtedly easier for the
tooling to implement, and that is a serious advantage of C.

> Without having read your precise diff, I would believe my personal view
> would be: C > D > B > A
That is what I expected your view to be. You might be A > B rather than
B > A, though, as discussed above.

Anyway, I think I'm into dead horse territory here. Unless someone else
speaks up, I assume the next step is for you to pick an option, which I
assume will be C (in principle; not necessarily my wording).

Thanks for taking the time to hear me out and thanks for DEP-14!

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Sat, 05 Sep 2020, Richard Laager wrote:
> > OK to use debian/unstable as default branch even if you are not a
> > complex package that require multiple branches, provided that you will
> > not use debian/unstable when you decide to push something to
> > experimental.
> 
> I do not see why we have to prohibit occasional uploads to experimental
> from debian/unstable. If this is permitted, then that also avoids the
> busywork of creating debian/experimental in that scenario.

To me it feels awkward to allow this. You can't really get it both ways
IMO. If you decide to use codename-based branches, then you should use
debian/experimental for an experimental upload.

What do other people think?

> > I don't think that you are wrong. Most packages definitely only target
> > unstable and never use experimental. 
> 
> Then why give up the simplicity of only one choice and the clarity (and
> tooling advantages) of debian/unstable as the typical case, in favor of
> debian/latest?

It's not clear to me that debian/latest has major disadvantages over
debian/unstable. It's a single choice too.

The "clarity" of debian/unstable is limited to Debian developers, upstream
developers might not know that unstable is the development branch. Random
outsiders neither.

And using codename by default for the development branch means that you
don't have uniformitiy across multiple vendors, which I find desirable
for the purpose of letting git packaging helper tools having a sane
cross-vendor default.

> > Another thing to take into account is that DEP-14 has been drafted
> > as a vendor-neutral recommendation. I use it in the context of Kali
> > and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
> > only has codenames even for their development release.
> 
> What's wrong with kali/kali-dev?

We have kali twice in the name. We used to have "kali/stable" and
"kali/dev" at some point and we switched to "kali/master" when we
switched to a rolling-release model to standardize on DEP-14.

But what I meant is that "unstable" is only applicable to Debian and
that derivatives have different models and that we should not impose
too much to make sure we cater to the needs of derivatives too.

> I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would
> be better there. From my point of view (as someone who occasionally SRUs
> something in Ubuntu), having ubuntu/ is the right choice. When
> a new development release opens up, you would branch e.g. ubuntu/focal
> into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs
> (stable release updates). To me, my proposed branching model feels like
> it matches the Ubuntu development model 1:1.

Sure, if you put yourself in the feet of someone doing stable release
uploads, it's convenient to have a branch ready to use. But if you put
yourself in the shoes of someone doing Debian syncs, then maybe
ubuntu/latest would save you some hurdle.

In any case, Ubuntu has no "suite" name and it's to be expected that they
would use only "codename" even for their development releases. That
doesn't mean that it's the right choice for everybody nor that it should
be the default.

> DEP-14 starts this section with a broad, "In general, packaging branches
> should be named according to the codename of the target distribution."
> On that, I think we all agree. Then it continues, "We differentiate
> however the case of development releases from other releases."
> Fundamentally, the scope of that exception is what we are discussing.

Yes. (Though I would have hoped that it would not require so much
discussion at this point :-))

> Diffs available here (since this list refuses attachments and I can't
> figure out how to disable line wrapping in Thunderbird):
> https://paste.debian.net/1162793/

Bah 503 service unavailable right now.

> My personal view is now: B > A > D > C

Without having read your precise diff, I would believe my personal view
would be: C > D > B > A

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Fri, 04 Sep 2020, The Wanderer wrote:
> As long as this is being patched anyway, how about fixing the "others
> vendors" duplicate pluralization? I'd suggest either "but all other
> vendors should do so" or "as all others should do", but other variations
> are possible and I don't have a strong preference.

Fixed locally.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

(Resending without the attachment for posterity sinte the message didn't
make it to -devel, but I also had no bounce notifying me that it was
discarded...)

Hello,

On Sun, 30 Aug 2020, Richard Laager wrote:
> You could use debian/experimental all the time and then merge down to
> debian/unstable only when you're ready to upload and have chosen
> unstable. But I suspect your objection would be: that's unnecessary
> busywork. And I see that point. I would probably make the same
> objection, which means I think I agree with the debian/latest concept in
> your situation.

You perfectly understood my reasoning. Thank you for making that effort.

> I'm not sure if most package maintainers are doing this or not. I've
> always assumed that most people are targetting only unstable most of the
> time and that use of experimental is relatively rare. I could easily be
> wrong on that.

I don't think that you are wrong. Most packages definitely only target
unstable and never use experimental. 

But most packages also never need to maintain two development branches
in parallel. Only very big packages, linux or django for example, will
maintain different upstream versions in two parralel branches.

Another thing that's quite certain is that you never know what the future
will bring you. And while you never had to use experimental, you might
have to at some point.

In that sense, I find debian/latest more future-proof but I also
agree that for the few cases where we would have to use experimental,
it's not a big deal to have to create debian/experimental.

Another thing to take into account is that DEP-14 has been drafted
as a vendor-neutral recommendation. I use it in the context of Kali
and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
only has codenames even for their development release.

Thus /latest is a better default for tools like git-buildpackage
and it makes sense for DEP-14 to endorse such a default branch as the
recommended name.

> That is, I'm generally always targetting unstable and _not_ regularly
> using multiple releases, so the DEP-14 language "prohibits" me from
> using debian/unstable. This is what feels backwards to me. If I'm always
> targetting unstable, debian/latest (and previously debian/master) is
> less clear than debian/unstable.
> 
> At a minimum, can we rework this in some way so the language does not
> require me to be regularly using multiple releases to use
> debian/unstable as a branch name?

That seems entirely reasonable, yes. Can you try to make a proposal ?

I attach the current markdown file with my not-yet pushed change that I
submitted for review here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Sean Whitton]

Hello Raphael,

On Sun 30 Aug 2020 at 10:02AM -07, Sean Whitton wrote:

> I think we should recommend debian/sid because for some years dgit has
> been generating branches called dgit/sid.  I think it would smooth the
> integration between branches on salsa and branches on dgit.debian.org
> if both always used codenames.

Haven't heard back from you on this -- do you happen to know whether
debian/sid or debian/unstable is in greater use on salsa right now?  I
would agree on standardising on d/unstable if it is already in
significantly wider use.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 8/31/20 8:53 AM, Raphael Hertzog wrote:
> I already agreed that we can tweak the wording to document that it's

I don't think the people on the list saw that message, as it had an
attachment. It's below (unabridged).

> OK to use debian/unstable as default branch even if you are not a
> complex package that require multiple branches, provided that you will
> not use debian/unstable when you decide to push something to
> experimental.

I do not see why we have to prohibit occasional uploads to experimental
from debian/unstable. If this is permitted, then that also avoids the
busywork of creating debian/experimental in that scenario.

On 8/30/20 4:27 PM, Raphael Hertzog wrote:
> Hello,
> 
> On Sun, 30 Aug 2020, Richard Laager wrote:
>> You could use debian/experimental all the time and then merge down to
>> debian/unstable only when you're ready to upload and have chosen
>> unstable. But I suspect your objection would be: that's unnecessary
>> busywork. And I see that point. I would probably make the same
>> objection, which means I think I agree with the debian/latest concept in
>> your situation.
> 
> You perfectly understood my reasoning. Thank you for making that effort.
> 
>> I'm not sure if most package maintainers are doing this or not. I've
>> always assumed that most people are targetting only unstable most of the
>> time and that use of experimental is relatively rare. I could easily be
>> wrong on that.
> 
> I don't think that you are wrong. Most packages definitely only target
> unstable and never use experimental. 

Then why give up the simplicity of only one choice and the clarity (and
tooling advantages) of debian/unstable as the typical case, in favor of
debian/latest?

> But most packages also never need to maintain two development branches
> in parallel. Only very big packages, linux or django for example, will
> maintain different upstream versions in two parralel branches.
> 
> Another thing that's quite certain is that you never know what the future
> will bring you. And while you never had to use experimental, you might
> have to at some point.
> 
> In that sense, I find debian/latest more future-proof but I also
> agree that for the few cases where we would have to use experimental,
> it's not a big deal to have to create debian/experimental.
> 
> Another thing to take into account is that DEP-14 has been drafted
> as a vendor-neutral recommendation. I use it in the context of Kali
> and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
> only has codenames even for their development release.

What's wrong with kali/kali-dev?

I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would
be better there. From my point of view (as someone who occasionally SRUs
something in Ubuntu), having ubuntu/ is the right choice. When
a new development release opens up, you would branch e.g. ubuntu/focal
into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs
(stable release updates). To me, my proposed branching model feels like
it matches the Ubuntu development model 1:1.

> Thus /latest is a better default for tools like git-buildpackage
> and it makes sense for DEP-14 to endorse such a default branch as the
> recommended name.
> 
>> That is, I'm generally always targetting unstable and _not_ regularly
>> using multiple releases, so the DEP-14 language "prohibits" me from
>> using debian/unstable. This is what feels backwards to me. If I'm always
>> targetting unstable, debian/latest (and previously debian/master) is
>> less clear than debian/unstable.
>>
>> At a minimum, can we rework this in some way so the language does not
>> require me to be regularly using multiple releases to use
>> debian/unstable as a branch name?
> 
> That seems entirely reasonable, yes. Can you try to make a proposal ?
> 
> I attach the current markdown file with my not-yet pushed change that I
> submitted for review here.
> 
> Cheers,
DEP-14 starts this section with a broad, "In general, packaging branches
should be named according to the codename of the target distribution."
On that, I think we all agree. Then it continues, "We differentiate
however the case of development releases from other releases."
Fundamentally, the scope of that exception is what we are discussing.

Diffs available here (since this list refuses attachments and I can't
figure out how to disable line wrapping in Thunderbird):
https://paste.debian.net/1162793/

Proposal "A":

My original position was that we limit that exception to using
"unstable" and "experimental" instead of "sid" and what (I later
learned) may or may not be "rc-buggy". This has the advantages that
there is only one recommended default (instead of two or three) and the
branch name (sans vendor) _always_ matches the changelog.

Proposal "B":

Raphael Hertzog, Russ Allbery, et al. upload to unstable or experimental
depending on various factors, which notably may not be known a priori.
In this case, it would be annoying busywork to have to 

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[The Wanderer]

On 2020-09-04 at 11:42, Raphael Hertzog wrote:

> So here's my counter proposal:
> 
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> @@ -201,12 +201,16 @@ Native packages
>  
>  The above conventions mainly cater to the case where the upstream
>  developers and the package maintainers are not the same set of persons.
> -
> -When upstream is Debian (or one of its derivative), the upstream vendor
> -should not use the usual `/` prefix (but all others vendors should
> -do so). The main development branch does not have to be named after
> -the codename of the target distribution (although you are free to still
> -use the codename if you wish so).
> +By contrast, this section applies to native packages where upstream is
> +Debian (or one of its derivatives) and where the packaging and upstream
> +source code are managed in the same branch(es).
> +
> +In that specific situation, the upstream vendor should not use the usual
> +`/` prefix for their branches and tags (but all others vendors
> +should do so)

As long as this is being patched anyway, how about fixing the "others
vendors" duplicate pluralization? I'd suggest either "but all other
vendors should do so" or "as all others should do", but other variations
are possible and I don't have a strong preference.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Raphael Hertzog wrote on 04/09/2020:

Hi,

On Fri, 04 Sep 2020, Paride Legovini wrote:

As the name of the development branch is not specified anymore, should dep14
ask for it to be the repository default branch? Otherwise there's no safe


I took this as granted. But maybe we should make it explicit, yes. I also
clarified that those recommandations are really for the cases where you
mix upstream development and Debian packaging in the same branch. I can
imagine someone picking 3.0 (native) packaging but keeping a separate
"main" branch with only upstream code and hosting packaging in
debian/latest...

So here's my counter proposal:

--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -201,12 +201,16 @@ Native packages
  
  The above conventions mainly cater to the case where the upstream

  developers and the package maintainers are not the same set of persons.
-
-When upstream is Debian (or one of its derivative), the upstream vendor
-should not use the usual `/` prefix (but all others vendors should
-do so). The main development branch does not have to be named after
-the codename of the target distribution (although you are free to still
-use the codename if you wish so).
+By contrast, this section applies to native packages where upstream is
+Debian (or one of its derivatives) and where the packaging and upstream
+source code are managed in the same branch(es).
+
+In that specific situation, the upstream vendor should not use the usual
+`/` prefix for their branches and tags (but all others vendors
+should do so) and they also don't have to follow the usual naming
+conventions for packaging branches (although they are free to do
+so if they wish). However the default branch of the repository (as pointed
+by the HEAD reference) should be a development branch.
  
  When the package is shipped as a native source package (i.e. a single

  tarball with no differentiation of the upstream sources and of the


+1, thanks!

Paride

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

Hi,

On Fri, 04 Sep 2020, Paride Legovini wrote:
> As the name of the development branch is not specified anymore, should dep14
> ask for it to be the repository default branch? Otherwise there's no safe

I took this as granted. But maybe we should make it explicit, yes. I also
clarified that those recommandations are really for the cases where you
mix upstream development and Debian packaging in the same branch. I can
imagine someone picking 3.0 (native) packaging but keeping a separate
"main" branch with only upstream code and hosting packaging in
debian/latest...

So here's my counter proposal:

--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -201,12 +201,16 @@ Native packages
 
 The above conventions mainly cater to the case where the upstream
 developers and the package maintainers are not the same set of persons.
-
-When upstream is Debian (or one of its derivative), the upstream vendor
-should not use the usual `/` prefix (but all others vendors should
-do so). The main development branch does not have to be named after
-the codename of the target distribution (although you are free to still
-use the codename if you wish so).
+By contrast, this section applies to native packages where upstream is
+Debian (or one of its derivatives) and where the packaging and upstream
+source code are managed in the same branch(es).
+
+In that specific situation, the upstream vendor should not use the usual
+`/` prefix for their branches and tags (but all others vendors
+should do so) and they also don't have to follow the usual naming
+conventions for packaging branches (although they are free to do
+so if they wish). However the default branch of the repository (as pointed
+by the HEAD reference) should be a development branch.
 
 When the package is shipped as a native source package (i.e. a single
 tarball with no differentiation of the upstream sources and of the

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Raphael Hertzog wrote on 29/08/2020:


@@ -200,7 +204,7 @@ developers and the package maintainers are not the same set 
of persons.
  
  When upstream is Debian (or one of its derivative), the upstream vendor

  should not use the usual `/` prefix (but all others vendors should
-do so). The main development branch can be named `master` instead of
+do so). The main development branch does not have to be named after
  the codename of the target distribution (although you are free to still
  use the codename if you wish so).


As the name of the development branch is not specified anymore, should 
dep14 ask for it to be the repository default branch? Otherwise there's 
no safe way to tell what the devel branch is for native packages.


Proposal:

---
The main development branch does not have to follow the naming 
conventions of non-native packages (although you are free to still do if 
you wish so), but it has to be the repository default branch.

---

I refer to the "naming conventions" instead of "codename of the target 
distribution" because "latest" in /latest is not a target 
distribution but an arbitrary name.


Paride

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Raphael Hertzog wrote on 31/08/2020:
> Hi,
> 
> On Mon, 31 Aug 2020, Paride Legovini wrote:
>> A tl;dr version of my idea is: let's remove the special treatment for
>> development releases, treating e.g. debian/unstable like a stable
>> release. Optionally use a 'debian/devel' branch for development work.
>> The only "workflow" bit is: if you work on debian/devel, merge your
>> changes to debian/unstable before uploading.
> 
> I understand this but you are imposing usage of multiple branches to some
> persons who are happy to have a single branch alternating between unstable
> and experimental. I don't want to go that extra mile. In particular
> because this requirement has other drawbacks that you didn't list:
> 
> You hardcode the name of the Debian development release while I would
> like DEP-14 to result in changes to packaging tools that can be useful
> across multiple distribution vendors. And while tools can easily query
> `dpkg-vendor --query vendor` there's currently no simple way
> for a tool to learn the codename of the development release.

I do not fully agree:

- if you go back to my proposal I exclude experimental from the "branch
name should match upload codename" requirement

- the devel branch name is not hardcoded: vendor foo with devel release
bar would have development for it done in the foo/bar branch

*however* after some more thinking I came to the conclusion that a
long-lived development branch with a cross-vendor predictable name makes
sense.

I second your proposal, with preference for /devel over
/latest.

>>> We want to document what we can expect when you have debian/latest
>>> and what you can expect when you have debian/unstable.
>>
>> On this point: should there be a way for a package to declare its
>> packaging repository follows dep14?
> 
> What would we gain from this?

Predictability: if a package is declared dep14 compliant then I'll know
immediately what to expect in its packaging repo and how its branches
are used. The repository can be "linted" for actual dep14 compliance.
But the branch structure itself and the name of the default branch are
probably enough to infer that dep14 is being followed.

>> And you are right, however I think the current wording may be partially
>> missing the opportunity to set stronger expectation of what is to be
>> found in a Debian packaging repository in terms of branches, which is
>> what my comment is about.
> 
> I'm trying to bring this DEP to some conclusion and I'm not going to
> extend its scope.

Thanks for this.

Paride

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

Hi,

On Mon, 31 Aug 2020, Paride Legovini wrote:
> A tl;dr version of my idea is: let's remove the special treatment for
> development releases, treating e.g. debian/unstable like a stable
> release. Optionally use a 'debian/devel' branch for development work.
> The only "workflow" bit is: if you work on debian/devel, merge your
> changes to debian/unstable before uploading.

I understand this but you are imposing usage of multiple branches to some
persons who are happy to have a single branch alternating between unstable
and experimental. I don't want to go that extra mile. In particular
because this requirement has other drawbacks that you didn't list:

You hardcode the name of the Debian development release while I would
like DEP-14 to result in changes to packaging tools that can be useful
across multiple distribution vendors. And while tools can easily query
`dpkg-vendor --query vendor` there's currently no simple way
for a tool to learn the codename of the development release.

Thus I stand on the opinion that we need to have a generic name for the
default development branch. We can accept use of alternate default
branches, for those who have strong opinions in that direction, but the
default recommendation should be some generic name.

> (Could be made more generic by recommending optional branches named:
> 
>   - //devel
> 
> for development, to be merged to
> 
>   - /
> 
> before uploading. But this is probably overkill.)

That would not work. git is not allowing you to have those two branches at
the same time. A given path can't be a branch and a directory at the same
time.

> > We want to document what we can expect when you have debian/latest
> > and what you can expect when you have debian/unstable.
> 
> On this point: should there be a way for a package to declare its
> packaging repository follows dep14?

What would we gain from this?

> And you are right, however I think the current wording may be partially
> missing the opportunity to set stronger expectation of what is to be
> found in a Debian packaging repository in terms of branches, which is
> what my comment is about.

I'm trying to bring this DEP to some conclusion and I'm not going to
extend its scope.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Raphael Hertzog wrote on 31/08/2020:
> On Mon, 31 Aug 2020, Paride Legovini wrote:
>> What I propose is to require for dep14 compliance that uploads to
>>  are to be cut from debian/ branches, unless
>>  is experimental. This allows to checkout the "maintainer
>> view" of a given (nonexperimental) version of a package by knowing only:
>>
>>  - the repository location
>>  - the relevant d/changelog entry.
> 
> You are asking for more than what DEP-14 is trying to achieve.
> 
> DEP-14 does not mandate any specific workflow, it mainly tries to
> stantardize the branch names for the various cases that we have.
> 
> We're not trying to impose one workflow or the other.

I agree, what I propose trespasses on the "workflows" territory. However
DEP-14 already does it a bit I think, and I don't think that what I
propose is too far away from it. Current DEP14 says:

---
In general, packaging branches should be named according to the codename
of the target distribution. We differentiate however the case of
development releases from other releases.
---

A tl;dr version of my idea is: let's remove the special treatment for
development releases, treating e.g. debian/unstable like a stable
release. Optionally use a 'debian/devel' branch for development work.
The only "workflow" bit is: if you work on debian/devel, merge your
changes to debian/unstable before uploading.

(Could be made more generic by recommending optional branches named:

  - //devel

for development, to be merged to

  - /

before uploading. But this is probably overkill.)

> We want to document what we can expect when you have debian/latest
> and what you can expect when you have debian/unstable.

On this point: should there be a way for a package to declare its
packaging repository follows dep14?

>> This automatically allows:
> 
> I don't think that anything in the current wording is forbidding
> anything that you list.

And you are right, however I think the current wording may be partially
missing the opportunity to set stronger expectation of what is to be
found in a Debian packaging repository in terms of branches, which is
what my comment is about.

Cheers!

Paride

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Mon, 31 Aug 2020, Paride Legovini wrote:
> What I propose is to require for dep14 compliance that uploads to
>  are to be cut from debian/ branches, unless
>  is experimental. This allows to checkout the "maintainer
> view" of a given (nonexperimental) version of a package by knowing only:
> 
>  - the repository location
>  - the relevant d/changelog entry.

You are asking for more than what DEP-14 is trying to achieve.

DEP-14 does not mandate any specific workflow, it mainly tries to
stantardize the branch names for the various cases that we have.

We're not trying to impose one workflow or the other. So it's not
debian/unstable vs debian/latest. We want to document what we can
expect when you have debian/latest and what you can expect when
you have debian/unstable.

> This automatically allows:

I don't think that anything in the current wording is forbidding
anything that you list.

I already agreed that we can tweak the wording to document that it's
OK to use debian/unstable as default branch even if you are not a complex
package that require multiple branches, provided that you will not
use debian/unstable when you decide to push something to experimental.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Hi,

The Wanderer wrote on 31/08/2020:
> On 2020-08-31 at 06:49, Paride Legovini wrote:
> 
>> Simon McVittie wrote on 30/08/2020:
>>
>>> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>>>
 If I know that the next upstream release breaks backwards
 compatitibly and that it will have to mature a long time in
 experimental until all other packages are ready, I might start
 to package it rigth now in debian/experimental and continue to
 use debian/latest for my unstable uploads.
>>>
>>> If that's your workflow (the same as src:dbus, where versions
>>> 1.13.x are a development branch not recommended for general use),
>>> then I don't think debian/latest is a good name for that branch,
>>> and I'd recommend using debian/unstable for your unstable uploads.
>>>
>>> Rationale: it seems very confusing if a branch with "latest" in its
>>> name does not contain the newest available version :-)
>>
>> +1, moreover I find that "latest" does not convey the idea of
>> something that is in development: I tend to think about it in terms
>> of "latest release" or "latest version", something that is set
>> already.
>>
>> This is fine with uptream/latest, as we import the latest *released* 
>> version of the upstream source, not the current work in progress
>> tip.
> 
> I'd tend to agree with this.
> 
>> Personally I'd prefer 'debian/devel': clearly the branch where 
>> development happens.
> 
> But what about cases where what would have been the 'master' branch
> tracks what's in e.g. sid and is being temporarily left to sit, except
> for bugfixes et cetera, while actual development happens somewhere else
> (e.g., in experimental)?

In this case the current DEP14 proposal from Raphael allows to have two
permanent branches:

 - debian/unstable
 - debian/experimental

and no debian/latest. This seems to fit your case.

I proposed a slightly different approach that would allow the
debian/unstable and debian/devel branches to coexist, see the other
email I just sent.

Cheers,

Paride

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Raphael Hertzog wrote on 30/08/2020:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I have no objection to DEP-14 supporting this workflow
>> with debian/latest. But I would like to see it (debian/latest)
>> recharacterized as the alternate approach rather than the recommended
>> method.
> 
> Your approach is perfectly valid but I don't really believe that it should
> be the recommended approach. It doesn't seem to match the most common
> workflow.
> 
> Most package maintainers are not actively working on two different
> development branches, instead the single development branch keeps moving
> between:
> - ready for unstable/upload to unstable
> - work in progress on a new upstream release
> - possible upload to experimental to gather feedback (buildd, users)
> - back to ready for upload to unstable
> 
> In some rare cases, we will have to do some intermediary upload to
> unstable because some RC bug popped up and we don't want to wait until
> we're ready with the next upload. In that case, we will create a
> debian/unstable branch starting from the last tag in debian/unstable.

Hi Raphael and thanks for this thread.

I think I can see your point here, however I still don't think that
having debian/latest (or debian/devel as I'd prefer, see my other email)
beats the straightforwardness of cutting releases from a branch named
after the release the package is uploaded to (the d/changelog codename).

What I propose is to require for dep14 compliance that uploads to
 are to be cut from debian/ branches, unless
 is experimental. This allows to checkout the "maintainer
view" of a given (nonexperimental) version of a package by knowing only:

 - the repository location
 - the relevant d/changelog entry.

This automatically allows:

 - The simplest workflow where packaging is done in debian/unstable, and
that's it. Good for simple, stable packages. In this case
debian/unstable has to be the default branch or declared in Vcs-Git.

 - Uploading to experimental, right from debian/unstable or by branching
it off to debian/experimental, committing experimental stuff and
uploading from there. The debian/experimental branch is allowed to be
ephemeral (as the packages are) or force-pushed.

 - If debian/latest (~ debian/devel) is desired it can just be used.
Maintenance can continue in the debian/unstable branch e.g. to fix RC
bugs, as in your example. When a new version is ready is can be merged
to debian/unstable and uploaded. The debian/unstable branch is treated
just like a stable release branch. Good for more complex packages.

 - The maintainer must declare if debian/latest is being used by setting
it as the repo default branch, or by specifying it in Vcs-Git.

 - Same if development mainly happens in debian/experimental: make it
the default branch or declare it in Vcs-Git. In this case debian/latest
is not allowed.

 - Uploads to experimental can cut from debian/latest, but the branch is
not ephemeral.

Cons: may require extra merges from debian/latest to debian/unstable. In
exchange we gain the flexibility of debian/latest, branch name
predictability (but for experimental, by design), and good compatibility
with existing workflows.

Paride

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[SZALAY Attila]

Hi,

For me, the one branch type of development is closer to my style. I'm
that type of guy who can be easily distracted by quite anything and
therefore can easily forget things. Luckily, in most cases I have
automatic alerts and habits preventing disasters to happen, but there
are cases when it's a bit harder to maintain.

In most of the cases (99.5%) I'm working on the next release of the
package. Either by fixing bugs, following recommendations (lintian,
PTS, etc) or incorporating newer versions from upstream.

ANd after I finish with it, I upload the next version to unstable. But
in some cases, when it better to validate my hypothesis first, I upload
it to experimental. It does not happen too often (1 or 2 times
annually) and therefore if I create a new branch for it, that would
make me harder to not make mistakes (forget about the branch entirely,
deploy it to unstable by accident or just forget to merge it at the
end.)

Of course, when I have to fix something in a more "prod" environment
while I'm targeting my uploads to experimental, I still can create
ephemeral branches, correctly targeting them to the right release and
do a small fix there (hopefully by cherry-picking the fix from the
latest, so that will not be a problem if I forgot to merge it back).

Another problem of mine with creating different branches (and therefore
I like to avoid them) is the Changelog file, which makes the cross-
merges a bit more complicated than what is healthy for me.

Of course my packages are small and the chance that a newer release
breaks something fundamental is subtle, so it is low risk to target
unstable mst of the time.

On Sun, 2020-08-30 at 21:33 +0200, Mathias Behrle wrote:
> * Simon McVittie: " Re: RFC: Final update of DEP-14 on naming of git
> packaging
>   branches" (Sun, 30 Aug 2020 15:02:35 +0100):
> 
> > On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
> > > If I know that the next upstream release
> > > breaks backwards compatitibly and that it will have to mature a
> > > long time
> > > in experimental until all other packages are ready, I might start
> > > to
> > > package it rigth now in debian/experimental and continue to use
> > > debian/latest for my unstable uploads.  
> > 
> > If that's your workflow (the same as src:dbus, where versions
> > 1.13.x
> > are a development branch not recommended for general use), then I
> > don't
> > think debian/latest is a good name for that branch, and I'd
> > recommend
> > using debian/unstable for your unstable uploads.
> > 
> > Rationale: it seems very confusing if a branch with "latest" in its
> > name
> > does not contain the newest available version :-)
> 
> +1
> 
> Additionally I think explicit is usually better than implicit. When
> all other
> branches are named following their suites why should we diverge for
> this special
> case?
>  
> > (debian/master didn't have that problem because it's named by
> > analogy
> > to the "master" branch used in upstream git repositories, which
> > doesn't
> > really have a fixed meaning anyway.)
> 
> BTW the same applies for me to the (re-)naming of the 'default'
> branch
> (currently master). If it is the default branch the most plausible
> name is just
> 'default'.
> 
> 

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[The Wanderer]

On 2020-08-31 at 06:49, Paride Legovini wrote:

> Simon McVittie wrote on 30/08/2020:
> 
>> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>> 
>>> If I know that the next upstream release breaks backwards
>>> compatitibly and that it will have to mature a long time in
>>> experimental until all other packages are ready, I might start
>>> to package it rigth now in debian/experimental and continue to
>>> use debian/latest for my unstable uploads.
>> 
>> If that's your workflow (the same as src:dbus, where versions
>> 1.13.x are a development branch not recommended for general use),
>> then I don't think debian/latest is a good name for that branch,
>> and I'd recommend using debian/unstable for your unstable uploads.
>> 
>> Rationale: it seems very confusing if a branch with "latest" in its
>> name does not contain the newest available version :-)
> 
> +1, moreover I find that "latest" does not convey the idea of
> something that is in development: I tend to think about it in terms
> of "latest release" or "latest version", something that is set
> already.
> 
> This is fine with uptream/latest, as we import the latest *released* 
> version of the upstream source, not the current work in progress
> tip.

I'd tend to agree with this.

> Personally I'd prefer 'debian/devel': clearly the branch where 
> development happens.

But what about cases where what would have been the 'master' branch
tracks what's in e.g. sid and is being temporarily left to sit, except
for bugfixes et cetera, while actual development happens somewhere else
(e.g., in experimental)? Calling the replacement branch 'devel' then
still gives the impression that that is where development is happening,
but in such a case, that impression is misleading.

The primary sense of "master" as a branch name in this context, as I
understood it, was something like "the branch which everything else
should be considered to be in some sense derived from"; experience seems
to show that that sense allows for considerable versatility. IMO we
should aim to retain that meaning in whatever name is chosen to replace
'master', for minimum disruption - and for the minimum semantic
difference from that sense, IMO the closest fit I've seen yet is
'primary'.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Emmanuel Arias]

On 8/31/20 7:49 AM, Paride Legovini wrote:
> Simon McVittie wrote on 30/08/2020:
>> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>>> If I know that the next upstream release
>>> breaks backwards compatitibly and that it will have to mature a long time
>>> in experimental until all other packages are ready, I might start to
>>> package it rigth now in debian/experimental and continue to use
>>> debian/latest for my unstable uploads.
>>
>> If that's your workflow (the same as src:dbus, where versions 1.13.x
>> are a development branch not recommended for general use), then I don't
>> think debian/latest is a good name for that branch, and I'd recommend
>> using debian/unstable for your unstable uploads.
>>
>> Rationale: it seems very confusing if a branch with "latest" in its name
>> does not contain the newest available version :-)
> 
> +1, moreover I find that "latest" does not convey the idea of something
> that is in development: I tend to think about it in terms of "latest
> release" or "latest version", something that is set already.
> 
> This is fine with uptream/latest, as we import the latest *released*
> version of the upstream source, not the current work in progress tip.

I agree.

> 
> Personally I'd prefer 'debian/devel': clearly the branch where
> development happens.

Yes, me to. If use 'debian/codename' broke some package workflow, I
think that 'debian/devel' it's the name that tell me, that this is the
branch used for development.

Cheers,
Emmanuel

> 
> Paride
> 


0xFA9DEC5DE11C63F1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Paride Legovini]

Simon McVittie wrote on 30/08/2020:
> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>> If I know that the next upstream release
>> breaks backwards compatitibly and that it will have to mature a long time
>> in experimental until all other packages are ready, I might start to
>> package it rigth now in debian/experimental and continue to use
>> debian/latest for my unstable uploads.
> 
> If that's your workflow (the same as src:dbus, where versions 1.13.x
> are a development branch not recommended for general use), then I don't
> think debian/latest is a good name for that branch, and I'd recommend
> using debian/unstable for your unstable uploads.
> 
> Rationale: it seems very confusing if a branch with "latest" in its name
> does not contain the newest available version :-)

+1, moreover I find that "latest" does not convey the idea of something
that is in development: I tend to think about it in terms of "latest
release" or "latest version", something that is set already.

This is fine with uptream/latest, as we import the latest *released*
version of the upstream source, not the current work in progress tip.

Personally I'd prefer 'debian/devel': clearly the branch where
development happens.

Paride

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Emmanuel Arias]

Hi,

From my point of view (newbie point of view) it's more natural use the
default branch as my "target" codename. I mean, if I'm working on a
package that I will upload to unstable I hope use debian/unstable branch
for that. If I want to test or for any reason upload package to
experimental (or backport) I will prefer use for that a
debian/experimental for instance.

Introducing the the debian/latest name, for me, it's more like the
latest version, maybe on development before upload, but don't give me
more information about the status of the package. I think could be more
appropriate the name debian/dev, thinking on package into a Team.


On 8/28/20 8:01 PM, Raphael Hertzog wrote:
> Hello,
> 
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
> 
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.


0xFA9DEC5DE11C63F1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Russ Allbery]

Geert Stappers  writes:
> On 2020-08-30 at 14:46, Richard Laager wrote:

>> Using debian/sid makes the branch name inconsistent with 
>> debian/changelog, which traditionally uses "unstable" not "sid".

> There no need to have consistency between a git branch name and
> debian/changelog saying where to upload.

There is no *need* in the sense that the lack of correspondance will not
break anything technically, but these sorts of little inconsistencies and
arcana add friction, confusion, and irritation for people who don't work
with Debian regularly.  Making these sorts of things consistent does more
than it may appear at reducing the cognitive load and perceived fiddliness
of packaging, and therefore can help new packagers feel comfortable more
quickly.

It also creates the possibility for tools to observe inconsistencies like
"you're packaging in a branch named experimental but your upload is
targeting unstable," which would have caught some errors that I've made
even as an experienced packager.

-- 
Russ Allbery (r...@debian.org)  

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Russ Allbery]

Richard Laager  writes:
> On 8/29/20 5:19 PM, Russ Allbery wrote:

>> The problem in my case with not putting a branch name in Vcs-Git is
>> that, for packages for which I'm also upstream, the default branch in
>> the repository named in that header is the upstream development branch,
>> which contains no Debian packaging files and thus would be a very
>> confusing thing for debcheckout to clone.  So I have to name *some*
>> branch, which right now is debian/master and would be debian/latest.

> If the packaging is on Debian Salsa (which I would recommend), then I'd
> set the default branch to the packaging branch. If upstream happens to
> live there too, then people can switch to that explicitly.

This is a good point.

I have to admit that I wrote and deleted three different progressively
less upset replies because I apparently have a lot of emotional baggage
about project Git hosting.  I think I'm realizing that part of what's
upsetting me is exactly that we're not standardizing on Salsa or some
other Git repository collection as the canonical place where as much of
Debian packaging as possible is stored.  And while I can't change that
reality, pushing all of my own packaging to Salsa certainly wouldn't hurt
the goal of moving us in that direction, so maybe I should do that.

I agree that then makes the issue of Vcs-Git branch names moot.

If we could upload a package to the archive by pushing a signed tag to
Salsa, that of course would be even better and would, at least for me,
make Debian a more delightful project on which to work.

-- 
Russ Allbery (r...@debian.org)  

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Adam D. Barratt]

On Sun, 2020-08-30 at 14:52 -0400, The Wanderer wrote:
> On 2020-08-30 at 14:46, Richard Laager wrote:
[...]
> > (because there is no character code name for
> > experimental AFAIK).
> 
> I thought the same at one point, but in fact, there is: it's called
> rc-buggy.
> 
> https://wiki.debian.org/DebianReleases#Codenames
> http://ftp.debian.org/debian/dists/rc-buggy/

Yes and no.

The suite doesn't officially have a codename, as examining the Release
files will show. There's a symlink in the dists directory, similarly to
dists/Debian10.5.

Regards,

Adam

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Mathias Behrle]

* Simon McVittie: " Re: RFC: Final update of DEP-14 on naming of git packaging
  branches" (Sun, 30 Aug 2020 15:02:35 +0100):

> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
> > If I know that the next upstream release
> > breaks backwards compatitibly and that it will have to mature a long time
> > in experimental until all other packages are ready, I might start to
> > package it rigth now in debian/experimental and continue to use
> > debian/latest for my unstable uploads.  
> 
> If that's your workflow (the same as src:dbus, where versions 1.13.x
> are a development branch not recommended for general use), then I don't
> think debian/latest is a good name for that branch, and I'd recommend
> using debian/unstable for your unstable uploads.
> 
> Rationale: it seems very confusing if a branch with "latest" in its name
> does not contain the newest available version :-)

+1

Additionally I think explicit is usually better than implicit. When all other
branches are named following their suites why should we diverge for this special
case?
 
> (debian/master didn't have that problem because it's named by analogy
> to the "master" branch used in upstream git repositories, which doesn't
> really have a fixed meaning anyway.)

BTW the same applies for me to the (re-)naming of the 'default' branch
(currently master). If it is the default branch the most plausible name is just
'default'.


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgppPckIukqb9.pgp
Description: Digitale Signatur von OpenPGP

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Geert Stappers]

On Sun, Aug 30, 2020 at 02:52:33PM -0400, The Wanderer wrote:
> On 2020-08-30 at 14:46, Richard Laager wrote:
> > On 8/30/20 12:02 PM, Sean Whitton wrote:
> >> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
> >>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
> >>> index 0316fe1..beb96ea 100644
> >>> --- a/web/deps/dep14.mdwn
> >>> +++ b/web/deps/dep14.mdwn
> >>> +In the interest of homogeneity and of clarity, we recommend the use of
> >>> +`debian/unstable` over `debian/sid` as it better conveys its special 
> >>> nature
> >>> +as opposed to other branches named after codenames which are used for
> >>> +stable releases.
> >> 
> >> I think we should recommend debian/sid because for some years dgit
> >> has been generating branches called dgit/sid. I think it would
> >> smooth the integration between branches on salsa and branches on
> >> dgit.debian.org if both always used codenames.

Yes,  DEP-14 is about providing guidelines for this.

And DEP-14  guides the URL for `debcheckout`

 
> > Using debian/sid makes the branch name inconsistent with 
> > debian/changelog, which traditionally uses "unstable" not "sid".

There no need to have consistency between a git branch name
and debian/changelog saying where to upload.


> > It also makes debian/experimental an outlier that cannot be made
> > consistent (because there is no character code name for experimental
> > AFAIK).
> 
> I thought the same at one point, but in fact, there is: it's called
> rc-buggy.
> 
> https://wiki.debian.org/DebianReleases#Codenames
> http://ftp.debian.org/debian/dists/rc-buggy/
> 


Learn from bikeshedding that it is just bikeshedding.



Regards
Geert Stappers
-- 
Silence is hard to parse

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[The Wanderer]

On 2020-08-30 at 14:46, Richard Laager wrote:

> On 8/30/20 12:02 PM, Sean Whitton wrote:
>
>> Hello Raphael,
>> 
>> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
>>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
>>> index 0316fe1..beb96ea 100644
>>> --- a/web/deps/dep14.mdwn
>>> +++ b/web/deps/dep14.mdwn
>>> +In the interest of homogeneity and of clarity, we recommend the use of
>>> +`debian/unstable` over `debian/sid` as it better conveys its special nature
>>> +as opposed to other branches named after codenames which are used for
>>> +stable releases.
>> 
>> I think we should recommend debian/sid because for some years dgit
>> has been generating branches called dgit/sid. I think it would
>> smooth the integration between branches on salsa and branches on
>> dgit.debian.org if both always used codenames.
> 
> Using debian/sid makes the branch name inconsistent with 
> debian/changelog, which traditionally uses "unstable" not "sid". It
> also makes debian/experimental an outlier that cannot be made
> consistent (because there is no character code name for experimental
> AFAIK).

I thought the same at one point, but in fact, there is: it's called
rc-buggy.

https://wiki.debian.org/DebianReleases#Codenames
http://ftp.debian.org/debian/dists/rc-buggy/

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 8/30/20 12:02 PM, Sean Whitton wrote:
> Hello Raphael,
> 
> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
>> index 0316fe1..beb96ea 100644
>> --- a/web/deps/dep14.mdwn
>> +++ b/web/deps/dep14.mdwn
>> +In the interest of homogeneity and of clarity, we recommend the use of
>> +`debian/unstable` over `debian/sid` as it better conveys its special nature
>> +as opposed to other branches named after codenames which are used for
>> +stable releases.
> 
> I think we should recommend debian/sid because for some years dgit has been 
> generating branches called dgit/sid.  I think it would smooth the integration 
> between branches on salsa and branches on dgit.debian.org if both always used 
> codenames.

Using debian/sid makes the branch name inconsistent with
debian/changelog, which traditionally uses "unstable" not "sid". It also
makes debian/experimental an outlier that cannot be made consistent
(because there is no character code name for experimental AFAIK).

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Sean Whitton]

Hello Raphael,

On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
> index 0316fe1..beb96ea 100644
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> +In the interest of homogeneity and of clarity, we recommend the use of
> +`debian/unstable` over `debian/sid` as it better conveys its special nature
> +as opposed to other branches named after codenames which are used for
> +stable releases.

I think we should recommend debian/sid because for some years dgit has been 
generating branches called dgit/sid.  I think it would smooth the integration 
between branches on salsa and branches on dgit.debian.org if both always used 
codenames.

Thanks.

Sean

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

I think I now have a better handle on how/why I disagree with the DEP-14
recommendation language.

On 8/30/20 8:36 AM, Raphael Hertzog wrote:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I have no objection to DEP-14 supporting this workflow
>> with debian/latest. But I would like to see it (debian/latest)
>> recharacterized as the alternate approach rather than the recommended
>> method.
> 
> Your approach is perfectly valid but I don't really believe that it should
> be the recommended approach. It doesn't seem to match the most common
> workflow.
> 
> Most package maintainers are not actively working on two different
> development branches, instead the single development branch keeps moving
> between:
> - ready for unstable/upload to unstable
> - work in progress on a new upstream release
> - possible upload to experimental to gather feedback (buildd, users)
> - back to ready for upload to unstable

So you are regularly using multiple releases (unstable and experimental)
where the DEP-14 language allows you to use either debian/latest or
debian/{unstable,experimental}, but you feel debian/latest makes the
most sense most of the time in that scenario.

I think I see your point. You don't always know a priori when you are
going to want to upload to experimental. (Where you do know that, it's
because you expect the experimental piece to live in parallel for a
while and you'll use a temporary debian/experimental branch.) So you
have one debian/latest branch that can upload to unstable or
experimental as needed.

You could use debian/experimental all the time and then merge down to
debian/unstable only when you're ready to upload and have chosen
unstable. But I suspect your objection would be: that's unnecessary
busywork. And I see that point. I would probably make the same
objection, which means I think I agree with the debian/latest concept in
your situation.

I'm not sure if most package maintainers are doing this or not. I've
always assumed that most people are targetting only unstable most of the
time and that use of experimental is relatively rare. I could easily be
wrong on that. But that is definitely _my_ practice:

My package branch typically moves between:
- ready for unstable/upload to unstable
- work in progress on a new upstream release
- back to ready for upload to unstable

That is, I'm generally always targetting unstable and _not_ regularly
using multiple releases, so the DEP-14 language "prohibits" me from
using debian/unstable. This is what feels backwards to me. If I'm always
targetting unstable, debian/latest (and previously debian/master) is
less clear than debian/unstable.

At a minimum, can we rework this in some way so the language does not
require me to be regularly using multiple releases to use
debian/unstable as a branch name?

Preferably, can we change this to convey the following (probably using
better language):

  1. If you (have one line of package development and) regularly
 alternate between uploading to unstable and experimental, use
 debian/latest.
  2. If you normally only upload to unstable, use debian/unstable.
  3. If you will have a separate line of package development for upload
 to experimental, name that debian/experimental.  If that is
 long-lived, the other branch should be debian/unstable.

#1 covers your use case. #1 is listed first per your view that this is
the common case. #2 covers my use case. #3 allows either a #1 or #2
style to add debian/experimental temporarily, while recommending the
debian/{unstable,experimental} pair if the experimental branch is
long-lived (because it's confusing for debian/latest to not be the
latest version).

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 8/29/20 5:16 PM, Simon McVittie wrote:
> On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote:
>> However, this is still saying that one should prefer debian/latest over
>> debian/unstable, and that debian/unstable is (sort of) only for use when
>> you're also uploading to experimental.
> 
> The way I think of it phrases this a bit differently: whether or not you
> have a version targeting experimental right now, if you *were* uploading
> to experimental, what would you do?

I think that's a perfectly reasonable way to look at the issue. I don't
think that's what the DEP-14 language says, though.

> I think the workflow used in packaging dbus (with the newly proposed
> naming: debian/unstable as default, and a debian/experimental branch
> that runs ahead of it) is fine. This is good if you want to draw most
> attention to the version in unstable, with experimental being for early
> adopters and not recommended for general use.
> 
> I think the workflow used in packaging gnome-shell (with the newly
> proposed naming: debian/latest as default, and a debian/unstable branch
> that lags behind it) is *also* fine. This is good if you want to draw
> most attention to the version in experimental (when there is one).

In both cases, I would have debian/unstable and debian/experimental
branches.

I would draw attention to the main line of development by making that as
the default branch on the server: debian/unstable in the first case and
debian/experimental in the second. That way, someone who doesn't know
the package's branch style gets a hint on clone; someone who does
already knows which branch they want and can pick it explicitly. Of
course, the same server-side HEAD setting also works (and should be
used) if debian/latest is in use.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 8/29/20 5:19 PM, Russ Allbery wrote:
> The problem in my case with not putting a branch name in Vcs-Git is that,
> for packages for which I'm also upstream, the default branch in the
> repository named in that header is the upstream development branch, which
> contains no Debian packaging files and thus would be a very confusing
> thing for debcheckout to clone.  So I have to name *some* branch, which
> right now is debian/master and would be debian/latest.

If the packaging is on Debian Salsa (which I would recommend), then I'd
set the default branch to the packaging branch. If upstream happens to
live there too, then people can switch to that explicitly.

Rationale: The packaging is the more relevant thing to Debian. While
there are Debian native packages and some people are both upstream and
packager, the common case is software packaged from another upstream.

Then you don't need a branch name in debian/control.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[The Wanderer]

On 2020-08-30 at 10:02, Simon McVittie wrote:

> Rationale: it seems very confusing if a branch with "latest" in its
> name does not contain the newest available version :-)
> 
> (debian/master didn't have that problem because it's named by
> analogy to the "master" branch used in upstream git repositories,
> which doesn't really have a fixed meaning anyway.)

This would be the reason why I would have argued against choosing
'latest' for the name. If a replacement for 'master' is needed, the best
candidate I've encountered or come up with yet is generally 'primary'.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Simon McVittie]

On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
> If I know that the next upstream release
> breaks backwards compatitibly and that it will have to mature a long time
> in experimental until all other packages are ready, I might start to
> package it rigth now in debian/experimental and continue to use
> debian/latest for my unstable uploads.

If that's your workflow (the same as src:dbus, where versions 1.13.x
are a development branch not recommended for general use), then I don't
think debian/latest is a good name for that branch, and I'd recommend
using debian/unstable for your unstable uploads.

Rationale: it seems very confusing if a branch with "latest" in its name
does not contain the newest available version :-)

(debian/master didn't have that problem because it's named by analogy
to the "master" branch used in upstream git repositories, which doesn't
really have a fixed meaning anyway.)

smcv

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Sat, 29 Aug 2020, Richard Laager wrote:
> That said, I do understand we give a lot of deference to developers'
> workflows. So I have no objection to DEP-14 supporting this workflow
> with debian/latest. But I would like to see it (debian/latest)
> recharacterized as the alternate approach rather than the recommended
> method.

Your approach is perfectly valid but I don't really believe that it should
be the recommended approach. It doesn't seem to match the most common
workflow.

Most package maintainers are not actively working on two different
development branches, instead the single development branch keeps moving
between:
- ready for unstable/upload to unstable
- work in progress on a new upstream release
- possible upload to experimental to gather feedback (buildd, users)
- back to ready for upload to unstable

In some rare cases, we will have to do some intermediary upload to
unstable because some RC bug popped up and we don't want to wait until
we're ready with the next upload. In that case, we will create a
debian/unstable branch starting from the last tag in debian/unstable.

IOW, while branches are cheap, I create them on request only when I need
them, I'm not using multiple branches until I have a real need for it.

But I might also do the opposite. If I know that the next upstream release
breaks backwards compatitibly and that it will have to mature a long time
in experimental until all other packages are ready, I might start to
package it rigth now in debian/experimental and continue to use
debian/latest for my unstable uploads.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Andrea Bolognani]

On Sat, Aug 29, 2020 at 01:01:09AM +0200, Raphael Hertzog wrote:
> Hello,
> 
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
> 
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.
> 
> I'm proposing debian/latest now because DEP-14 is already recommending
> upstream/latest and that makes the result a bit more consistent. But if
> enough person disagree with this choice, we can look into setting a poll
> to choose among all the names proposed so far.

We switched libvirt from debian/sid to debian/master a few days ago,
and honestly I was feeling a bit uncomfortable about the new name but
adopted it anyway on the basis that it is formalized in DEP-14, which
we have been following for a long time.

Using debian/latest removes this problem, and as you point out is
also entirely consistent with the existing upstream/latest. So, for
whatever it might be worth, you have my +1 for this change.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Russ Allbery]

Richard Laager  writes:
> On 8/29/20 3:33 PM, Russ Allbery wrote:

>> I think the primary thing that bothers me about this workflow is that
>> experimental becomes an ephemeral branch, which appears and disappears
>> based on the vagaries of the release cycle.

> To me, that feels like the branch is an accurate representation of
> reality. The packages in experimental are ephemeral and appear and
> disappear too, right?

Yes, this is true.

>> That said, one way in which this becomes concrete is the Vcs-Git
>> control field.  What do you put in the branch field for your
>> experimental upload?  Naming debian/experimental is clearly wrong; that
>> branch is highly likely to not exist when someone later checks.  Naming
>> debian/unstable is also clearly wrong; the package is not based on that
>> branch.

> I wouldn't (and don't) put a branch name there. I don't think it serves
> a practical purpose. If it does, I guess a corollary is that I/we should
> be specifying debian/buster there for stable updates and likewise
> debian/buster-backports for backports. Is that a thing people actually
> do? I haven't been, but I can do so if that is a best practice.

Vcs-* as defined in policy identify "the branch used for development of
new versions of the Debian package."  I think whether that should point to
the stable release branch for stable uploads is debatable; I can see
arguments either way.  In practice, it generally does not because most
packages never receive a stable upload and thus Vcs-Git is set to whatever
it was set to during the last upload to unstable that made it into the
release.  So the de facto meaning is the branch on which new development
happens, not the release branch for the stable release.

The problem in my case with not putting a branch name in Vcs-Git is that,
for packages for which I'm also upstream, the default branch in the
repository named in that header is the upstream development branch, which
contains no Debian packaging files and thus would be a very confusing
thing for debcheckout to clone.  So I have to name *some* branch, which
right now is debian/master and would be debian/latest.

-- 
Russ Allbery (r...@debian.org)  

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Simon McVittie]

On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote:
> However, this is still saying that one should prefer debian/latest over
> debian/unstable, and that debian/unstable is (sort of) only for use when
> you're also uploading to experimental.

The way I think of it phrases this a bit differently: whether or not you
have a version targeting experimental right now, if you *were* uploading
to experimental, what would you do?

I think the workflow used in packaging dbus (with the newly proposed
naming: debian/unstable as default, and a debian/experimental branch
that runs ahead of it) is fine. This is good if you want to draw most
attention to the version in unstable, with experimental being for early
adopters and not recommended for general use.

I think the workflow used in packaging gnome-shell (with the newly
proposed naming: debian/latest as default, and a debian/unstable branch
that lags behind it) is *also* fine. This is good if you want to draw
most attention to the version in experimental (when there is one).

smcv

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 8/29/20 3:33 PM, Russ Allbery wrote:
> I think the primary thing that bothers me about this workflow is that
> experimental becomes an ephemeral branch, which appears and disappears
> based on the vagaries of the release cycle.

To me, that feels like the branch is an accurate representation of
reality. The packages in experimental are ephemeral and appear and
disappear too, right?

> That said, one way in which this becomes concrete is the Vcs-Git control
> field.  What do you put in the branch field for your experimental upload?
> Naming debian/experimental is clearly wrong; that branch is highly likely
> to not exist when someone later checks.  Naming debian/unstable is also
> clearly wrong; the package is not based on that branch.

I wouldn't (and don't) put a branch name there. I don't think it serves
a practical purpose. If it does, I guess a corollary is that I/we should
be specifying debian/buster there for stable updates and likewise
debian/buster-backports for backports. Is that a thing people actually
do? I haven't been, but I can do so if that is a best practice.

I currently set the branch name in debian/gbp.conf because that actually
has a practical effect on the tools.

Putting the branch name in debian/gbp.conf leads to a small amount of
churn for things like stable updates and backports. I had forgotten
about the effects of that in your case. That does undercut my argument a
bit in the immediate term, as you'd have to change that when going
between experimental and unstable, which means they aren't just
fast-forward merges. But if we standardize on this naming convention as
I propose, then gbp could default to these branch names, which means we
wouldn't need to set branch names in debian/gbp.conf. That seems like
the best long-term outcome.

> It's valid to say that it's okay for me to feel odd and I can cope with
> feeling odd and follow the convention anyway.

To be honest, I lean towards that view. But you've been doing Debian
development more and/or longer than me (and more to the point here,
actually use experimental regularly), so I'm very hesitant to dismiss
your viewpoint. I could easily be missing something.

I would love to see other people weigh in on debian/latest vs
debian/unstable as the default. Assuming the silent majority is using
debian/{master,latest}, is that out of a considered preference over
debian/unstable or out of inertia / following other packages / following
DEP-14? In other words, how many people _care_ either way?

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Gunnar Wolf]

Seconded. Thanks!

Raphael Hertzog dijo [Sat, Aug 29, 2020 at 01:01:09AM +0200]:
> Hello,
> 
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
> 
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.
> 
> I'm proposing debian/latest now because DEP-14 is already recommending
> upstream/latest and that makes the result a bit more consistent. But if
> enough person disagree with this choice, we can look into setting a poll
> to choose among all the names proposed so far.
> 
> Let me know your thoughts:
> 
> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
> index 0316fe1..beb96ea 100644
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> @@ -2,11 +2,11 @@
>  
>  Title: Recommended layout for Git packaging repositories
>  DEP: 14
> -State: DRAFT
> -Date: 2016-11-09
> -Drivers: Raphael Hertzog 
> -URL: http://dep.debian.net/deps/dep14
> -Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
> +State: ACCEPTED
> +Date: 2020-08-29
> +Drivers: Raphaël Hertzog 
> +URL: https://dep-team.pages.debian.net/deps/dep14/
> +Source: 
> https://salsa.debian.org/dep-team/deps/-/blob/master/web/deps/dep14.mdwn
>  Abstract:
>   Recommended naming conventions in Git repositories used
>   to maintain Debian packages
> @@ -92,24 +92,28 @@ For development releases
>  
>  
>  Packages uploaded to the current development release should be prepared
> -in a `/master` branch.
> +in a `/latest` branch.
>  
>  However, when multiple development releases are regularly used (for
>  example `unstable` and `experimental` in Debian), it is also accepted to
> -name the branches according to the codename or the suite name of the
> -target distribution (aka `debian/sid` or `debian/unstable`, and
> -`debian/experimental`). Those branches can be short-lived (i.e. they exist
> -only until they are merged into `/master` or until the version in
> -the associated repository is replaced by the version in `/master`)
> -or they can be permanent (in which case `/master` should not
> -exist).
> +name the branches according to the suite name of the
> +target distribution (aka `debian/unstable`, and `debian/experimental`).
> +Those branches can be short-lived (i.e. they exist only until they are
> +merged into `/latest` or until the version in the associated
> +repository is replaced by the version in `/latest`) or they can be
> +permanent (in which case `/latest` should not exist).
> +
> +In the interest of homogeneity and of clarity, we recommend the use of
> +`debian/unstable` over `debian/sid` as it better conveys its special nature
> +as opposed to other branches named after codenames which are used for
> +stable releases.
>  
>  NOTE: If the Git repository listed in debian/control's `Vcs-Git` field does
>  not indicate an explicit branch (with the `-b ` suffix) then it 
> should
>  have its HEAD point to the branch where new upstream versions are being
>  packaged (that is one of the branches associated to a development release).
>  The helper tools that do create those repositories should use a command
> -like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD
> +like `git symbolic-ref HEAD refs/heads/debian/latest` to update HEAD
>  to point to the desired branch.
>  
>  For stable releases
> @@ -200,7 +204,7 @@ developers and the package maintainers are not the same 
> set of persons.
>  
>  When upstream is Debian (or one of its derivative), the upstream vendor
>  should not use the usual `/` prefix (but all others vendors should
> -do so). The main development branch can be named `master` instead of
> +do so). The main development branch does not have to be named after
>  the codename of the target distribution (although you are free to still
>  use the codename if you wish so).
>  
> @@ -293,3 +297,6 @@ Changes
>  
>  * 2014-11-05: Initial draft by Raphaël Hertzog.
>  * 2016-11-09: Extended version mangling to troublesome dots -- Ian Jackson.
> +* 2020-08-29:
> +  * Replace debian/master with debian/latest
> +  * Recommend debian/unstable over debian/sid



-- 



signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Russ Allbery]

Richard Laager  writes:

> When I last brought this up [1], Russ Allbery said that debian/latest
> was desirable (to him, at least) because, "My normal use of experimental
> does not involve maintaining unstable and experimental branches
> simultaneously.  I essentially never do that; instead, I maintain one
> development branch, which I upload to either experimental or to unstable
> based on things like where we are in the release cycle or whether I need
> to stage some change." [2]

> I believe that "git branches are cheap", so I don't really see the
> problem in switching back and forth between debian/unstable and
> debian/experimental in that case. Given that he further said, "If I'm
> uploading to experimental, I don't fix bugs in unstable until the
> experimental release is ready for upload to unstable.", the merges would
> be fast-forward merges anyway, so they wouldn't take any actual hand
> merge work. Using separate branches would inherently allow for proper
> handling of the "exception" he described of needing to upload a fix to
> unstable while debian/latest is the upload to experimental.

I think I understand your argument here.  The point that Git branches are
cheap is valid.

I think the primary thing that bothers me about this workflow is that
experimental becomes an ephemeral branch, which appears and disappears
based on the vagaries of the release cycle.  This is unlike every other
packaging branch I use, which are stable release branches.  They may not
receive any further activity, but debian/etch, for instance, is still a
meaningful branch (it was the last thing uploaded to etch), it has meant
the same thing since I first created it, and there's no reason to ever
delete it.

debian/experimental, on the other hand, is essentially an ephemeral
development branch off of debian/unstable with little continuity.  If one
uses Git in a way that emphasizes ephemeral development branches that are
pushed publicly but then disappear randomly, that may not feel like much
of a problem, and I know that's a common GitHub workflow.  But to me it
feels very strange to delete the branch on which uploads to the archive
were based (and even stranger to leave it around when it's older than
unstable).

Perhaps this is my problem, and I should embrace the fact that the history
is reachable from the tag and can be merged back into the unstable branch
and stop worrying about it.

That said, one way in which this becomes concrete is the Vcs-Git control
field.  What do you put in the branch field for your experimental upload?
Naming debian/experimental is clearly wrong; that branch is highly likely
to not exist when someone later checks.  Naming debian/unstable is also
clearly wrong; the package is not based on that branch.

Maybe that doesn't matter.  Indeed, this is part of the argument against
having Vcs-* fields in source packages, I realize.  But it makes this
convention feel odd to me.

It's valid to say that it's okay for me to feel odd and I can cope with
feeling odd and follow the convention anyway.

-- 
Russ Allbery (r...@debian.org)  

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Richard Laager]

On 8/28/20 6:01 PM, Raphael Hertzog wrote:
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.

I think this is a change in the right direction.

However, this is still saying that one should prefer debian/latest over
debian/unstable, and that debian/unstable is (sort of) only for use when
you're also uploading to experimental.

I think this is backwards. I think the default should be
debian/unstable. If you want to use experimental, then also use a
debian/experimental branch.

The big advantage of this approach is that the branch names are always
consistent with changelog names. This works well when you need a
debian/buster for a stable update and/or a debian/buster-backports for a
backport. Aside from being helpful to humans, this consistency then
makes for a reasonable default in the tools (e.g. git-buildpackage). It
also extends perfectly to use with downstream distributions, with things
like ubuntu/bionic, ubuntu/focal, etc. FWIW, I have a package using all
of debian/{buster,buster-backports,unstable} and ubuntu/bionic right now
and it works great.

When I last brought this up [1], Russ Allbery said that debian/latest
was desirable (to him, at least) because, "My normal use of experimental
does not involve maintaining unstable and experimental branches
simultaneously.  I essentially never do that; instead, I maintain one
development branch, which I upload to either experimental or to unstable
based on things like where we are in the release cycle or whether I need
to stage some change." [2]

I believe that "git branches are cheap", so I don't really see the
problem in switching back and forth between debian/unstable and
debian/experimental in that case. Given that he further said, "If I'm
uploading to experimental, I don't fix bugs in unstable until the
experimental release is ready for upload to unstable.", the merges would
be fast-forward merges anyway, so they wouldn't take any actual hand
merge work. Using separate branches would inherently allow for proper
handling of the "exception" he described of needing to upload a fix to
unstable while debian/latest is the upload to experimental.

That said, I do understand we give a lot of deference to developers'
workflows. So I have no objection to DEP-14 supporting this workflow
with debian/latest. But I would like to see it (debian/latest)
recharacterized as the alternate approach rather than the recommended
method.

Previously, my proposal would have required a fair amount of branch
renaming--from debian/master to debian/unstable. However, with the
change from debian/master to debian/latest, branch renaming would "have
to" occur anyway, so renaming debian/master to debian/unstable is no
more trouble.

[1] https://lists.debian.org/debian-devel/2019/11/msg00084.html
[2] https://lists.debian.org/debian-devel/2019/11/msg00085.html

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Samuel Henrique]

> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.

+1 to this and the other changes.

I believe we will be able to easily perform the branch naming changes
under the pkg-sec team.

Regards,


--
Samuel Henrique 

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Didier 'OdyX' Raboud]

Le samedi, 29 août 2020, 01.01:09 h CEST Raphael Hertzog a écrit :
> Hello,
> 
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
> 
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.

Thanks for this proposal. I can't help but feel overwhelmed by the upcoming 
change to main branches of "so many" repos to debian/latest, but I feel it's 
definitely worth it (and scriptable).

Seconded.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[David Prévot]

Le 28/08/2020 à 19:01, Raphael Hertzog a écrit :


Basically it replaces debian/master
with debian/latest for all the reasons already discussed earlier.

[…]

Let me know your thoughts:

diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
index 0316fe1..beb96ea 100644
--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -2,11 +2,11 @@
  
  Title: Recommended layout for Git packaging repositories

  DEP: 14
-State: DRAFT
-Date: 2016-11-09
-Drivers: Raphael Hertzog 
-URL: http://dep.debian.net/deps/dep14
-Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
+State: ACCEPTED
+Date: 2020-08-29
+Drivers: Raphaël Hertzog 
+URL: https://dep-team.pages.debian.net/deps/dep14/
+Source: 
https://salsa.debian.org/dep-team/deps/-/blob/master/web/deps/dep14.mdwn
  Abstract:
   Recommended naming conventions in Git repositories used
   to maintain Debian packages
@@ -92,24 +92,28 @@ For development releases
  
  
  Packages uploaded to the current development release should be prepared

-in a `/master` branch.
+in a `/latest` branch.
  
  However, when multiple development releases are regularly used (for

  example `unstable` and `experimental` in Debian), it is also accepted to
-name the branches according to the codename or the suite name of the
-target distribution (aka `debian/sid` or `debian/unstable`, and
-`debian/experimental`). Those branches can be short-lived (i.e. they exist
-only until they are merged into `/master` or until the version in
-the associated repository is replaced by the version in `/master`)
-or they can be permanent (in which case `/master` should not
-exist).
+name the branches according to the suite name of the
+target distribution (aka `debian/unstable`, and `debian/experimental`).
+Those branches can be short-lived (i.e. they exist only until they are
+merged into `/latest` or until the version in the associated
+repository is replaced by the version in `/latest`) or they can be
+permanent (in which case `/latest` should not exist).
+
+In the interest of homogeneity and of clarity, we recommend the use of
+`debian/unstable` over `debian/sid` as it better conveys its special nature
+as opposed to other branches named after codenames which are used for
+stable releases.
  
  NOTE: If the Git repository listed in debian/control's `Vcs-Git` field does

  not indicate an explicit branch (with the `-b ` suffix) then it should
  have its HEAD point to the branch where new upstream versions are being
  packaged (that is one of the branches associated to a development release).
  The helper tools that do create those repositories should use a command
-like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD
+like `git symbolic-ref HEAD refs/heads/debian/latest` to update HEAD
  to point to the desired branch.
  
  For stable releases

@@ -200,7 +204,7 @@ developers and the package maintainers are not the same set 
of persons.
  
  When upstream is Debian (or one of its derivative), the upstream vendor

  should not use the usual `/` prefix (but all others vendors should
-do so). The main development branch can be named `master` instead of
+do so). The main development branch does not have to be named after
  the codename of the target distribution (although you are free to still
  use the codename if you wish so).
  
@@ -293,3 +297,6 @@ Changes
  
  * 2014-11-05: Initial draft by Raphaël Hertzog.

  * 2016-11-09: Extended version mangling to troublesome dots -- Ian Jackson.
+* 2020-08-29:
+  * Replace debian/master with debian/latest
+  * Recommend debian/unstable over debian/sid


Seconded.

Regards

David