On Friday 15 February 2008 07:57:28 John W. Linville wrote: > Greetings, > > Given current discussions, it seems timely to revamp some of the > upstream wireless tree management policies. I'm sure I still won't > be able to please everyone, but maybe I can change who gets to be > unhappy about the process... :-) > > Let's review the current process. The wireless-2.6 tree has a number > of branches, each with a specific use. Most of these are for my own > administrative purposes relating to coping with the processes upstream > from me. These include any "fixes", "upstream", or "pending" branches, > as well as any "master-*" branches. There are also "merged-*" branches > which I maintain to assist me when rebases are necessary. In addition, > there have been topic branches such as "at76" and (formerly) "ath5k". > And there is the "mm-master" branch, which primarily just collects > the topic branches together for testing in -mm. > > The "everything" branch is an integration branch which collects patches > from all the "fixes", "upstream", and "pending" branches as well > as any topic branches. This is the branch I ask developers to use. > The purpose of this branch is to avoid having API-level patches miss > any drivers as well as to avoid any similar conflicts. > > Finally, in the old process the "master" branch always just pointed > at the most recent full or -rc release from Linus. This always seemed > to confuse users looking for the "latest and greatest" wireless bits. > Moreover, all the branches created confusion among both users and > developers. > > The new process shifts from reliance on branches to the use of > several trees. Each tree may have some placeholder branches used for > administrative purposes, but the interesting bits will be committed > on the "master" branches of those trees to avoid confusion about > which tree normal people should use. > > The wireless-2.6 tree will primarily become a vehicle for pushing > patches to the current -rc release. This replaces the former "fixes" > branches. It is my intent that this will not be rebased except in > the most extreme (and unforseen) circumstances. > > A new wireless-2.6.26 tree (or 2.6.x as appropriate in the future) will > be the vehicle for queueing patches to net-2.6.26 (or its successors) > in anticipation of the next merge window. This tree will regularly > be updated to correspond to the current state of net-2.6.26. I will > avoid rebasing this tree as much as possible, but given its dependence > on net-2.6.26 I will be somewhat at Dave's mercy... :-) > > Finally, a new wireless-testing tree will be created to replace the > usage of the former 'everything' branch. This tree will be based > on a current -rc release in hopes avoiding the churn in between > -rc releases. The tree may contain topic branches (e.g. "at76") > as appropriate, as well as picked commits from wireless-2.6 and > wireless-2.6.26. I will attempt to limit rebasing this tree as much as > practical, at the expense of having some ugly history. However, this > tree almost certainly will be rebased from time to time, and you should > expect any patches in this tree to be re-committed in wireless-2.6 > or wireless-2.6.26 before going upstream -- you have been warned! > > I hope that this "covers all the bases" for our various process > needs (merging fixes, queueing for the merge window, integration and > on-going development). Any coments or suggestions you might have > are welcome now. :-) > > So, comments? this might be a stupid question, but which tree do you expect us to base regular development patches on? i basically don't really care when my patches are merged upstream, and i don't know enough about upstream processes to decide that, so i think i'll better leave that decision up to you :) thanks, bruno - 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
