Hi there, I've been mostly VAC, and only now found enough time to properly read through this bug log. In the interest of transparency and to help the TC reach a consensus (also through understanding what the other members' understanding, ideas and positions are), here comes my current understanding of the problem at hand.
As preamble, I will upfront state that I have _not_ looked in the precise
details of the so-called 'htags' functionality, as, the rest will show, my
current viewpoint on the problem is that it doesn't matter.
* src:global hasn't had a Debian upload since October 2010, for wheezy ,
and no new upstream-release Debian upload since September 2007, for
lenny (although there was on upload yesterday)
* there was no src:global upload to experimental
* its maintainer, Ron Lee, failed to provide timely and comprehensive answers
to various requests through bugreports over the years. On #574947
specifically, a bug filed in March 2010, Ron's first answer in April 2013
boiled down to "we're in freeze now, no".
* Ron claims to have had various private conversations about src:global with
various parties about the problems that a new upstream upgrade would pose.
* How the 'htags' functionality is implemented in newer upstream releases
seems to be at the heart of what Ron sees as making these "unsuitable for
release with the distro".
* There is arguably frustration on all sides of the discussion about upgrading
src:global to newer upstream releases, both sides arguing that they are
doing the right thing for Debian.
Now. I'd like to write down some considerations about the Debian namespace.
Debian, as a Free Software distribution, ships various software made by
various upstream authors, thereby filling the Debian source packages, binary
packages, and binaries namespaces. Upstream's global_*.tar.gz is shipped as
src:global source package, producing the 'global' binary package, shipping the
/usr/bin/global binary [0].
The TC has had various discussions about uses and abuses of these various
namespaces (especially the 'binary packages' and 'binaries' namespaces) in the
past, usually in cases of conflict. Various developers also often safeguard
the namespaces by launching discussions upon ITPs proposing too generic names.
How we handle these namespaces of ours is certainly an important topic for the
project. (But don't mistake me, the 'global' name isn't the problem here).
All these namespaces are also interfaces of what we as a project create, with
the community of our users. The most important of these three is arguably the
binary packages namespace, which is the usual interface with the software we
ship. It has been customary to have a one-to-one mapping between upstream
projects, and binary package names, and in all cases where we decided
otherwise (iceweasel, cupsys, nodejs, …), it has imposed a lot of
documentation and convincing for our users to get used to these.
All in all, I think there is a reasonable expectation from our users to have
our namespaces match the rest of the ecosystem; there is an expectation that a
given 'foobar' upstream, iff packaged for Debian, gets to be shipped as the
'foobar' binary package. And I think that extends to versions as well; it is
expected that our releases ship with 'reasonably recent' versions, as well.
(
I know, Debian stable releases aren't known for the freshness of their
packages. There's still an expectation from our users
)
Outside of special times with regards to releases (that is, outside frozen
times), it is quite customary for packages to 'catch back' on new upstream
releases. This has multiple effects: it prepares the new _functionalities_,
and bug fixes for the next stable release; it also often comes with
regressions and new bugs; annoyances and headaches for users and maintainers
alike. Uploading new upstream releases and letting them be consumed by a
portion of our userbase (unstable & testing users), is a way to share the
burden, and _discover_ what those regressions and bugs are; identify, then try
to fix or document these.
As you have understood by now, I think it is a reasonable expectation from
package users to get new upstream releases between stable releases. The
upstream software evolves independently of Debian, and if we're not forking
the upstream software, we owe updates to our users as part of our "package
maintainers" duty. It's also our role to ship the newer works of our upstreams
to our users. (To clarify: I'm not saying there can't be exceptions.)
Now, coming back to src:global, there was a first request in March 2010
(#574947, 5.8.1) to get a new upstream release, before the squeeze freeze,
only answered late during the wheezy freeze (at that time, 6.2.8 was
released). The other request (#816924, 6.5.2) landed in March 2016, 9 months
before the stretch release. For me, it looks like the squeeze, jessie _and_
stretch release cycles have offered _vast_ opportunity to upload new upstream
versions, iron the bugs out in unstable (blocking migration to newer stable
for as long as needed to fix these supposed bugs), and land in testing.
I understand Ron's approach as follows: "I see this potential regression in
new upstream releases, which I want addressed before (even considering)
uploading it to unstable". This seems to have been the argument against any
new upstream uploads in the last 6+ years, deferring the resolution of these
potential regressions onto others. This, frankly, defeats the whole point of
having an 'unstable' suite, in which real users get their hands on new
packages, file bugs and find regressions; in which maintainers followup on
these, pipe them up to upstream, collaborate with both upstream and Debian
users to find satisfactory solutions, to provide the best of upstream works
combined with out Debian-specific expertise to our users.
Now, from the users' point of view, the src:global shipped in Debian has
various bugs, which upstream addressed (#590053, fixed in 5.9.1; #756367,
fixed in 6.3, #844356 fixed in 6.5.5).
To conclude with my current thoughts:
* I think our user's expectation of having a reasonably recent global when
using our 'global' package is justified.
* I think there was plenty of time and opportunities given to the current
src:global maintainer to ship the new upstream releases to our users (the
package could have been 6.1 in squeeze, 6.2 in wheezy, 6.3 in jessie; 6.5
could be in stretch), at the _very_ least in experimental, at least in
unstable.
* Without assuming malice, I observe that despite action promises, there were
no steps towards a 6.* src:global upload, and that the 'upcoming' or
'current' freezes have been repeatedly used as postponers multiple times
already; work also hadn't resumed after the releases.
* In general, as well as specifically for the src:global package, I don't
think it's reasonable for a maintainer to indefinitely [1] hold new upstream
releases back; if new releases have bugs, we ought to identify and fix them,
idealy in collaboration with upstream. If the new releases have immediately
identifiable flaws, then the initial new releases should be uploaded to
experimental, and Debian as well as upstream bugs filed. Uploads to unstable
with serious bugs (as in "makes the package unsuitable for release in the
package maintainer's opinion") are also acceptable, of course.
* In general, I think the namespace should be reserved to the most recent
package for a given upstream. I don't think it's reasonable to force the
maintenance of a src:global6 because the src:global maintainer insists on
staying on an old version.
* I'm not happy with delaying the landing of a 6.x version of global for
another release, and despite the somehwat short time before the stretch full
freeze (2017-Feb-05), we're talking about a single binary package without
reverse dependencies. I'm really afraid that a side-effect of the TC
discussion will be yet-another release without an up-to-date src:global.
I see the following good ways out of this problem:
A) Ron stays maintainer of src:global and uploads a reasonably recent 6.x
version to unstable;
B) (With or without an explicit decision by the TC), src:global is handed over
to new maintainers and they'd upload a reasonably recent 6.x version to
unstable;
(
In both A) and B) cases, whoever is maintainer of src:global would be in
charge of handling the subsequent (so far hypothetical) bugs in time for
the release. As usual, everyone is welcome to help with finding,
forwarding, and fixing bugs.
)
I see this as a suboptimal outcome, because it rewards inertia and stop-
energy:
C) Ron stays maintainer of src:global and uploads a reasonably recent 6.x
version to experimental, with the explicit goal of making that version later
available through stretch-backports.
--
Cheers,
OdyX
P.S. Sorry for the wall of text, including too many repetitions :/
[0] I know, it's all obvious.
[1] Yes, 6+ years, even at the Debian rhythm, is indefinite.
signature.asc
Description: This is a digitally signed message part.
