[Asterisk-Dev] Bug Tracker / Feature Requests (my take)
dking at pimpsoft.com
dking at pimpsoft.com
Sat Jan 1 16:31:55 MST 2005
There would be more bugs fixed if Asterisk development was actually
open in the true nature of open source instead of done on a nopay-for-
work-done payscale for digiums benefit with digium owning every
bodys hard work.
I understand that some of the larger open source projects do the same
thing, but they unlike asterisk are actively maintained by certified
non profit organizations with a valid modus operendi that is in
compliance with furthering the open source/free software ideal. That
is there only motivation and making money has nothing to do with it,
unlike Digium since as a company it must make money to survive.
Digium sells the software and is basically a software company much
like Microsoft or Sun is since its business model of selling software
for hardware is basically the same. This turns allot of people away
and hurts the Asterisk Open source development community.
There are more bugs and feature requests because people are limited
from fixing and adding them themselves. Instead of the global
community being able to help as little or as much as they like you
must not only live in a country where american contract and copyright
laws are compatible, you must be willing and have the resources to
give up your rights to your work.
Many people are willing to do that only if they know they are
farthing something bigger then themselves, as is the case with
development of GCC and such projects managed by non profit
organizations that guarantee through there very existence that this
faith will not be abused.
But that's not how Digium does it with asterisk, and its public
knowledge that digium is a for profit company that by definition
wants to make money and not a non profit seeking to better the open
source community.
Due to this your going to see allot of feature and bug requests,
that's the only option people have to help, and it will continue to
be that way until asterisk is moved to a real open source development
model.
Please no flames, I was respectful.
- D
On 1 Jan 2005 at 17:43, Mark Spencer wrote:
> First, let me thank everyone who has been participating in this discussion
> -- and especially I want to thank all the bug marshals who devote so much
> time and energy to trying to manage the very difficult, sometimes tedius
> job, of maintaining the bug tracker.
>
> My intent with this message is to share where I am with my thoughts so
> far.
>
> 1) Clearly the bug tracker is only useful as a resource when it serves the
> the bug placers, the feature requesters, and is serviceable by the bug
> marshals.
>
> 2) The growth of number of people placing bugs is not necessarily in tune
> with those who are servicing the bug tracker.
>
> 3) Most bugs and feature requests are properly handled by the existing
> system, but clearly some things have gotten closed out or lost in some
> circumstances.
>
> 4) The more open tickets there are in the bug tracker, the more difficult
> it becomes for the bug marshals to see through the maze of "going nowhere"
> issues for those that really are ready for some activity.
>
> 5) Feature requests with no attached patches rarely go anywhere, and
> contribute greatly to #4.
>
> 6) As difficult as it is to try to keep up with the bug tracker, it is
> clearly more useful than any other system currently in place with Asterisk
> for the tracking of any issues.
>
> 7) Patches which fix bugs, features which are implemented and bugs which
> do not have patches all require substantial amounts of time and effort to
> get done.
>
> 8) Just because a feature can be done, even if it is supplied with an
> implementation, doesn't mean it should be merged. Patches must be
> consistent with an overall architecture and also mindful of my strong
> preference for "simple"
>
> 9) Maximizing the performance of the bug tracker means to try to solve as
> many bugs and implement as many *logical* features as possible.
>
> 10) Bug marshals are a "scarce resource" compaared to those placing bugs.
>
> 11) Since the system is dependent upon the volunteer effort of bug
> marshals, the first priority is to cater to the needs of current and/or
> future bug marshals. While I certainly value the opinion of those who are
> not bug marshals, I clearly have to prioritize the needs of the "doers" to
> those of the "talkers". Even if we developed the perfect system with
> respect to the bug placer, if there are no bug marshals or too few bug
> marshals to serve it, it cannot operate and serve anybody.
>
> 12) Feature requests can sometimes be augmented by having bounties on
> them. Having a centralized place for feature requests with bounties might
> help get them more visibility and get them translated into features with
> patches.
>
> 13) Some feature requeests, even without patches, are fairly easy to
> implement and can be done fairly quickly.
>
> So, generally I guess, my overall feeling is that the bug tracker should
> primarily be focused around things which are active -- primarily bugs and
> feature requests with patches. It also seems like a good starting place
> for features even without patches in case they're very easy....
>
> At some point though, there needs to be a way to both get them out of the
> way of myself and the other bug marshals when trying to work on higher
> priority bugs and features with patches and retain high S/N. Likewise
> feature requests with bounties should be centralized so that people
> looking to add to asterisk but get a bounty in return can find them
> easily.
>
> Clearly none of this is a specific recommendation or policy, but soon
> after I get back to the states, I'd like to try to come up with something
> that *is* concrete, so please continue your discussion and I hope I've
> added something.
>
> Mark
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-dev
mailing list