
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.
But on the other hand, I think it makes no sense if we start posting patches here that are against N private repositories somewhere else.
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.
The whole point of git is that we *can* develop features off of mainline in N private repos and easily merge them back in when they are ready. The off-mainline work needs peer-review just as much as patches for mainline (especially when they're my patches). As you agree, patches to the mailing list is the easiest way to discuss changes, but they don't always directly map to an increment to another patch. Once the off-mainline tree is ready, a patch can easily be generated that describes the sum of changes. Individual commits don't matter, only the sum of commits (for a single off-mainline tree).
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 [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].
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.
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.
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.
Best regards,
Wolfgang Denk