On Wed, Mar 02, 2011 at 11:44:09AM -0800, Ping Cheng wrote: > On Tue, Mar 1, 2011 at 5:55 PM, Peter Hutterer > <[email protected]>wrote: > > > Following up on this, I just bumped the version in git to 0.10.99. > > > > New release versioning scheme until we settle on a stable 1.0: > > - 0.x.99 is the version number in-between releases > > - 0.x.99.901 is the first RC > > - 0.x.99.902 is the second RC > > - 0.x+1.0 is next the release > > > > Any version bump other than to .99 is coupled with a tag and a tarball so > > users and distros can get the newest goodness easily. Note that this is the > > same versioning scheme we use in X.Org, so I'm less likely to get it > > confused ;) > > > > I'm planning for 901 on April 1st (yes, it'll be a hoot!) and then the > > release soon after that, depending on the issues we see with the RCs. > > Either > > way, we'll have a 0.11 release early-April. That's about as precise as I > > can > > plan at this point :) > > > > For the time between 0.10.99.901 and 0.11 I won't merge any intrusive > > patches, only stuff that fixes actual issues. > > > > Any comments or extra requests? > > > > Thank you for sharing the plan ahead of the release. I am fine with the plan > as long as we have a plan. > > I have a question about the definition of "stuff that fixes actual issues".
There's a blurry line as usual, but in general patches that are acceptable are: - documentation updates - typo fixes and other fixes that don't change functionality - patches that fix regressions - patches that fix crashes and build errors Not acceptable: - adding new features - intrusive patches fixing old bugs - UI changes > You know I am still holding the workaround I made for fixing the hotplugging > device enable/disable issue. Before we get a barrier from X server that > tells us we are getting the last configured input device (are you plan to do > that?), we can only work on one device at a time. The X server doesn't really know about it either, at least not in the case of hotplugging. For xorg.conf devices, that information is available (and I think currently even accessible to the driver, though more by accident than intention). Not sure what we can do in the server here, I'll have a look though. > I know if hotplugging is provided through udev, all tools could be added > insider xf86-input-wacom, if all tools are configured with the same options. > What about hotplugging based on HAL? Do we care about that case? HAL-based hotplugging is identical to udev-based hotplugging. the only exception is a HAL-trick we used in linuxwacom to let HAL fake up the devices. we're not using that anymore though, at least not in xf86-input-wacom. for our purposes, HAL and udev are the same (with the exception of a few strcmps) > So, basically, I need to know if you would consider that patch as fixing > actual issues or not. It is not a perfect solution. But, there is not way to > make it perfect without getting help from outside of the driver. It does > narrow the race condition. the problem with that patch was IIRC that it was based on some mistaken assumptions. e.g. the refcounting was working completely different to what you tried to do. so it was more a problem with the patch itself than anything related to the release problem. Cheers, Peter ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
