From: Jonathan Larmour <jifl@ecoscentric.com>
To: Andrew Lunn <andrew.lunn@ascom.ch>
Cc: eCos Maintainers <ecos-maintainers@sources.redhat.com>,
ecos-patches@sources.redhat.com
Subject: Re: Welcome to sources.redhat.com
Date: Tue, 06 Aug 2002 12:17:00 -0000 [thread overview]
Message-ID: <3D5020BA.7020804@ecoscentric.com> (raw)
In-Reply-To: <20020806185528.GE4434@biferten.ma.tech.ascom.ch>
Andrew Lunn wrote:
>>If you don't mind, for the time being, if you write your own patches can
>>you still submit them for approval by any other maintainer anyway rather
>>than going ahead and checking it in and just posting the patch?
>
>
> Should this be to ecos-patches or ecos-maintainers?
ecos-patches.
> A while ago i posted to ecos-patches a patch for the ftp client. Here
> is what i want to commit:
Looks absolutely fine. I saw the ChangeLog in my ecos-patches backlog
which is fine too. There's no time like the present to try committing
yourself :-).
Oh yes, I forgot to say one thing. When you commit, people have different
habits about what the commit message should be. Some people go for the
really minimal approach of just saying what changed in _each_ file. In
that scenario, they normally leave the commit message for the ChangeLog
file empty.
The other way some people do it is by cut'n'pasting your ChangeLog entry
without the banner and using that as the text for _all_ the files, i.e.
yours would be
* src/ftpclient.c: Send "quit" not "quit " to keep some servers
happy.
Also deal with multi line replies correctly
I prefer this approach as it's less work, and when you make a change it
keeps the change "set" together, i.e. you'll see what other files were
involved as part of this change if you do a cvs log.
Gary takes the former approach I believe, although perhaps he has emacs
macros or something to help him which might be why.
Commit log messages are also important as they are what people see in the
ecos-cvs list, which I certainly read, and I'm pretty sure Gary does too.
Yeah, what fun lives we lead ;).
Jifl
--
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
next prev parent reply other threads:[~2002-08-06 19:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020806155646.18120.qmail@sources.redhat.com>
2002-08-06 11:07 ` Jonathan Larmour
2002-08-06 11:55 ` Andrew Lunn
2002-08-06 12:12 ` Gary Thomas
2002-08-06 12:17 ` Jonathan Larmour [this message]
2002-08-06 12:24 ` Gary Thomas
2002-08-06 12:33 ` Jonathan Larmour
2002-08-06 12:41 ` Gary Thomas
2002-08-06 14:53 ` Jonathan Larmour
2002-08-07 1:13 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D5020BA.7020804@ecoscentric.com \
--to=jifl@ecoscentric.com \
--cc=andrew.lunn@ascom.ch \
--cc=ecos-maintainers@sources.redhat.com \
--cc=ecos-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).