On 10/10/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610100013h7a7fd1d3pe66473431000dc28@mail.gmail.com you wrote:
Where then should I take discussion that is directly related to improving the quality of the flattened device tree code held in that tree? Would you really prefer that discussion to be taken off line
No, definitely not. Discussing the stuff here is just fine. Also posting patches here is fine (and the only "official" way for patch submissions so far).
Ok, which leads to the issue of which patches are allowed to be posted here.
and then a full patch set be dumped on the mailing list wholesale?
If this is a clean set of patches this is just fine with me. Actually this is the current "official" way to do it. Even if you provide a git repo for easy merging, you are still required to post the set of patches here on the list so everybody can see and discuss these.
It is MUCH easier to review a patch than analyzing what might have been change in another repo.
Agreed
The fdt support patches are non-trivial. You've already rejected them here. Why do you want to eliminate an effort to improve them from this list?
I definitely don't want to do this.
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.
If you find a problem with the code, then post a follow-up (eventually including an incremental patch) against a patch that was posted here on this mailing list.
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).
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 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.
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?
Cheers, g.