On Wed, Feb 16, 2011 at 7:45 PM, Peter Hutterer <peter.hutte...@who-t.net>wrote:
> Looking back at the release history of xf86-input-wacom 0.10.x, we have the
> following release windows (rough approximations):
> 0.10.1 - baseline
> 0.10.2 ~2 weeks
> 0.10.3 ~3 weeks
> 0.10.4 ~4 weeks
> 0.10.5 ~8 weeks
> 0.10.6 ~6 weeks
> 0.10.7 ~3 weeks
> 0.10.8 ~5 weeks
> 0.10.10 ~19 weeks (ignoring 0.10.9, brown paper bag release)
> 0.10.11 ~13 weeks
>
> so in short, it's all over the place. afaict, the biggest uptakes were
> 0.10.5 and 0.10.8 though that's likely because they long window after
> coincided with distribution releases. However, 19 or 13 weeks are clearly
> to
> long.
> What I'd like to commit to is regular releases. While the misc cleanup is
> still going strong, we can't and shouldn't just line up with X server
> releases. So what I propose is an approcimately monthly release with a
> driver release ever first week of the month.
>
Alining with X server releases can be a factor if the driver is stable. At
this stage, gathering more feedbacks, testing-wise
and functionality-wise, from the community is more important than anything
else. A faster release cycle helps.
However, 4 weeks may be a bit too short. We need time to review and test the
code among developers before pushing the driver to the public. At least, we
don't want to surprise our users too often.
I'd say a 6 to 8-weeks window may fit into our current status more. We can
stop feature support merging at week 6 and let it soak for one or two weeks
before the release.
Ping
> This requires some more discipline, so I'll simply stop merging intrusive
> patches on the 1st of each month and focus on dealbreakers only for a
> couple
> of days. anything else will simply go on -next, which will then be merged
> whenever the previous release is out.
>
> Does that make sense? Is that too often?
>
> The main issue will be if the server's input ABI changes too much during a
> single server release but since I control that part, I can try to make it
> less of an issue :)
>
> Cheers,
> Peter
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Linuxwacom-devel mailing list
> Linuxwacom-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
