[asterisk-dev] autoconf_and_menuselect branch

[Kevin P. Fleming]

Andrey S. Pankov wrote:

> Kevin, why do you close autoconf related bugs on the
> asterisk bugtracker and ask me to contact one of its
> developer directly, but when I contact you directly
> you wrote me about "following the rules"?

Because we don't work on projects in closed environments like private
email. Especially when there are two or more developers working on a
branch, it's far better for discussions related to that branch to happen
on this list or on IRC, where everyone can participate.

> I was kindly informed about architecural freeze on Friday
> last week, but as we can see it didn't happen.

Yes it did. Anything 'architectural' in nature that was submitted after
that date will not be merged for 1.4.

> Closing reports on the bugtracker with "will never happen"
> is very informative. Let me ask why this will never happen.
> Why HTTP support should be in the core for example? Because
> this is Mark who made decision on this? Not sure here...

The bug tracker is not a discussion forum. The mailing lists are
discussion forums. The bug tracker is for reporting bugs (not
configuration problems, questions about the code or similar things) and
posting enhancement patches.

> Let me stress again on the necessity of the roadmap for 1.4
> release. What chages are planned to be integrated? T.38
> passthrough support? Autotools support? We need to
> elaborate the must have list for 1.4 and it should not be
> released unless every item in the list is marked DONE.

Your opinion would carry more weight with the community if you had been
a long-standing contributing member (as you can see by the lack of
responses to your original post). We frequently have people join the
community and start complaining about things they don't like, even
though the rest of the community is well aware of what needs to change
and is working towards those goals. The processes do not change
overnight, and we need all the help we can get ensuring that code that
is submitted is correct, sane and supportable.

There is not an official roadmap for 1.4, but after the 1.4 release we
(including the newly formed Asterisk Advisory Council) will begin
setting a roadmap for what we desire to have in each major release.
However, given that much of the Asterisk code changes from volunteers, a
roadmap is no guarantee that _anything_ will get done, unless there are
people who will commit the resources to get those features/changes
implemented and tested. Just like every other open source project, our
'roadmap' will be a list of goals, but if the time comes to make a
release and an item on that list has not been achieved, it does not make
sense to hold up the release of all the other improvements because of
it. Given a relatively short release cycle of six months, the worst case
scenario for a new major feature to appear in a release is less than a
year (assuming the code gets into a mergeable state during that period,
of course).