Re: A question about patches for upstream
On 7 May 2014 01:19, Charles Plessy <plessy@debian.org> wrote:
> Hi Matthias,
>
> your answer exemplifies very well what I mean with “pressed by the machine”…
>
> I will reply on one point only.
>
> Le Wed, May 07, 2014 at 01:46:32AM +0200, Matthias Klose a écrit :
>> Am 06.05.2014 03:05, schrieb Charles Plessy:
>> >
>> > When the first mass rebuilds with GCC and porting issues came to Debian, I was
>> > very impressed. Years later it became a routine and I sometimes feel that I am
>> > pressed by a machine. There is not much apparent coordination with the other
>> > distributions (not our derivatives) that also conduce such large screens.
>>
>> This is wrong. And I would like you to better research such claims before
>> posting these as facts.
>
> Please trust me that I do not intend to be derogatory, demotivating or
> libelous. In what I wrote, I made sure that the word “apparent“ is there, to
> show that I am not implying that there is no coordination, nor even not enough
> coordination.
>
> This said, please consider if there would be a benefit that people in my
> situation can see better the coordination that is already taking place. I
> would argue that by definition, something that nedds “better research” is not
> as apparent as it could be. I have not seen much reference to similar efforts
> in other distributions in the emails sent on this list to announce mass
> rebuilds. If you were considering about being more verbose and write a bit
> more about what is happening behind the curtain, I am sure that it would be
> appreciated (at least by me).
>
The set of things that are involved in a toolchain is a large one:
1) major versions of default kernel, glibc, binutils, gcc, make, clang..
2) distro-specific patches applied on top of those
3) whether DSO linking is enabled, Hardening enabled, which ones, etc.
4) packages them-self (not everything is packaged everywhere, or in
the same way)
5) current transitions etc. or rather overlaps between those...
multiarchification...
6) supported architectures, of which debian typically has those that
nobody else does
7) ...
What Matthias is saying does resonate with me, since i have been
involved in resolving above issues, and even overlaps of above. (E.g.
in a single upload first fix configure.ac to support some build-dep
multiarch, then fix dh-autoreconf failure now induced, then port to a
new api of a given thing, then fix new major-version of gcc -Werrors,
and then in the end get eaten by symbols missmatches on mipsel).
Naturally some of the above issues are common among other
distributions and upstreams. Thus before I go around writing a patch
to port to, for example BOOST_FILESYSTEMS v3 API, I first check
upstream VCS (boo dead, no commits), patches in their bug
tracker/mailing list (boo nothing), other distros that e.g. started
using newer boost ahead of debian (fedora, opensuse, gentoo, etc...
all of which patches are trivially browsable online). But if something
is in fact trivial, it is at times quicker to just fix it myself (even
if that produces identical or near-identical fix that may have been
available from elsewhere).
Just because a patch to port a random dkms module to newer kernels has
not been posted to LKML (aka the central repository of patches for
kernelish things) it doesn't mean that one doesn't exist elsewhere. I
don't see how a central repository of patches or aggregation would
work or help much. As it's again tangential extra work to create
central repository of patches, contribute to it, and each distro
applying patches from it. E.g. it would be best for e.g. upstreams to
notice those issues with pre-release software of all of their
reverse-dependencies, write a fix, and make release and point releases
of every release ever made or used by any of the distros... However,
debian would only care about the fix if it's needed for the Debian's
current "toolchain" set, which is highly likely to be different from
every other distribution out there.
I believe that package not FTBFS is a fundamental requirement for a
package to be in Debian. Thus Debian maintainers, developers and
contributors collective are responsible on getting those fixed. If a
patch is available, it should be applied swiftly by the maintainer, as
otherwise it's actively delaying release or release goal or a given
port bringup or a given port eligibility to become a release
architecture. Collectively it is in the best interest to get the patch
upstreamed. There is no hard & fast rule, but it is assumed that a
maintainer has a relationship with upstream and/or has forwarded
patches to upstream before. If anyone is complaining "why has this
patch hasn't been upstream" it's trivial to point them to our patch
tracker inviting them to scratch their own itch and do as needed with
it (e.g. send/apply upstream, send/apply in other distributions,
send/apply in backports-security-stableupdate, etc.)
"A central repository of opportunities" has been tried to establish
before - http://harvest.ubuntu.com/ I think it does fetch
patches/branches from launchpad, applied patches in fedora, and maybe
more. I didn't find it useful yet, when finding a specific fix i'm
after for a given FTBFS (e.g. gcc4.x fix + boost1.5.x fix + something
else). Although harvest has a different target audience, I think,
something like prospective/new distribution developers who need hints
as to what is needed to be done.
To give direct answers:
Does the Debian guidelines give any hints on who is responsible to
report a patch upstream? Is it the bug submitters or the Debian package
maintainers responsibility?
- both are, as it's in everyone's best interest. however, due to
numerous factors it may end up getting done by someone else, never
happening (or rather hasn't happened yet), or not needed at all due to
patch being distro-specific.
...(in addition to eventually apply them to the packages)?
- maintainer typically does apply patches, but has no responsibility
to do so. Others can apply patches as well, e.g. via NMU process.
Package maintainer has the right to veto changes in their packages.
Thus you would find some packages in debian revert changes done
upstream. Or keep patches that were rejected upstream, etc.
There is no hard-rule, or a generic recommendation that can be
trivially applicable to all patches ever, against all packages. And
it's wasteful for us to discuss this in generic terms. If some patch
you care about has been neglected so far, talk to people about it,
probe maintainer/upstream about it, offer to NMU it, etc.
--
Regards,
Dimitri.
Reply to: