On 07/18/2012 04:09 PM, David Seikel wrote: > On Wed, 18 Jul 2012 11:40:59 -0700 Tim Bird <[email protected]> wrote: > >> On Wed, Jul 18, 2012 at 6:40 AM, Gaurang Shastri >> <[email protected]> wrote: >>> Hi All, >>> >>> Please find attached the initial implementation of "w" command. >>> >>> Output after compiling my code with toybox : >>> {{{ >>> [root@stark toybox-0.3.0]# ./toybox w >>> USER TTY LOGIN@ FROM >>> root tty2 Wed Jul 11 18:29:24 2012 ( ) >>> rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109) >>> rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0) >>> rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208) >>> }}} >>> >> >> Here is some feedback: >> >> It is better to provide the patch inline, in the message body, rather >> than as an attachment. This allows people to easily respond to >> individual parts of the patch by commenting directly in a response >> e-mail. Comments can be placed in-line with the submitted code. > > I thought it was generally agreed that attached patches are better > than inlined ones.
The linux-kernel mailing list has a strong preference for inlined patches, due to the volume. Personally pretty happy with both. Inlined patches are easier to reply to, but I find them slightly harder to apply. Various mail clients are insane and break stuff subtly, and when I save them I have to strip out header stuff manually to avoid confusing "patch". Attached patches I can save to a file, open in mousepad, and cut and paste back to the composer window. Takes ~20 seconds. > Inline patches can get mangled to the point where > the patch program fails to actually use them. Attached patches are a > separate item that wont get mangled. Look back in this list you will > see inline patches that had this problem. Having the patch actually > work is more important than the ability to comment on them in place. My preference is actually for "hg export" patches because then they're automatically attributed to the right person and I don't have to come up with a description for them, and I'm not tempted to fiddle with the patch _before_ applying it but do my changes as a separate cleanup pass. But it's not a strong preference. I'd far rather the patch be A) good code, B) copied to the list rather than just me personally. The rest is details. > In my experience with mailing lists where the patch is sent to the list > by the source code management tool, people usually just quote the > entire patch as one big blob when commenting on it. I don't. :) > Even if the patch > is megabytes long, and their response is two or three words. I think I set the mailing list up to have something like a 150k message size limit, but I'd have to go look. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
