[tahoe-dev] darcs patch: ymy name... (and 1 more)

[Arno Waschk]

Hi Brian, thanks for spending so much energy in investigating that patch!
the original idea was once we had humanreadable plugged into that logging  
thing, we could use it to automagically format those nowadays often  
differently printed ids into something nice and consistent. Which we do  
not have yet. Otherwise humanreadable might be helpful for long things to  
come into the log (which you can have now by turning on switches like  
debugNegotiate, e. g., IIRC...
If you prefer a different timestamp like the one you mentioned, that is  
fine for me! I was mainly trying to have the seconds.
the class-level constant thing is ugly, but i did not find something  
better, so i was actually hoping somebody might teach me how to do it  
better ;)
sorry for the complications introduced by emailed patches, they come  
directly out of (my?) darcs. When sending these patches it was usually  
very late and i was very tired, so that seems the easiest and quickest  
(only for me, apparently ?). These trac tickets are nice, but if (like me)  
one is not at all familiar which tickets are already there, and which not,  
and which patch has to go where, it is not an easy thing at all. I might  
become more familiar with tarc's content, so i might change that.
is there a way to configure darcs to send to a specific trac ticket?

yours, arno

Am 14.08.2007, 00:52 Uhr, schrieb Brian Warner <warner at allmydata.com>:

> I guess I'm +0 on the logging changes. The timestamp is harder for me to
> read (although having the seconds included is nice), and I'm not sure I
> see the value of using humanreadable here (do we have existing log
> statements that are too large? I see a lot of comments in
> humanreadable.py which talk about threading, which we don't use)..
> mostly it just seems to add spurious single-quotes to the log output.
> I'm not keen on reaching through to log.FileLogObserver and changing
> class-level constants like that, especially doing it on every single
> log() call, but to be honest I can't think of a better way to accomplish
> the same thing.
>
> The log.callWithContext line is probably more useful if everything uses
> it. At the moment the majority of the log lines are either produced by
> twisted.web internals (and get a prefix of [HTTPChannel,0,127.0.0.1] or
> such), or are in the upload process (and use [Negotiation,client] for
> some reason), so I don't think it helps all that much.
>
> Overall, I don't mind if this one goes in, although I'd prefer a
> timestamp of %Y/%m/%d %H:%M:%S (like the original twisted one but with
> seconds added).
>
> As a meta issue, I find it hard to evaluate patches that show up in
> email. It might just be my MUA (I'm using Thunderbird, when I'd prefer
> to be doing everything inside emacs), but I have to save the attachment
> out and apply it to a tree before I can see a clean list of the
> differences. (Thunderbird doesn't think it knows how to show me the
> attachment itself, and the quoted-printable nature of the darcs patch
> means that 'less' on the saved file is also frustrating).
>
> What do people think about the merits of putting patches as Trac
> attachments? Maybe if we name them darcs1234.diff then trac will display
> them nicely, maybe not.. quoted-printable may bite us regardless. There
> are different kinds of discussions that tend to take place in an email
> thread vs. on a Trac ticket comment list.. at the moment I'm leaning
> towards preferring Trac tickets, but I'd like to hear other opinions.
>
> thanks,
>   -Brian
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev



-- 
http://www.arnowaschk.de
http://arnowaschk.blogspot.com
http://www.xing.com/go/invite/7018920.9c6816