Re: [hylafax-users] [hylafax-devel] Re: new community site

["Darren Nickerson" <darren.nickerson@xxxxxxxx>]

> Just chipping in once more :) I have also been away from the lists
> for a while, but I do seem to remember that Darren said the
> sub-release/fork, (or whatever terminology you prefer to use), for
> cutting edge testing and enhancement releases, free from the
> constraints of stable and cvs versions, were neither required nor
> economically worth the effort. That, by the way, is my interpretation
> of what Darren said, just highly condensed :)

I think you have misrepresented me just a bit there. During the transition 
from 4.1.x to 4.2.x, myself and others actually lobbied the -devel list to 
support two 'recommended' releases of HylaFAX. Previously we had only had 
'one true release' of HylaFAX, and were in a bit of a pickle. Some of us 
felt that 4.2.0 had so much new stuff in it (a good thing), had broken 
backwards compatibility in a few ways that might surprise/challenge 
upgraders, and was so young still, that we should at least offer an option 
for people who had integrated 4.1.x deeply into their setups and didn't feel 
ready to take the leap. The concensus that fairly quickly emerged was that 
all new work would be aggressively pursued in 4.2.x, and that 4.1.x would 
become a dead-end 'maintenance release', with only bug fixes being 
backported. Please refer to:

http://thread.gmane.org/gmane.comp.telephony.fax.hylafax.devel/1164

and possibly other discussions around that time.

I really don't see how you can condense that into what you claim I was 
saying (above). If it's not too much trouble, since you have claim to be 
paraphrasing me, can you reference the discussion or discussions from which 
you concluded that? That seems only fair ...

Perhaps you're talking about a later discussion, once 4.2.x was more mature 
... I think I personally do favor a single release now that things have 
settled down and there's not so much deep fundamental reworking of (for 
instance) the Class 1 driver, but really it's not about what I personally 
favor. If the majority of people agreed that a new direction was best, and 
they agreed on what that new direction was, that's the way development would 
proceed! If the majority of people wanted to revise the release process to 
somehow speed it up while still keeping the same fundemental steps of beta, 
release candidate, release, then hylafax-devel is the place for that 
discussion and again, all it takes is for the people there to agree to 
change, agree what form the change should take, and it would happen. 
Democracy can sometimes be hard work and messy, and often takes more time 
than some may feel it's worth, but so far it has worked out ok.

> In my personal opinion, this was pretty much the only option,
> (although a straight fork with different logo/name might have been
> preferable), that people had for obtaining a non politically enmeshed
> version of HylaFAX. I would also have to say that the democratic
> model Darren keeps mentioning does appear to be very biased in one
> direction more than others. ( No offence meant :).

I invite you, and anyone else who has a concern about whether HylaFAX 
development has been democratic to review the discussions that have been had 
over the years at 
http://news.gmane.org/gmane.comp.telephony.fax.hylafax.devel. If you see a 
case, or cases, where you think the principle of 'rough concensus' was not 
followed, please send me the URL of the discussion thread. If in fact the 
views of the majority were not followed, then there has been an error and 
that should be addressed, if at all possible. I can't claim that the process 
is perfect, but I cannot recollect one case where concensus was reached and 
the decision was not followed.

-Darren 


____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*