In message 528646bc0610110830k7f29ab8jf319886dfa98683b@mail.gmail.com you wrote:
Who's talking about hundreds of unrelated repositories? We're talking about a handful of *related* repositories. Plus, it must be understood that if anyone uses a non-mainline tree, it is *their* responsibility to keep that repo up to date.
Agreed. Will they also take responsibility to answer related questions here on the list?
<digress>Why are you so concerned with a manual CHANGELOG file? Isn't that part of the reason to use a good scm? Updating the Changelog by hand is just busywork when the tool will generate changelog information for you.</digress>
Many of the users (at least many of those I have to deal with) don't use any SCM, at least not to work with the U-Boot code. Many of them just download a snapshot, typically a tarball from the FTP server.
The CHANGELOG file is important for such users to know what's there; I"m usually happy if they know how to run "diff" against two versions of that file to see what was changed :-( For me it's also important as I've seen quite a number of situations where the CHANGELOG file was the only way to reliably identify which exact version a (modified) tree was branched off.
I agree that we don't need it as long as everybody has an intact repository available. Unfortunately this is not always the case. At least not with the people I have to deal with :-(
Finally, I find it much faster to grep in the CHANGELOG than to run "git log" and search in the output.
Maybe there is a clever way to auto-generate the CHANGELOG from the commit message; I tried this once and failed. Ummm... just tried again and found that it's actually working when I use git-commit; however, it seems that cg-commit does not run the pre-commit hook. Maybe a cogito issue. I'll ask...
Which is what I want to do. What I'm hearing from you is that I am not welcome to do so on this list. I respect the fact that you are the maintainer of this list, and therefore can choose the list policies. However, I do think you are being short sighted in not welcoming discussion that is indirectly related to mainline (ie. under development, not ready for integration)
I understand your argument. But I'd rather have that we were all able to see the code we're discussing without need to clone another repository and to analyze what they changed and why, and which parts of this are intended for mainstream and which not, and which parts are ready or incomplete or under work. It's like the netiquette rules for quoting when replying to a message: it gives you some context. With a repo somewhere else it's IMHO more difficult to get such context than when you can reply to a message with a patch included and simply quote the relevant parts of that patch.
Maybe I'm not flexible enough, but I'd really prefer if the patches we're discussing have been posted to this list before.
But you are not the only person on this list. There are others who are interested.
You are right. Maybe we should just try how it works.
If the patches that lead to this "non-mainline" tree have not been posted here before, I don't want to see discussion of this "non-mainline" tree here either.
Thank you for making your position clear. I think your position is unreasonable and short sited, but this is your list and I will respect how you want to run it.
No, this is actually not what I want. I'm interested to reach some agreement we all can live with. If you (and others?) think my position is unreasonable I would at least like to understand why. I don't promise to change my mind ;-), but I do promise to seriously consider your arguments.
git makes it easy to generate and send patches, so what's wrong with asking that such patches have been posted here? At least this makes clear what this specific patch is intended for.
Also, it makes sure this stuff is archived somewhere. Such external repositories tend to disappear without notice, and I would like to be able to track down history any time later.
Best regards,
Wolfgang Denk