CGL 5.0 - Git

[greg@xxxxxxxxx (Greg KH)]

On Mon, May 19, 2008 at 04:03:48PM +0200, Florian Heigl wrote:
> Hi,
> 
> as far as I can tell the carrier gaps document is far from complete in it's
> current state.  furthermore the precise process accounting patch is
> iirc a test on how to actually get the community convinced to commit
> something the CGL group needs, thus the extensive documentation. As I
> just lurk the CGL lists I dont know if it even was submitted to
> undertake that "test". if I recall correctly it had generated some
> attention but that seemed to have worn off.

The last version of the patch was for 2.6.18, two years ago.  That
doesn't lend itself to getting accepted.  You have to actually try to do
it...

> But in total there's probably still quite a few patches left.
> kexec/kdump/netdump all being mainlined by now the first thing I
> remember out of my head would be EVLOG which didn't get included
> because neither the posix draft standard nor the posts to lkml by
> telco admins or it's make as a plugin log mechanism were convincing
> enough to some people who thought structured logging must be bad. (ok,
> trust me I do hate AIX structured error logs, but anyway.)

No, that's not why EVLOG faild, the authors were told exactly what to do
with it, everyone agreed, and then they disappeared.  So a total lack of
follow-through by the authors is not a failure on the kernel
maintainer's part to accept the patch, it's a failure on the developer's
part.

> another thing might be forced umount with process structure tear down and
> this stuff.

I think that might be in there already.

> someone from montavista could probably list the things where they changed
> "panic" into "kill offending process" and in general I'd say it would
> be great if the CGL docs came back to the level of detail they use to
> have.

You mean the "we must have this patch!" type detail?  That was changed
for a good reason.  We want to see the gaps and reasons for proposing
things.  Otherwise it will "fail" just like it has in the past.

> on the other hand they used to have this and many, many of those patches
> they used were submitted to the linux community and i think a notable
> number didnt see inclusion not for code quality reasons but simply for
> being out of the ordinary.

No, we take "out of the ordinary" stuff into the kernel every day.
There were other reasons (code quality, lack of explaination as to why,
etc.)

> maybe it would help if the CGL current members pick some person who
> reevaluates all "useful" patches and then someone should go through
> them one by one and sort them, and eventually re-submit.

Having the developer who created the patch, and who is going to maintain
it, is best to do the submission.  Otherwise some other person can't
answer the questions and queries very well.

> one note:
> when I still tried to apply all the CGL patches that were relevant to my
> non-telco system I DEFINITELY wished for a GIT tree with a working,
> even if older, version.  Probably this would also help with
> identifying the patches that need to be revisited for cleanly applying
> to the current upstream.

I suggest you look into using 'quilt' it works very well for this kind
of thing.

thanks,

greg k-h