[Toybox] new toy : w command

[Rob Landley]

On 07/18/2012 04:09 PM, David Seikel wrote:
> On Wed, 18 Jul 2012 11:40:59 -0700 Tim Bird <tbird20d at gmail.com> wrote:
> 
>> On Wed, Jul 18, 2012 at 6:40 AM, Gaurang Shastri
>> <gmshastri at gmail.com> wrote:
>>> Hi All,
>>>
>>> Please find attached the initial implementation of "w" command.
>>>
>>> Output after compiling my code with toybox :
>>> {{{
>>> [root at 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.

 1342705408.0