Re: Welcome to sources.redhat.com

[Jonathan Larmour <jifl@ecoscentric.com>]

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