Re: Welcome to sources.redhat.com

Re: Welcome to sources.redhat.com

[Jonathan Larmour]

Ladies and Gentleman, please welcome Andrew Lunn as a new eCos maintainer :-).

For those on the DCN list, if there are eCos maintainership issues, please 
direct them to ecos-maintainers@sources.redhat.com as DCN =/= 
ecos-maintainers now. ecos-maintainers is a publically archived list, 
note: http://sources.redhat.com/ml/ecos-maintainers

root@sources.redhat.com wrote:
> Your account is now active, the login name is asl@sources.redhat.com.
[snip]

So now you're ready :-). As the message says you don't have shell access, 
just enough access that you can set your CVSROOT as it describes and do a 
checkout. Shell access is only required for those who need to be able to 
put things up for FTP.

What you'll want to do now is find somewhere with lots of disk space and 
get a sourceware checkout with that CVS setup. Or if you prefer, run a sed 
script over an existing CVS checkout, like:

for i in `find . -type f -path \*/CVS/Root -print` ; do
   echo ":ext:asl@sources.redhat.com:/cvs/ecos" > $i
done

You should also probably do a checkout of "htdocs". These are the 
webpages. This will also eat disk space as there's some old stuff there 
that should be tidied up really.

So hopefully you'll be able to get all that working, and can set about 
doing, um, whatever :-). Just helping - whatever you are prepared to do!

There's a few procedure-y things that occur to me though, and it's 
probably good for these types of things to go in the list archive. Sorry 
if some of these are completely bloody obvious, but I'm just being 
thorough for the archive if nothing else! :-)

In general, all patches go to the ecos-patches list for approval before 
they are committed. Because us existing lot are a clique :-) we prefer to 
go ahead and commit our changes in general (unless they are particularly 
tricky/complex), but still post what was committed to ecos-patches.

There isn't any official ownership of areas of code as such (yet), except 
that if an area was originally written by someone and the patch is 
non-trivial they should probably be consulted in preference to any other 
maintainer (CC'ing direct is best since a lot of people, me included, 
don't always notice our names in lights). Certainly changes in some tricky 
areas like kernel innards should always be discussed before they are 
committed no matter how good they look, but I'm sure I'm just telling a 
granny to suck eggs here, as this is just good practice anywhere :-).

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? This 
doesn't apply to trivial patches though. I heard a good definition of a 
trivial patch as a patch that the most sadistic reviewer you know would 
still have no grounds of objecting to :-). The most extremely trivial 
patches sometimes don't even deserve a ChangeLog entry or patch to 
ecos-patches, but err on the side of caution for now. Otherwise, all 
changes should have a ChangeLog entry.

But don't worry too much about all this procedure stuff, as long as what 
you've actually committed is on ecos-patches it shouldn't be too difficult 
to unpick if absolutely required :-).

Most contributed patches need fixing in some way before they are applied. 
Things that frequently need doing are missing ChangeLog files, missing 
ChangeLog entries, badly applying patches (due to e-mail corruption, or 
repository conflicts, although the latter will be easier now that there's 
no red hat/public repository schism to deal with), Author/Contributor 
fields in headers that aren't true. Descriptions in each file that aren't 
correct, especially if copied from a different package. CDL option default 
values set to be enabled when the option is actually esoteric and only on 
because that's what the submitter wanted for themselves, rather than 
what's useful for everybody else. Generally you have to go through each 
contribution file by file :-|. There's only a few particularly large 
contributions where that's just too onerous and I just give up :-).

Believe me, it's rarely the case a patch just applies! And then when it 
does, there are frequently plenty of broken things about it. So that means 
actually reading the patch and doing your best to understand it. Sometimes 
it's just a question of trust, but it's worth asking for clarification 
from the submitter to be sure the change is correct. It's not the first 
time people have submitted changes to architecture HALs that are correct 
for _their_ platform, and the previous setup wasn't wrong, it's just that 
it didn't apply to their platform.

Or indeed there are other correctness issues with patches, like if they 
did "fix" changes like that by adding lots of #ifdef MYPLATFORM/#else 
.../#endif stuff. That doesn't scale and we've gone to a lot of effort in 
many places to prevent or remove that type of stuff (although there's a 
few left), and unless it really is a one-off, CDL interfaces are the 
proper way to do it. In that case you either have to implement it that way 
yourself for them (and I've done that plenty of times) or bounce the patch 
back to the submitter and ask them to fix it accordingly.

A more recent issue is that contributions based on older code will tend to 
have the RHEPL. That needs to be changed to the new licence. I have a 
script that can fairly automatically do that - just ask me for it when you 
need it.

Don't be afraid to reject a patch because it'll be too much work for you 
to fix. Just bounce it back to the author. Also not all patches make sense 
"strategically". Just because someone has contributed something doesn't 
mean it's actually a sensible thing to include, especially if our 
strategic direction is some other way, or if it would have future 
maintenance overhead, especially if we'd want to obsolete it with 
something else. Or if it's just bloat, especially if they haven't made it 
configurable with a CDL option.

If you make non-trivial changes to a contributed patch before actually 
committing it, it's worth reposting your new diff to ecos-patches. There's 
  no need if it is just things like adding ChangeLog files, or changing 
RHEPL->GPL etc. - those aren't interesting :-). It's if you make 
non-trivial technical changes that's all.

Patches over about <hand wave>two screens of actual changes</hand wave> 
need a copyright assignment. For now those should be to Red Hat, although 
for our own changes as maintainers, we will add our own copyright, e.g. 
you may well have seen (C) 2002 Gary Thomas in some places. We're going 
through the motions of arranging for another body to handle our 
assignments and in due course us maintainers will do a retrospective 
assignment for all those changes to that body to keep everything neat. 
More of this a bit later.

If you're not sure whether a patch is too big to accept without an 
assignment, just ask. We've been doing a lot of discussion in private 
before, but with you on board, that will change.

Any significant contributions warrant a mention on 
http://sources.redhat.com/ecos/contrib.html, which you can access as 
htdocs/contrib.html in your checkout although if you prefer I can keep 
doing this if you let me know of ones to be added. That page needs to be 
completely overhauled eventually I know.

Phew. I think that'll do - I got a bit carried away :-). Let me know if 
you have any questions or if I've missed something!

Jifl
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Welcome to sources.redhat.com

[Andrew Lunn]

> 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? 

A while ago i posted to ecos-patches a patch for the ftp client. Here
is what i want to commit:

Index: ftpclient.c
===================================================================
RCS file: /cvs/ecos/ecos-opt/net/net/ftpclient/current/src/ftpclient.c,v
retrieving revision 1.4
diff -c -u -r1.4 ftpclient.c
--- ftpclient.c	23 May 2002 23:08:04 -0000	1.4
+++ ftpclient.c	6 Aug 2002 18:48:09 -0000
@@ -9,6 +9,7 @@
 // -------------------------------------------
 // This file is part of eCos, the Embedded Configurable Operating System.
 // Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
+// Copyright (C) 2002 Andrew Lunn.
 //
 // eCos is free software; you can redistribute it and/or modify it under
 // the terms of the GNU General Public License as published by the Free
@@ -54,6 +55,7 @@
 
 #include <network.h>
 #include <stdio.h>
+#include <stdlib.h>
 #include <sys/socket.h>
 #include <netinet/in.h>
 #include <arpa/inet.h>
@@ -128,7 +130,9 @@
   char buf[BUFSIZ];
   int more = 0;
   int ret;
-
+  int first_line=1;
+  int code=0;
+  
   do {
     
     if ((ret=get_line(s,buf,sizeof(buf),ftp_printf)) < 0) {
@@ -137,7 +141,19 @@
     
     ftp_printf(0,"FTP: %s\n",buf);
     
-    more = (buf[3] == '-'); 
+    if (first_line) {
+      code = strtoul(buf,NULL,0);
+      first_line=0;
+      more = (buf[3] == '-');
+    } else {
+      if (isdigit(buf[0]) && isdigit(buf[1]) && isdigit(buf[2]) &&
+          (code == strtoul(buf,NULL,0)) && 
+          buf[3]==' ') {
+        more=0;
+      } else {
+        more =1;
+      }
+    }
   } while (more);
 
   return (buf[0] - '0');
@@ -461,7 +477,7 @@
   
   int ret;
   
-  ret = command("QUIT","",s,msgbuf,msgbuflen,ftp_printf);
+  ret = command("QUIT",NULL,s,msgbuf,msgbuflen,ftp_printf);
   if (ret < 0) {
     return (ret);
   }

Re: Welcome to sources.redhat.com

[Gary Thomas]

On Tue, 2002-08-06 at 12:55, 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? 
> 

I'd say to ecos-patches.

> A while ago i posted to ecos-patches a patch for the ftp client. Here
> is what i want to commit:

What's the purpose of the change?  What about a ChangeLog entry?

Re: Welcome to sources.redhat.com

[Jonathan Larmour]

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

Re: Welcome to sources.redhat.com

[Gary Thomas]

On Tue, 2002-08-06 at 13:17, Jonathan Larmour wrote:

> 
> 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 ;).

I *do* have emacs macros which help with this.

What I try and do is explain the change in the ChangeLog (I have scripts
which automate this as well) and then just a high-level synopsis of the
change(s) when I commit (again scripted).

Of course, the way it's done is always pretty subjective - kinda like
what editor or MUA you swear by :-)

Re: Welcome to sources.redhat.com

[Jonathan Larmour]

Gary Thomas wrote:
> On Tue, 2002-08-06 at 13:17, Jonathan Larmour wrote:
> 
> 
>>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 ;).
> 
> 
> I *do* have emacs macros which help with this.

Okay, can you indulge me with a peek? :-).

> Of course, the way it's done is always pretty subjective - kinda like
> what editor or MUA you swear by :-)

Quite! I'm still quite attached to the "change set" principle myself, but 
I'm not too bothered really.

Jifl
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Welcome to sources.redhat.com

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On Tue, 2002-08-06 at 13:33, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > On Tue, 2002-08-06 at 13:17, Jonathan Larmour wrote:
> > 
> > 
> >>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 ;).
> > 
> > 
> > I *do* have emacs macros which help with this.
> 
> Okay, can you indulge me with a peek? :-).
> 

Here's what I have in my .emacs file:

    (require 'add-log)
    (global-set-key "\C-x4a" 'add-change-log-entry)
    ;; (defun user-mail-address () "gthomas@redhat.com")
    (defun user-mail-address () "gary@chez-thomas.org")
    (defun user-full-name () "Gary Thomas")

Then, to make a ChangeLog entry, I just go to the file/function where
the change was made, type ^X-4-a and it finds the appropriate ChangeLog
file, makes the basic entry and I just fill in the details.

What I normally do is to run a script to see what I've changed 
(cvs-patch), then run another script which runs emacs on all of the 
changed files so I can update the ChangeLog (do_ChangeLogs).  Then run 
the (cvs-patch) script one more time and commit.


[-- Attachment #2: cvs-patch --]
[-- Type: text/x-sh, Size: 150 bytes --]

#! /bin/sh

#cvs -q diff $* | FixPatch | tee /work/diffs
#cvs -q diff $* | FixPatch | no_srec >/work/diffs
cvs -q diff $* | no_srec >/work/diffs

[-- Attachment #3: do_ChangeLogs --]
[-- Type: text/x-sh, Size: 222 bytes --]

#! /bin/sh

#grep Index $1 | sed -e "s/Index: //" | xargs -n1 xemacs $1
grep Index: /work/diffs | grep -v "%redact" | grep -v ChangeLog | grep -v .Sanitize | sed -e "s/Index: //" | xargs -n1 ${CVSEDITOR} /work/diffs

Re: Welcome to sources.redhat.com

[Jonathan Larmour]

Gary Thomas wrote:
> On Tue, 2002-08-06 at 13:33, Jonathan Larmour wrote:
>>
>>Okay, can you indulge me with a peek? :-).
> 
> Here's what I have in my .emacs file:
> 
>     (require 'add-log)
>     (global-set-key "\C-x4a" 'add-change-log-entry)
>     ;; (defun user-mail-address () "gthomas@redhat.com")
>     (defun user-mail-address () "gary@chez-thomas.org")
>     (defun user-full-name () "Gary Thomas")
> 
> Then, to make a ChangeLog entry, I just go to the file/function where
> the change was made, type ^X-4-a and it finds the appropriate ChangeLog
> file, makes the basic entry and I just fill in the details.

Ah, I already have that. I was hoping there was some sort of magic that 
extracted the info from the ChangeLog entry or something :-).

Jifl
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Welcome to sources.redhat.com

[Andrew Lunn]

> I heard a good definition of a trivial patch as a patch that the
> most sadistic reviewer you know would still have no grounds of
> objecting to :-). The most extremely trivial patches sometimes don't
> even deserve a ChangeLog entry or patch to ecos-patches, but err on
> the side of caution for now. Otherwise, all changes should have a
> ChangeLog entry.

As you all know, my spelling/English is terrible. Please feel free to
correct ChangeLog entries, comments, etc. I have no problems with
this. Being dyslexic, i don't notice my errors. Such changes i think
fall into the trivial category. 

     Andrew