On Oct 13, 2009, at 13:16, Keith Packard wrote:
Excerpts from Jeremy Huddleston's message of Tue Oct 13 12:59:19 -0700 2009:Hi Keith, Can you please pull these two commits into master: 6980f77892e0409b44bd8f33ba82e7273c6462a4 7e178ffbed7c8557faf8d471ad275aa2b0365e1dI'm still waiting on Peter's "best git practices" documentation beforemaking my apple feature tree.In general, I think the idea was that patches be merged to master, tested there, and then pulled back to the version branches. Is there some reason you're doing this kind of development and testing on the 1.7 branch instead of from master? Are you finding master too unstable to be used for this kind of development?
No, I actually tested these on master and am living on master...but since I can't commit to master by policy (merge to master from feature branches), and I don't have an apple feature branch tracking master (since I'm waiting for Peter's documentation on the best practices for that), the only place I could put them in git for you was on my 1.7 branch... but I assure you I'm actually using them on master myself.
As we work on refining our source management policies, it would be useful to get feedback on how things are working for developers and maintainers. Ideally, I'd like to see you maintaining a branch or repository off of the master X server branch and be I'd merging rather than cherry-picking patches to master.
Yeah, that's what I want as well, but I'm waiting for Peter's "best practices" wiki page to figure out the best way to do that since our 1.6 feature branch is not that clean.
With my feature branch off of 1.6 (xorg-server-1.6-apple), we ran into a bit of a headache as server-1.6-branch diverged a bit... it is non- trivial to provide incremental patches from 1.6.5 to 1.6.5-apple1 at this point because we've been doing "svn merge origin/server-1.6- branch" into xorg-server-1.6-apple along the way. Rebasing rather than merging would make it easier to generate incremental patches, but that is "bad" for people tracking your branch since they can't fast- forward.
--Jeremy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
