Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Hi Sam,

Russ> Thanks for the review!  There's now a newer version of this
Russ> diff adjusted for a flaw that Simon pointed out.  It's
Russ> sufficiently different from the original diff that I don't
Russ> want to count seconds for the original as seconds for it.
Russ> It's at:

Russ> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542288#280

Aargh, sorry.
I read Simon's message, and then read your earlier patch in the wrong
order, and thought, wow Russ managed to come up with a way to address
Simon's issue that was shorter than I thought.
(Not realizing that I was responding to a message before you had
addressed it).

I'm happy to second the newer patch in #280 although I have one
non-blocking comment.

+- ``upstream_version`` components in native packages ending in
``+debNuX``
+  indicate a stable update.  This is a version of the package uploaded
+  directly to a stable release, and the version is chosen to sort
before
+  any later version of the package uploaded to Debian's unstable or a
+  later stable distribution.  ``N`` is the major version number of the
+  Debian stable release to which the package was uploaded, and ``X`` is
a
+  number, starting at 1, that is increased for each stable upload of
this
+  package.
+


Because this comes before [+~]debXuN in the Debian revision, it's easy
for a reader to treat this as a common case on first reading.
I think it's much more common for us to have the stable update noted in
a Debian revision than in the upstream revision, and we should say this.


I hugely confused myself by missing the word "native" in the above  and
was starting to think about why we'd ever mark a stable update in the
upstream version of a non-native package.
Your text does in fact include native, but this illustrates how even for
a experienced packager, having the uncommon case first can  lead to
confusion.

--Sam


signature.asc
Description: PGP signature

Bug#986320: Stronger advice on when to use native packages

[Russ Allbery]

Sam Hartman  writes:

> I'd propose the following way forward:

> 1) Capture the discussion thread we had during my DPL term and the
> things to think about that were brought up in the native packages part
> of that discussion.
> I'm not sure policy is the right place for those; I think some of those
> might better belong in a wiki page or dev ref.

> 2) Figure out  what the work flow gaps are that cause people to find
> native packages easier to deal with.
> I suspect we'll find that something in our git workflows is not great
> especially for closely tracking upstream git and especially when
> upstream itself doesn't make releases.

> 3) Fix these work flow gaps.

> 4) Then add advice to policy.

Thank you for this perspective!  I had entirely forgotten about that.

Realistically, I probably won't be able to drive this myself (at least
soon), since I want to try to dig through the Policy backlog for places
where we're blocking progress (which I don't think is true here).  But
even if we don't tackle this soon, I think this is a great statement of
the issues.

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

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Sam Hartman  writes:
>> "Russ" == Russ Allbery  writes:

> Russ> Here is an updated diff that documents the most
> Russ> well-understood version conventions in the Debian archive.
> Russ> More could certainly be added; this is just a first start that
> Russ> addresses this specific bug.

> Russ> This revised patch is less aggressive about defining native
> Russ> packages to only mean packages with no existence external to
> Russ> Debian.  I also found that we never define upstream, which
> Russ> seems like a critical concept, so I added a definition to the
> Russ> Definitions section.

> second.

Hi Sam,

Thanks for the review!  There's now a newer version of this diff adjusted
for a flaw that Simon pointed out.  It's sufficiently different from the
original diff that I don't want to count seconds for the original as
seconds for it.  It's at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542288#280

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

Bug#986320: Stronger advice on when to use native packages

[Sam Hartman]

I do not support advising against using native packages with our current
tooling.

My issue is that for some work flows  generating and keeping up with the
upstream tarballs significantly increases the frustration of packaging
and and brings doing a package update across a pain threshhold that
psychologically matters.
The idea is that if I can accomplish a task in a minute or two without
much frustration, I'll do it more and be happier doing it.

If the task takes twice as long, especially when I can't see the value
in the steps, resentment builds up, happiness decreases, and the task is
done less often.

Being able to update packages frequently without frustration is more
important to me than the legitimate concerns raised about native
packages.
I was actually surprised how many legitimate things to think about we
came up with while discussing native packages during my DPL term.
(There's a pointer from the consensus summary I wrote up to d-d-a.)

But at least for me, when I'm trying to closely track a fast moving
upstream  from a git repo, native packages are just easier.
Generating new upstream tarballs for each upstream change, trying to
keep track of when I needed to do that,  and keeping track of all the
upstream tarballs crosses a frustration threshhold for me.

Various suggestions were made during previous discussions to make
workflows easier.
Unfortunately, these suggestions were generally made while dismissing
the needs of people favoring native packages.
I'll admit that I was frustrated when people were dismissing my concerns
enough that   it was hard to engage with the suggestions.
It's possible there are better work flows I don't know about, but I
think there are still gaps.

I'd propose the following way forward:

1) Capture the discussion thread we had during my DPL term and the
things to think about that were brought up in the native packages part
of that discussion.
I'm not sure policy is the right place for those; I think some of those
might better belong in a wiki page or dev ref.

2) Figure out  what the work flow gaps are that cause people to find
native packages easier to deal with.
I suspect we'll find that something in our git workflows is not great
especially for closely tracking upstream git and especially when
upstream itself doesn't make releases.

3) Fix these work flow gaps.

4) Then add advice to policy.



signature.asc
Description: PGP signature