Hi Willy,
Thank you for clearing this up for me.
I now understand the direction that you are wanting to take more clearly
now.
I just wish that I could help more than by just using and reporting, I'm
sure I'll get there though.
~Scott
On 29/07/2014 09:33, Willy Tarreau wrote:
Hi Scott,
On Sun, Jul 27, 2014 at 03:40:10PM +0100, Scott McKeown | redIT wrote:
Anyhow, as you have mentioned that its really the community that is
helping drive the developement forward, how about some form of online
vote system to help find out what the community would most like to have
added to the next release and this could then be the main target of the
next stable release.
It already exists, it's the mailing list! Development is not based on a
vote but on *real* efforts, and the best way to have a feature implemented
is to contribute it. When you cannot contribute it, you at least need to
explain your needs on the list so that they can be discussed and tailored
to something implementable. In fact, this has worked for years so I firmly
believe this will continue to work. Also, as I mentionned, I don't want a
release to depend on an advertise feature set anymore, so that's one more
reason for having things done in parallel and as contributions.
For example Open a vote for one month before all major development
begins with say four items that are realisticly possible for adding into
v1.6 after the month the one with the most becomes the main development
focus for this release.
We really never know. Server-side keep-alive was realistic for 6-months
after 1.4, and digging into it constantly proved more difficult with a
very long trail of dependencies. So I don't want to bet anymore on ETAs
for certain features. We have many examples like this, of things we have
been forced to drop or at least delay so that we could perform deeper
changes that were needed.
I'm not saying that other things can't and
shouldn't be added that would just be silly but this way us out here get
what we think we really need and we continue to have a reliable and
stable development process.
There's another point I forgot to mention : despite a number of companies
contributing to the project, most initiatives are done on a voluntary basis
by enthousiasts on their spare time. Most of them have no idea how long it
can take to implement something nor how much spare time they have to work
on it. We *cannot* and *must not* wait for people's work to be completed
before a release, and they must not feel bad for missing a deadline. That's
the benefit of a merge window : if your code is not in good enough shape
for version N, no rush, continue at your rhythm, you'll push it for N+1 a
few months later.
This process ensures that what people want actually is what will eventually
get merged. Large companies can hire developers to get their features done
quickly, and other users can take their time, nobody is waiting for them to
finish.
Best regards,
Willy
