Thread: [Audacity-devel] Writing to the developers from the Wiki
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2007-08-28 08:02:50
|
Hi All Recently we have requested in some new development related Wiki pages that users might contact the developers. Usually there is no information given on how to do this, but on "Audacity needs you" we suggest writing to audacity-devel at sourceforge dot net Does that address exist (i.e. without the "lists")? And if we need to use the usual address, then they will get a "held as you are not a member" warning. What procedure do we want to follow here, so it can be standardised? Gale Outbound message virus free. Tested on: 8/28/2007 9:02:48 AM |
From: James C. <cr...@in...> - 2007-08-28 11:44:22
|
Gale Andrews wrote: > Does that address exist (i.e. without the "lists")? And if we need to use the > usual address, then they will get a "held as you are not a member" warning. > What procedure do we want to follow here, so it can be standardised? Oops... Perhaps better than the incorrect e-mail address I gave would be to direct people to our mailing lists page, http://audacity.sourceforge.net/contact/lists and then to rework the list descriptions there a bit. I would like the announcement for the developer list to be more inviting. On that page perhaps instead of: > Audacity-devel: For developers working with the Audacity source code > and documentation. You must subscribe to send messages to this list have: > Audacity-devel: For developers working with the Audacity source code > and documentation. If you've compiled Audacity yourself or are trying > to do so, this is the right list for you. You must subscribe to the > audacity-devel list to send messages to it. I think that makes it more inviting to developers than what we previously had. That change could be made now. Vaughan Johnson wrote: > Anyway, the artwork is cool, but I think the biggest effect will be if > we put a small text notice on the home page -- it gets tremendously more > traffic than the Get Involved page. Yes, we will need that. What wording would you suggest? > I'm also apprehensive though, on the > point Dominic made, that it might start a deluge of barely capable > talent. But per Cathedral and Bazaar, the bazaar will cause the cream to > rise. I expect new people to be less experienced with the code than us! It is easier for us to add getting-started material to the wiki when there are a number of people asking questions - so it's not so much the numbers of people, as how to deal with people who won't go on to make valuable contributions at all. > I think it might be best to do this after 1.4.0 is out, because adding > personnel now is likely to have the Mythical Man Month effect of > delaying its release. After 1.3.4 would be a good time to start recruiting. We'll have the essentials done, and we'll be waiting for feedback from our beta testers. --James. |
From: Gale A. <ga...@au...> - 2007-08-29 02:13:11
|
| From James Crook <cr...@in...> | Tue, 28 Aug 2007 12:46:16 +0100 | Subject: [Audacity-devel] Writing to the developers from the Wiki | Gale Andrews wrote: | > Does that address exist (i.e. without the "lists")? And if we need | > to use the usual address, then they will get a "held as you are not a | > member" warning. | > What procedure do we want to follow here, so it can be standardised? | | Oops... Perhaps better than the incorrect e-mail address I gave would | be to direct people to our mailing lists page, | | http://audacity.sourceforge.net/contact/lists | | and then to rework the list descriptions there a bit. I would like the | announcement for the developer list to be more inviting. On that page | perhaps instead of: | | > Audacity-devel: For developers working with the Audacity source code | > and documentation. You must subscribe to send messages to this list | | have: | | > Audacity-devel: For developers working with the Audacity source code | > and documentation. If you've compiled Audacity yourself or are trying | > to do so, this is the right list for you. You must subscribe to the | > audacity-devel list to send messages to it. | | I think that makes it more inviting to developers than what we | previously had. That change could be made now. That's probably a good change to make anyway, but I wonder for the case of specifically directing people to devel list from the Wiki they might just as well go straight to the devel-list subscription page as they have to go there anyway: http://lists.sourceforge.net/lists/listinfo/audacity-devel That page may probably want a look at the wording as well. If you let me know where you want references to contacting to devel list on the Wiki to point to I can make the changes if you don't get to it first while you on a particular page yourself. I think this may be a good time to be clearer what we do want to do with questions where people want to try compiling Audacity for the first time and are having problems. At present they will mostly go to -help list. For basic questions of where to get started I can help, and the new Wiki page here for Windows users: http://audacityteam.org/wiki/index.php?title=Developer_Guide#Windows_Set_Up will make things a bit easier. When it comes to detailed questions about Windows or Mac compilation errors, neither Richard or I can really help much, though Richard can solve the Linux compilation errors of course and (maybe) in fullness of time I can help with some Windows problems . If we want to encourage compilation error questions to go to devel list, then we will want to change http://audacity.sourceforge.net/contact/ accordingly. What do we think? If we can in particular improve the Windows documentation further, and give a strong impression that we're supportive of the relatively inexperienced building Audacity, getting interested and then contributing, I'm all for it, but it will be an extra time commitment. Gale Outbound message virus free. Tested on: 8/29/2007 3:13:11 AM |
From: James C. <cr...@in...> - 2007-08-29 16:13:41
|
Gale Andrews wrote: > | From James Crook <cr...@in...> > | > | > Audacity-devel: For developers working with the Audacity source code > | > and documentation. If you've compiled Audacity yourself or are trying > | > to do so, this is the right list for you. You must subscribe to the > | > audacity-devel list to send messages to it.... > > That's probably a good change to make anyway, but I wonder for the case of > specifically directing people to devel list from the Wiki they might just as well > go straight to the devel-list subscription page as they have to go there anyway: > http://lists.sourceforge.net/lists/listinfo/audacity-devel Yes. Better. > That page may probably want a look at the wording as well. Yes. I like the wording on the devel-list sign up page. If we add the text "If you've compiled Audacity yourself or are trying to do so, this is the right list for you". It should do just fine. > I think this may be a good time to be clearer what we do want to do with > questions where people want to try compiling Audacity for the first time and > are having problems. At present they will mostly go to -help list. For basic > questions of where to get started I can help, and the new Wiki page here > for Windows users: > http://audacityteam.org/wiki/index.php?title=Developer_Guide#Windows_Set_Up > will make things a bit easier. > When it comes to detailed questions about > Windows or Mac compilation errors, neither Richard or I can really help much, > though Richard can solve the Linux compilation errors of course and (maybe) > in fullness of time I can help with some Windows problems . If we want > to encourage compilation error questions to go to devel list, then we will > want to change http://audacity.sourceforge.net/contact/ accordingly. What do > we think? I think it is quite clear for Windows. Windows compilation issues / error messages should be handled on the audacity-devel list. I'll try to be reasonably responsive. Even if it is still Richard doing 98% of it, it also seems logical to handle Linux compile errors here too. A recent CVS check in which *we* know about might be the cause of some user problem in compiling. > If we can in particular improve the Windows documentation > further, and give a strong impression that we're supportive of the relatively > inexperienced building Audacity, getting interested and then contributing, I'm > all for it, but it will be an extra time commitment. If I help five developers get started on windows and one starts making valuable contributions, that's time well spent in my book. The way the windows documentation is most likely to improve is through having specific compile/link error messages that have been encountered listed on it, and what the symptom means. Over time, supporting people in getting up to speed should get easier. --James. |
From: Richard A. <ri...@au...> - 2007-08-29 18:21:25
|
On Wed, 2007-08-29 at 17:15 +0100, James Crook wrote: > > http://audacityteam.org/wiki/index.php?title=Developer_Guide#Windows_Set_Up > > > will make things a bit easier. Would anyone object to splitting this page into four on it's current headings? I can think of a reasonable number of things to say about Linux and Mac, but the page is rapidly going to get out of hand. I'm thinking maybe "Developing on Windows", "Developing on Linux" and "Developing on Mac" which would in principal be program agnositic, but include how to get debugable builds, where Apple hide the GCC install files and so on. > I think it is quite clear for Windows. Windows compilation issues / > error messages should be handled on the audacity-devel list. I'll try > to be reasonably responsive. > > Even if it is still Richard doing 98% of it, it also seems logical to > handle Linux compile errors here too. A recent CVS check in which *we* > know about might be the cause of some user problem in compiling. Fair enough, as I'm on both lists. Can we decide whether we aim to make source tarballs compile out of the box for Mac and Win or not? We don't currently test this, so often it turns out the project files need libraries not in the source tarballs and so on. Should we just advise people on these platforms to grab the CVS and start from there, leaving the source tarball as a way of building the releases for Linux (*BSD etc). This would let us loose quite a bit of stuff from the tarball, and with it some of the nasty compile errors (if we didn't have libsoundtouch in the tree, we wouldn't get the errors around it's assembly optimisations (pretty badly non-portable)). Richard |
From: Martyn S. <mar...@go...> - 2007-08-30 00:13:13
|
See below... Richard Ash wrote: > On Wed, 2007-08-29 at 17:15 +0100, James Crook wrote: >>> http://audacityteam.org/wiki/index.php?title=Developer_Guide#Windows_Set_Up >>> will make things a bit easier. ... > Can we decide whether we aim to make source tarballs compile out of the > box for Mac and Win or not? We don't currently test this, so often it > turns out the project files need libraries not in the source tarballs > and so on. Should we just advise people on these platforms to grab the > CVS and start from there, leaving the source tarball as a way of > building the releases for Linux (*BSD etc). This would let us loose > quite a bit of stuff from the tarball, and with it some of the nasty > compile errors (if we didn't have libsoundtouch in the tree, we wouldn't > get the errors around it's assembly optimisations (pretty badly > non-portable)). Tonight I thought I would see what it was like for a newbie. Not very encouraging. I followed 'If you wish to compile Audacity yourself...' Got the 'Recommended Download' (although as a windows person I don't know what a 'tarball' is). Extracted the .gz as a .tar (I would have to know how to do this, or go and find out, but really I have 7-zip). Unzipped the .tar (7-zip). Had already installed VS8 off MS (I'm pretending here, I have Pro installed already). Had to allow the 'conversion wizard' to run, as the sln file are version 7. Saw 8 projects that couldn't load as they aren't there. Press the green 'go' button anyway, and see 100s or errors and warnings (OK I have wx 2.6.4 and some are down to that, but you get the idea). As we heard recently from somebody who is probably more competant than I... | I'm sure many of you are snickering by now. For those who aren't, the | stable source isn't really compilable under the latest VC++, and MS | doesn't let you download older versions, so I probably need to scrub | everything and move to the bleeding edge source code. Yuck. This is | turning into more trouble than I have time for. Would anyone like to | help me out?" My conclusion? Direct Windows people (at least) to the current CVS version. Their problems may well be solved already, they work on what the rest of us are working on, they contribute to current code (not year old stuff), we stand a good chance of supporting them. But I have not tried the instructions for 'CVS' yet! TTFN Martyn > Richard > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: James C. <cr...@in...> - 2007-08-30 10:30:29
|
Martyn Shaw wrote: > Tonight I thought I would see what it was like for a newbie. Not very > encouraging. > I followed 'If you wish to compile Audacity yourself...' > Got the 'Recommended Download' (although as a windows person I don't > know what a 'tarball' is).... > | I'm sure many of you are snickering by now. For those who aren't, the > | stable source isn't really compilable under the latest VC++, and MS > | doesn't let you download older versions, so I probably need to scrub > | everything and move to the bleeding edge source code. Yuck. This is > | turning into more trouble than I have time for. Would anyone like to > | help me out?" > My conclusion? Direct Windows people (at least) to the current CVS > version. Their problems may well be solved already, they work on what > the rest of us are working on, they contribute to current code (not year > old stuff), we stand a good chance of supporting them. If a windows developer were joining Audacity right now, that is what I would suggest too. I would recommend that a new developer use audacity from CVS, wx2.8.4, and the wx284 Debug build. They can get going with a standard DLL build of wxWidgets (though later they should enable wxACCESSIBLE and wxGLCANVAS in setup.h). They don't need special project files for compiling wxWidgets. They can use MSVC2005 .vcproj files for compiling Audacity. Much fewer things to go wrong. Once we have 1.3.4 we should update the tarball. --James. |
From: Martyn S. <mar...@go...> - 2007-08-30 23:22:30
|
James I may well be wrong, but I've never seen the wx284 Debug build option appear in VS8, and I thought I had the most recent CVS update (and wx 2.6.4). Any idea what am I doing wrong? Should I get wx2.8.4 to see the option? Martyn James Crook wrote: > > Martyn Shaw wrote: >> Tonight I thought I would see what it was like for a newbie. Not very >> encouraging. > >> I followed 'If you wish to compile Audacity yourself...' >> Got the 'Recommended Download' (although as a windows person I don't >> know what a 'tarball' is).... > >> | I'm sure many of you are snickering by now. For those who aren't, the >> | stable source isn't really compilable under the latest VC++, and MS >> | doesn't let you download older versions, so I probably need to scrub >> | everything and move to the bleeding edge source code. Yuck. This is >> | turning into more trouble than I have time for. Would anyone like to >> | help me out?" > >> My conclusion? Direct Windows people (at least) to the current CVS >> version. Their problems may well be solved already, they work on what >> the rest of us are working on, they contribute to current code (not year >> old stuff), we stand a good chance of supporting them. > > If a windows developer were joining Audacity right now, that is what I > would suggest too. I would recommend that a new developer use audacity > from CVS, wx2.8.4, and the wx284 Debug build. They can get going with a > standard DLL build of wxWidgets (though later they should enable > wxACCESSIBLE and wxGLCANVAS in setup.h). They don't need special > project files for compiling wxWidgets. They can use MSVC2005 .vcproj > files for compiling Audacity. Much fewer things to go wrong. > > Once we have 1.3.4 we should update the tarball. > > --James. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: James C. <cr...@in...> - 2007-08-31 11:20:38
|
Martyn Shaw wrote: > James > I may well be wrong, but I've never seen the wx284 Debug build option > appear in VS8, and I thought I had the most recent CVS update (and wx > 2.6.4). Any idea what am I doing wrong? Should I get wx2.8.4 to see > the option? > Martyn You don't need wx2.8.4 to see the option. Probably I made a mistake with a cvs checkin and it isn't in CVS at all. I'll fix it when I check the vamp stuff in. The windows .sln and .vcproj files are always a problem with check ins because the CVS merging plays havoc with them - so when those change, I always check-in/check out separately from the c code, with consequent risk of not checking a change in correctly. Thanks for alerting me to it. --James. |
From: Gale A. <ga...@au...> - 2007-08-30 08:47:13
|
| From Richard Ash <ri...@au...> | Wed, 29 Aug 2007 19:21:18 +0100 | Subject: [Audacity-devel] Writing to the developers from the Wiki | On Wed, 2007-08-29 at 17:15 +0100, James Crook wrote: | > > http://audacityteam.org/wiki/index.php?title=Developer_Guide#Windows_Set_Up | > | > > will make things a bit easier. | | Would anyone object to splitting this page into four on it's current | headings? I can think of a reasonable number of things to say about | Linux and Mac, but the page is rapidly going to get out of hand. I'm | thinking maybe "Developing on Windows", "Developing on Linux" and | "Developing on Mac" which would in principal be program agnositic, but | include how to get debugable builds, where Apple hide the GCC install | files and so on. I can't say I see the function of that developer guide page on its own. Apart from the Windows, Mac and Linux specifics which I agree should have their own pages, the rest is "More about Audacity" which only has links accessible from the home page anyway, and I have already cross referenced those pages so they have links to each other. "More about digital sound" may be a good page in time but I am not quite sure if it belongs there. Also I am not quite sure where: http://audacityteam.org/wiki/index.php?title=CompilingAudacity fits into the new structure of OS specific compilation help pages. Should it just be rewritten as purely an overview of the principles, once Linux etc. and Mac have their own step by step instructions (as I assume is the intention)? Gale Outbound message virus free. Tested on: 8/30/2007 9:47:08 AM |
From: James C. <cr...@in...> - 2007-08-30 11:47:45
|
Gale Andrews wrote: > I can't say I see the function of that developer guide page on its own. Apart > from the Windows, Mac and Linux specifics which I agree should have their > own pages, the rest is "More about Audacity" which only has links accessible > from the home page anyway, and I have already cross referenced those > pages so they have links to each other. I see the developer section of the wiki growing beyond the number of pages where we would want to link to all of them from the home page. Therefore some kind of coordinating page will be needed - and that page can say more about each of the links than would be acceptable on the main page. We could, I think, already drop the whole of the 'Designing Audacity' section from the main page and have its links just from the [[Developer Guide]]. > "More about digital sound" may be > a good page in time but I am not quite sure if it belongs there. Also I > am not quite sure where: > http://audacityteam.org/wiki/index.php?title=CompilingAudacity > fits into the new structure of OS specific compilation help pages. Should it just > be rewritten as purely an overview of the principles, once Linux etc. and Mac > have their own step by step instructions (as I assume is the intention)? CompilingAudacity was 90% linux specific. I've moved its contents to [[Developing On Linux]] and done some other reorganisation. It's wiki. Nothing is set in stone. --James. |
From: Gale A. <ga...@au...> - 2007-08-31 01:33:33
|
| From James Crook <cr...@in...> | Thu, 30 Aug 2007 12:49:41 +0100 | Subject: [Audacity-devel] Writing to the developers from the Wiki | Gale Andrews wrote: | > I can't say I see the function of that developer guide page on its own. | > Apart from the Windows, Mac and Linux specifics which I agree should | > have their | > own pages, the rest is "More about Audacity" which only has links accessible | > from the home page anyway, and I have already cross referenced those | > pages so they have links to each other. | | I see the developer section of the wiki growing beyond the number of | pages where we would want to link to all of them from the home page. | Therefore some kind of coordinating page will be needed - and that page | can say more about each of the links than would be acceptable on the | main page. We could, I think, already drop the whole of the 'Designing | Audacity' section from the main page and have its links just from the | [[Developer Guide]]. That's fine if the Developer Guide is going to extend to be the hub page for development topics. Yes, agreed "Designing Audacity" looks ready to be dropped as its own section, and probably wants to be on the home page as a subsection of Developer Guide, so maybe I'll do that and you can see what you think. The odd man out is Feature Requests - it's already on the home page by virtue of being in the "most popular" section. Probably it should be on its own now, or it almost fits into "Maintaining Quality"? | > "More about digital sound" may be | > a good page in time but I am not quite sure if it belongs there. Also I | > am not quite sure where: | > http://audacityteam.org/wiki/index.php?title=CompilingAudacity | | > fits into the new structure of OS specific compilation help pages. Should | > it just | > be rewritten as purely an overview of the principles, once Linux etc. and | > Mac have their own step by step instructions (as I assume is the | > intention)? | | CompilingAudacity was 90% linux specific. I've moved its contents to | [[Developing On Linux]] and done some other reorganisation. It's wiki. | Nothing is set in stone. That's fine. My only interest is to see that things are kept user friendly for novices (which I still am, or worse than that). I still have reservations about http://audacityteam.org/wiki/index.php?title=CompilingAudacityForBeginners I'd have thought Mac and even Linux want step by step instructions that include the above basics in their own unitary document. Linux has novices as well - I almost switched to it. If it makes the documents too long, then it's fine to link to [[CompilingAudacityForBeginners] if it's properly integrated into the Mac and Linux instructions which I don't think it is yet. In other words on the home page, Windows, Linux and Mac have their own step by step guides which are the [[Developing on XX]] pages, and the link to [[CompilngAudacityForBeginners]] no longer exists on the Home Page (or no longer exists at all). Gale Outbound message virus free. Tested on: 8/31/2007 1:47:37 AM |
From: James C. <cr...@in...> - 2007-08-31 11:39:02
|
Gale Andrews wrote: > ...The odd man out is Feature Requests - it's already on the home > page by virtue of being in the "most popular" section. Probably it should be > on its own now, or it almost fits into "Maintaining Quality"? Or dropped entirely from the developer section on the home page. It is already very prominently on the home page. It can also be linked to from the developer guide. > .....I still have reservations about > http://audacityteam.org/wiki/index.php?title=CompilingAudacityForBeginners > I'd have thought Mac and even Linux want step by step instructions that > include the above basics in their own unitary document. I want to leave that to linux/mac people to edit or change. My own impression is that the title should be more like: [[Linux Compiling Step by Step]] Or else the page should just be merged into the [[Developing On Linux]] page. Leave it up to the people who know. I gather that Linux and mac development are very very similar, so it may be that the mac pages should just say 'follow the steps for linux, except where it says XXX use YYY instead...' rather than repeat all the information. My suggestion is that if you think you see an improved structure that makes the navigation better and the front page better, just make the change. Where on one of the subsidiary pages new material is needed, request it using an ''edit-hint:'' --James. |
From: Gale A. <ga...@au...> - 2007-09-01 06:07:26
|
| From James Crook <cr...@in...> | Fri, 31 Aug 2007 12:40:55 +0100 | Subject: [Audacity-devel] Writing to the developers from the Wiki | Gale Andrews wrote: | | > ...The odd man out is Feature Requests - it's already on the home | > page by virtue of being in the "most popular" section. Probably it should be | > on its own now, or it almost fits into "Maintaining Quality"? | | Or dropped entirely from the developer section on the home page. It is | already very prominently on the home page. | It can also be linked to from the developer guide. I have stuck it for now under the "Ensuring Quality" section as "possibly" the best place, but linked to it on the developer guide page with a developer slant. If we are encouraging questions and answers directly in the developer section of the Wiki we may need to think where they go. The Discussion tab of each page might be appropriate, though the usual Wiki line seems to be to discourage regular users doing that as they will probably never be answered, and keep discussion pages strictly for discussion of page content and structure. Or (better?) dedicated Q + A pages could be linked out of relevant pages e.g. the pages on the Developer Guide that have indented links. | > .....I still have reservations about | > http://audacityteam.org/wiki/index.php?title=CompilingAudacityForBeginners | | > I'd have thought Mac and even Linux want step by step instructions that | > include the above basics in their own unitary document. | | I want to leave that to linux/mac people to edit or change. My own | impression is that the title should be more like: | | [[Linux Compiling Step by Step]] | | now says Mac/Linux/Unix step by step guides. | | Or else the page should just be merged into the [[Developing On Linux]] | page. Without knowing the best way to convey the technical points, merging seems desirable to me. | I gather that Linux and mac | development are very very similar, so it may be that the mac pages | should just say 'follow the steps for linux, except where it says XXX | use YYY instead...' rather than repeat all the information. That is definitely a decision for experts on building on Mac. Leland might want to have some input too if he gets a chance. Gale Outbound message virus free. Tested on: 9/1/2007 7:07:21 AM |
From: James C. <cr...@in...> - 2007-08-30 10:11:41
|
Richard Ash wrote: > On Wed, 2007-08-29 at 17:15 +0100, James Crook wrote: >>> http://audacityteam.org/wiki/index.php?title=Developer_Guide#Windows_Set_Up >>> will make things a bit easier. > Would anyone object to splitting this page into four on it's current > headings? Please go ahead. > Can we decide whether we aim to make source tarballs compile out of the > box for Mac and Win or not? We don't currently test this, so often it > turns out the project files need libraries not in the source tarballs > and so on. Should we just advise people on these platforms to grab the > CVS and start from there, leaving the source tarball as a way of > building the releases for Linux (*BSD etc). This would let us loose > quite a bit of stuff from the tarball, and with it some of the nasty > compile errors (if we didn't have libsoundtouch in the tree, we wouldn't > get the errors around it's assembly optimisations (pretty badly > non-portable)). As a windows developer, can I turn your question round? Assuming we have a snapshot of CVS as a tarball, do we also need a cut down version for linux that excludes libraries like libsoundtouch? --James. |