Greetings, So I'm tired of a) being asked how wireless-testing is managed; and, b) having trouble explaining it. I think it is time to move to a more conventional process for wireless patches. The main change I would like to make for now is to move wireless-2.6 and wireless-next-2.6 to a default "immutable history" policy. By this I mean that I will strive to keep the history both clean and immutable in those trees. If for some reason I can't make that happen and have to rebase those trees, I will make a loud and obvious announcement on the linux-wireless mailing list. More likely, it means I may have to push an occasional revert through those trees that I might have otherwise avoided. One of the ramifications of this will be that I will need to be extra careful about what gets merged into those trees. I have been pushing patches into those trees quickly after merging them into wireless-testing, relying on linux-next to uncover some of the problems a quick review might miss. Now I will need to have higher confidence in a patch before pushing it to wireless-next-2.6 or (especially) wireless-2.6, so some patches may take longer to get there. All of your usual dilligent reviews are most helpful in this regard. For now, the main change to wireless-testing will be that I will be pulling from wireless-2.6 and wireless-next-2.6 rather than reapplying most patches. This should limit (and possibly eliminate) the confusing patch-revert-reapply-repeat practice I have been using there for a long time. However, I still anticipate using w-t as a holding area for questionable patches. So, at least some patches may still get the revert-reapply treatment. I may ask Stephen to pull w-t into linux-next in order to expand testing of any such patches. One advantage to this new process is that it will enable me to more readily accept actual git pull requests from driver/subsystem maintainers. In order for this to work, those maintainers will need to send separate pull requests for fixes intended for the current release and for features intended for the next release. They will also need to maintain their trees appropriately (i.e. separate trees or separate branches with appropriate bases) for this to work. If anyone is interested in doing this, feel free to ask more questions. Well, there is my overview. Anyone have questions/objections/etc? Thanks, John P.S. If you care (and most of you should not), I intend for wireless-2.6 and wireless-next-2.6 to pull from Linus at v2.6.33-rc1 and then only pull from net-2.6 or net-next-2.6 (or wireless-2.6) if necessary for dependencies or conflict resolution. Any driver/subsystem maintainers that want me to pull from them should consider doing something similar. -- John W. Linville Someday the world will need a hero, and you linville@xxxxxxxxxxxxx might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
