From: Magnus <Mag...@ip...> - 2007-11-27 22:05:20
|
On tisdag 27 november 2007, Ping@LinuxWacom wrote: > On Nov 27, 2007 4:04 AM, Ron <ro...@de...> wrote: > > There is no rush, but yes I do think this will save us all time and > > unnecessary rework. Just let me know if/when you'd like me to poke > > some people to fast-track us an alioth group for it. > > Ok, you convinced me. Let's start now. Give me sometime to catch up > with git though. > > Ping I think we need a strategy how different kind of development should be handled. Since we're more or less starting on a clean slate if we're going towards git it could be a good thing to do this now. I can see three main things we need to be able to handle: 1) Main development (master) I'd guess this would be handled as it is now, with tagging and all. 2) Old X-server support Why not actively purge support for older Xserver versions and try to adapt the source to use the available API? I'm not saying that we should only support the latest X.org, but a selected few releases (yes, XFree86 can be one of these releases). If we can keep the old support available but not in master and add corrections for those versions when someone asks for it, it would make the master much cleaner, easier to understand and to test for those who makes patches. A typical example on this is Xorg 7.3/xserver 1.4... It has its issues, and some of these will go away in 1.4.1. Hopefully 1.4 will disappear sooner than Xorg 7.2, so it would be really nice if we could get rid of the workarounds I've been forced to do as soon as we can for that release. 3) Experimental development For example, my work to make the X-driver more hotplug-aware. It's something separate from the main development, but heavily dependent on it (need patches and features introduced in master to be up-to-date). Another thing that should initially be placed here is the additional processes/configuration/whatever that is needed for a proper hotplug support added in Xorg 7.3/Xserver 1.4. I think 1) and 2) are easy to support with git, but I don't know how 3) is best handled. I haven't done anything advanced with git so I don't know if keeping one or several repos for 3) is the best. Cheers Magnus |