Re: Please re-enable sbuild log filtering for archive rebuilds.
On Sat, Jan 14, 2012 at 7:59 PM, Charles Plessy <plessy@debian.org> wrote:
> Le Sat, Jan 14, 2012 at 07:55:20PM +0100, Bastian Blank a écrit :
>> On Sat, Jan 14, 2012 at 11:54:46PM +0900, Charles Plessy wrote:
>> > The filtering makes my work easier, because it reduces the size of the diffs
>> > without extra action on my side.
>>
>> And why can't you filter the logs on your own?
>
> I can, but I would prefer if it were done automatically. I think that it is a
> general principle that applies to many of our activities in Debian. Sbuild's
> log filtering function, because it exists, saves me the time from
> re-implementing a similar function from scratch, and from maintaining and
> sharing a script.
>
> Because filtering is by default enabled in sbuild, the logs of the packages
> that I upload to the archive, that I either send to the packaging team's list
> or commit in the package's git repository, are filtered logs. I have not
> reveived any complain that filtration was harmful, and I feel that this feature
> has been benefical to me; it assisted me to spot key differences between
> builds. I think that the benefits would be greater if the archive rebuilds
> were also filtering logs, since they use a sbuild version that has that
> capacity.
>
> But all of this can be said to be a matter of preference, so how to chose
> between people's preferences ? I propose the following:
>
> If log filtering does not make somebody's work harder, I humbly request that it
> is enabled.
Without knowing the contents of these logs, or of what's being
filtered from them (I have looked at the bug log mentioned earlier in
this thread), I make the following general observations:
(1) Something computable (e.g. data / information, not something
material) that is of interest to a broad-enough class of people
shouldn't require them all to each, independently and separately, have
to implement the thing, thereby duplicating effort. It obviously
makes much more sense to implement it once, do the work once, and make
the results available to anyone interested in them. (Errr, on second
thought, in *this* specific context that's true. I can think of
potential counter-examples, but for things very different than this
particular context.)
(2) Information or data, once generated, shouldn't be casually
discarded unless there's no other option. This is because it's hard
to know what information or data generated in the past might be of
interest to someone in the future, even tho we cannot imagine now what
use might (or even *could*) be made of it later. If the information
is not made available, that future hypothetical someone might not even
have the inspiration or opportunity to have a "What if ...?" moment.
Further, the information, once discarded, might be hard or even
impossible to recreate, depending on what it is. (I freely admit to
being an information / data pack rat.)
Therefore, I wonder: is it possible, and feasible / practical, to make
both forms of logs available? E.g., make the filtered logs available
for people like Charles, and the unfiltered for people like Jakub? I
realize that if many people each request slightly differently filtered
versions of these logs, *that* would probably not be practical to do.
However, that seems like a separate issue to be worried about at a
future time.
Thanks for your time. Hope this is of some use, interest. Be well.
Joseph
Reply to: