Re: [Audacity-devel] Modular Architecture Initiative

[Vaughan J. <va...@au...>]

Thanks for all the clarification, James.

James Crook wrote:
> On 02/02/2010 20:26, Vaughan Johnson wrote:
>   
>> Exactly, Leland!
>>
>> James, I very much applaud your initiatives on code review and
>> modularization. But I don't think modularization is a panacea,
>> especially for the moonphase P2's.
>>     
>
> Nor do I.  The motivation for modularisation is to allow us to again add 
> big new features but now without destabilising the core of Audacity.  We 
> can't at the moment.  There have been expressions of dissatisfaction 
> with the long time in bug-fixing mode, and the absence of exciting new 
> features.  I've listened to these.  The risk of destabilising Audacity 
> is one of the reasons cited for not doing GSoC this year.
>
> Code reviews help us with bugs much more directly than modules do.  
> Modules allow us to bring in more people.  I think it is important for 
> Audacity, even vitally important.  I think it is a shame we are not 
> doing GSoC.   
I agree it's a shame, but I agree it's the right decision.


> We have talked about the need for a more modular Audacity 
> for a long time.  Why the upset that I have started an initiative with 
> the intention to actually get there?
>   
No upset. I applauded. Just wanted to understand what that meant 
relative to the agenda for stability. If a modules initiative means 
reworking a lot of the core of Audacity, it could introduce more 
instability -- or potentially less, but it's away from the idea of "keep 
what you've got, no new features, just get all the high-priority bugs 
out" that we've been operating on. But I think it's great that you're 
trying to figure a way to get off that modus operandi and start back to 
making Audacity more exciting.


>   
>> Code review may help on those, and
>> Gale running with Doc Watson,&  whatever else will help identify the
>> problems. These are possible solutions that will gradually improve
>> stability and allow new features, but I question whether they'd really
>> find all the moonphase bugs.
>>
>> I think we should at least discuss the idea of start-from-scratch
>> re-architecting, so we have a clean API, and clean internal structures.
>>    
>>     
>
> Please start such a discussion.
>   
Consider it done, here and now (or yesterday). ;-)

Specifically, I think it could be seen as a necessary first step in the 
modularization initiative. Redesign the core with modules support as one 
of the main goals, along with separation of data, processing, display, 
and user interface functions into separate classes and hierarchies. 
Otherwise, I suspect that as people want to do more ambitious modules, 
we'd run into trouble as Leland described, and have to iteratively 
redesign the modules API many times.



> We need to discuss both technical and social factors.  Why didn't Mezzo 
> take off?  It sounded great in theory and there was some good code 
> written for it.  What can we do next time round to make sure that it does?
>   
I think that was simply because it was mostly Josh's project, and he 
left the team. I think we have a lot of lone wolf development, largely 
because we're spread out around the globe, but it would be interesting 
to try some kind of pairs/team programming.

Btw, I did use Mezzo and complete a bit more of it about a year and a 
half ago , for a client. (Easy stuff, in-memory sequences, code that was 
previously just stubs.) Haven't looked at it in a while, but it may be 
useful.

>   
>> Martyn mentioned this as a possible GSoC project. It's a major effort,
>> but I think a ten-year-old codebase is ripe for such an effort.
>>    
>>     
>
> I agree about a cleaner API, but I think we need more developers or some 
> amazing developer tools if we are to try to start a new Audacity from 
> scratch and maintain existing Audacity at the same time.
>
> --James.
>
>   

True. Not doing GSoC can help. It might be slow going given scant 
resources, but I think the end result will be better if we do that 
before or at least as an early step in the modules initiative.

And it would be so different we could call it Audacity 10 (but not named 
after the year!). :-D

Thanks,
Vaughan