On Sat, Jan 14, 2012 at 7:59 PM, Charles Plessy <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAC58tq-3gh-NbX1qO+hfv4=erdzgdpgctsgdfhsnghs8ery...@mail.gmail.com
