On 10/11/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610102309j6fcf7ed4n74e6af179d21f42b@mail.gmail.com you wrote:
Ok, which leads to the issue of which patches are allowed to be posted here.
Patches against the "official" U-Boot source tree.
And this is where we diverge. Why not? Many other projects do so, the Linux kernel being the most notable example.
Why not? I want to have the information all in one place, and not scattered around in hundrets of unrelated repositories, all in a different state, all with diferent problems and issues to track.
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.
Anyone who asks to merge an out of sync repo should rightly be flamed.
This assumes that the "other" repository is kept in a clean state, but this is usually not the case. What happens is this: somebody starts working in his own repo, and does so for a long time without review on the list. Over time, a lot of problems in his code sneak in. When he finally announces his repo and ask to have it merged into the public tree he says: Ummm, now it's too late, it would be too much work to fix all these issues and to re-do all the checkins
True, but that's not your issue. Flame away when someone posts out of date patches. The holder of the non-mainline tree is responsible to make sure his submissions to mainline are clean.
[remember the case of the missing CHANGELOG entries in Jon's tree - this cannot be fixed afterwards as these have to be done for each checkin].
<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>
Also, I think your contradicting your original statement:
Please do NOT post patches here against code that is not in the official source tree"
Are you saying that patches to non-mainline code is only acceptable if it's are reply to a mainline patch? That seems rather arbitrary to me. What if I have a change that builds on an off-mainline tree; but isn't a bug fix or enhancement. (for instance; I'm working on fdt
Ummm... I don't understand. If it's neither a fix nor an enhancement I see no need for a change at all ;-) And if it's againt someboidy else's tree, then please discuss it with the maintainer of that tree.
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)
support for the 5200; it builds on the fdt support that isn't in mainline, but it isn't a change to it). The off mainline tree is not yet accepted for merging, but I still want to get my changes out there for others to see/comment on.
It's simple: if you cange code that's in the "official" tree, then post patches here. Maybe even patches on top of other patches that have been posted here.
If you are using some other repository, then please discuss this with the maintainer of this other repo. I'm not willing to comment on code which is unknown to me.
But you are not the only person on this list. There are others who are interested.
Surely we can come to a compromise on this. Can we agree on a way to label non-mainline patches so that it is *explicit* that they are not for mainline?
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.
Cheers, g.