On Wed, 2022-02-16 at 16:51 +0000, Simon McVittie wrote: > If the maintainers of dak (our eternally overworked ftp team) want to > pick up build logs as first-class artifacts produced by both failed > and successful builds, they're welcome to do so (and then handling my > prototype of test artifacts would be a matter of adding another glob > pattern to be stored, for the tarball of artifacts that accompanies the > log); but I don't want to block on them doing that, because that seems > like a recipe for it never happening. I have heard that they accept patches :) > If you are trying to solve the problem "we cannot see into the logs of > maintainer-built binaries that exist in the archive", I think a better > answer to that would be to stop letting maintainer-built binaries into the > archive, as the release team are already pushing us towards. That way, > we don't have to worry about whether maintainers' build logs and/or test > artifacts would be leaking personal or sensitive information that they > would prefer not to have shared. There are always going to be non-buildd binaries in the archive, since Debian doesn't support autobuilding with non-default build profiles and even if we had that there will likely always be the need for packages to be manually bootstrapped. There is already a (merged?) dak patch for dropping maintainer built binaries after NEW processing, so we are close to completing this. ISTR dropping all (not just NEW) maintainer built binaries by default was decided to be unwanted and the NEW-only approach was preferred. Personally I wanted to drop all maintainer built binaries by default, with perhaps a .changes field for enabling accepting binaries. > I'm reasonably sure that the sbuild configuration is the wrong place > to specify what the artifacts are I think that completely depends on the audiences and which artefacts each of the audiences wants to look at. For some it will be. > If the other groups get a benefit from this too, then that's a welcome > bonus, but I think solving it for individual package maintainers and > ignoring everyone else would be a net improvement. I think that package maintainers are indeed the primary need for this feature but that the other audiences shouldn't be ignored. > Perhaps it would make sense to have a hybrid of what I prototyped, and > something more like substvars: ... > What I definitely want to avoid is a system that requires collecting > the artifacts imperatively rather than declaratively, e.g. converting Sounds good. > I think those are a non-starter: as a maintainer of an individual package, > I do not want to have to ask the Debian sysadmins' permission to collect > test results (or, worse, ask the sbuild maintainer's permission and then > wait 2 years for the change to be in a stable release). I'm saying we want all of the options, not just one of the options. > I think part of being a do-ocracy is that if there isn't an important > reason for a small and usually overworked group to be in a position to > block other people's work, then we should avoid putting extra load on them. I think that working around groups like this often leads to suboptimal designs and a better approach is to get the design right and help those groups do the implementation work, leaving only the deployment to them. Anyway, I'm not in any of the audiences for this feature and I won't be doing any work on it, so I'll leave it up to others to determine the final design and implementation of the flow of build info/artifacts. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part