On 7 May 2014 01:19, Charles Plessy <ple...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlujpxbubahck6qgcbws7foji+ym0pgb5d6noa0y+j20...@mail.gmail.com