[asterisk-dev] [Code Review]: Move unsupported modules to their own directory

[Paul Belanger]

> On April 14, 2011, 2:46 p.m., Leif Madsen wrote:
> > After additional discussion on IRC with russell and kpfleming, a different approach (which is less intrusive to those building packages) has been proposed. I've created a wiki page which outlines the proposed approach. Any comments are welcome.
> > 
> > https://wiki.asterisk.org/wiki/display/~lmadsen/Asterisk+Module+Support+States
> 
> ZX81 wrote:
>     Can you either add a list of modules which will change state there or here?
>     
>     Also, what would be required to keep those modules "maintained"?
>     
>     I use app_amd and func_db quite a bit and would like to see them stay :-)  
>     
>     I guess I'm a little concerned about the eventual removal of unsupported modules
> 
> Leif Madsen wrote:
>     There is a comment earlier with a list of modules.
>     
>     app_amd support is not being changed per a comment earlier.
>     
>     func_db is not on that list (app_db is, which has already been deprecated in favour of func_db for quite some time).
> 
> Paul Belanger wrote:
>     +1, a few comments.
>     
>     Ideally the path for modules should be: Maintained -> Deprecated -> Unmaintained-> Removal, this would be the best case scenario.  Since Deprecated implies a replacement module is available.
>     
>     However, Maintained -> Unmaintained-> Removal maybe hard to swallow for people, since we would be removing functionality without a replacement. How we determine this process may also require work.  For example, app_amd was on a previous list for removal, but has already found members of the community to help maintain it.  So, is that the criteria to keep a module? Do we go to the develops list for votes?  I guess what I'm saying is we _should_ be really sure of a module before moving down this path.  Additionally, regardless of what we decided people are not going to be happy.
> 
> Russell Bryant wrote:
>     I do think we should add a list of modules to the wiki page.  I wanted to start by identifying the policy framework.  I'm pretty happy with the direction of the proposal so far.  Now I'd like to see a proposed list for each of the categories and have a chance to approve it and add input as necessary.  Perhaps Leif and I should go off and work together on a list and come back with it.
>     
>     I really don't want anyone to get scared over this.  I think the list of what modules get categorized as "unmaintained" will be short and unsurprising.  Please nobody freak out until we have an official list.  :-)
>     
>     Regarding Paul's concern about removing something without a replacement, I think it's a concern that will never happen in practice.  If that actually happens, it's going to be something people don't care about.  If people care about a feature, there will be people around to help maintain it.  Our community is big enough that that is just the way it happens in practice.

Are we still planning on moving modules?  Or can this review be closed?


- Paul


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1181/#review3364
-----------------------------------------------------------


On April 13, 2011, 3:42 p.m., Leif Madsen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1181/
> -----------------------------------------------------------
> 
> (Updated April 13, 2011, 3:42 p.m.)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> As Asterisk continues to grow, not every modules receives the same amount of love, and some modules receive no love at all. In order to make it more obvious for users which modules are deprecated or unsupported, I've modified menuselect to show modules in their own menu called "Unsupported Modules". This way as things are deprecated, or they no longer have a reasonable level of support, then they can be moved into this directory.
> 
> For modules that get moved here, but someone comes along to support the module, it can of course be moved back to a sub-menu where supported modules live.
> 
> 
> This addresses bug 19117.
>     https://issues.asterisk.org/jira/browse/19117
> 
> 
> Diffs
> -----
> 
>   trunk/Makefile 313699 
>   trunk/addons/Makefile 313699 
>   trunk/addons/app_mysql.c 313699 
>   trunk/addons/app_saycountpl.c 313699 
>   trunk/addons/cdr_mysql.c 313699 
>   trunk/apps/app_dahdibarge.c 313699 
>   trunk/apps/app_db.c 313699 
>   trunk/apps/app_macro.c 313699 
>   trunk/apps/app_readfile.c 313699 
>   trunk/apps/app_setcallerid.c 313699 
>   trunk/channels/chan_h323.c 313699 
>   trunk/configure UNKNOWN 
>   trunk/include/asterisk/autoconfig.h.in 313699 
>   trunk/unsupported/Makefile PRE-CREATION 
>   trunk/unsupported/app_dahdibarge.c PRE-CREATION 
>   trunk/unsupported/app_db.c PRE-CREATION 
>   trunk/unsupported/app_macro.c PRE-CREATION 
>   trunk/unsupported/app_readfile.c PRE-CREATION 
>   trunk/unsupported/app_setcallerid.c PRE-CREATION 
>   trunk/unsupported/chan_h323.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/1181/diff
> 
> 
> Testing
> -------
> 
> Ran ./configure && make menuselect
> 
> I then selected a couple of modules from the directory. After running 'make' I verified only the modules I selected built. Everything looks as it should.
> 
> 
> Thanks,
> 
> Leif
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110911/f0bddcaa/attachment-0001.htm>