Thread: [Audacity-devel] guidelines (was: Ubuntu on Windows) (Page 3)
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Benjamin D. <bd...@de...> - 2013-03-11 22:21:45
|
Am Montag, den 04.02.2013, 23:25 -0800 schrieb Vaughan Johnson: > On 1/31/2013 10:46 PM, Rob Sykes wrote: > > ----- Original Message ----- > > > >> From: Benjamin Drung <bd...@de...> > >> To: aud...@li... > >> Cc: > >> Sent: Thursday, 24 January 2013, 12:48 > > > > > >> PS: Can we avoid top-posting on this mailing list? I recommend to read > >> the technical guidelines on > >> http://www.ubuntu.com/support/community/mailing-lists > > > > > > I second that and would suggest that we don't just read the > > guidelines, we adopt them (in essence if not word-for-word), i.e. > > record them on the web-site and reference them in the list 'welcome' > > mail. > > No. We've already discussed this, ages ago. We encourage contribution > over stylistic "rectitude" or enforcement. Sorry for triggering a heated discussion. I would have preferred to get one response saying something like: "We discussed this before. See <pointer to wiki/mail archive>." What I would like to see are guidelines (for communication and for the coding style), not rules. Everyone can decide to follow the guideline or not. Not following the guideline won't get you rejected, but following the guideline will increase the likelihood of getting accepted. Guidelines help to not getting distracted by format, but allows you to concentrate on the content. Would you prefer a language without grammar? You cannot make grammar mistakes without grammar, but understanding the content without grammar would be much harder. As a contributor I have these questions: When responding to a mail, should I top-post or inline post? When writing a patch, which coding style should I use? I could pick one, but this could annoy most developers without my intention. I want my mails and patches easily readable by the recipients. -- Benjamin Drung Debian & Ubuntu Developer |
From: Vaughan J. <va...@au...> - 2013-03-12 03:47:04
|
On 3/11/2013 3:21 PM, Benjamin Drung wrote: > Am Montag, den 04.02.2013, 23:25 -0800 schrieb Vaughan Johnson: >> On 1/31/2013 10:46 PM, Rob Sykes wrote: >>>> From: Benjamin Drung <bd...@de...> >>>> Sent: Thursday, 24 January 2013, 12:48 >>... >> No. We've already discussed this, ages ago. We encourage contribution >> over stylistic "rectitude" or enforcement. > > Sorry for triggering a heated discussion. But you're now trying to light it up again, despite it having concluded a while ago (weeks, right?). :-) - V |
From: Vaughan J. <va...@au...> - 2013-01-20 01:53:34
|
On 1/19/2013 4:19 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > | Fri, 18 Jan 2013 19:07:05 -0800 >> On 1/18/2013 3:57 PM, Benjamin Drung wrote: >>> Am Mittwoch, den 16.01.2013, 20:21 -0800 schrieb Vaughan Johnson: >>>> On 1/16/2013 12:42 PM, Steve the Fiddle wrote: >>>>> On 16 January 2013 19:50, Gale Andrews <ga...@au...> wrote: >>>>>> | From Steve the Fiddle <ste...@gm...> >>>>>>> [...] >>>>>>> Do we really need the full source tarball? As I understand it, it is >>>>>>> better for Linux users to use system libraries when possible. For >>>>>>> Windows developers I'd have thought they world be better to use SVN >>>>>>> than a tarball. >>>> >>>> I defer to Linux experts. >>> >>> I guess that the minsrc tarball is sufficient for most Linux users. We >>> always use the minsrc tarball in Debian/Ubuntu and nyquist is the only >>> library that we need from the lib-src directory. From a Linux user >>> perspective, the full source tarball could go away. >>> >>> I think it makes sense to keep the full source tarball and use it for >>> the Windows (and Mac?) builds. Then you can point user of your built >>> binaries to the corresponding source tarballs. This is in my opinion >>> easier than to point to a specific revision of an svn checkout. >>> >> >> Okay, thanks, but I don't think we have resources to do full tarball >> this release, as was pretty extensively discussed. >> >> If I'm incorrect about that, sure, let's do it. We're certainly >> resource-limited, so I think we should not spend a lot of effort on >> icing the cake. > > The maketarball.sh script uses: > > ./configure --enable-maintainer-mode --with-libsndfile=local --with-lib-preference=\"local system\" > > As I understand it, if you try to build all the libs needed for the > fullsrc using that ./configure, you end up with a failed configure > "fails with unexpected EOF's at line 8525 and 8526" or similar > (I can confirm that). > Thanks. So is that a -1 for full tarball for 2.0.3? Or +1 that we need to fix this and include it in 2.0.3? - V |
From: Gale A. <ga...@au...> - 2013-01-20 07:37:07
|
Sorry about that unreadable mess, I sent it using Nabble but something went wrong. Readable version below. >>> "Vaughan Johnson" wrote: >> On 1/19/2013 4:19 AM, Gale Andrews wrote: >>>> Benjamin wrote: >>>> I think it makes sense to keep the full source tarball and use it for >>>> the Windows (and Mac?) builds. Then you can point user of your built >>>> binaries to the corresponding source tarballs. This is in my opinion >>>> easier than to point to a specific revision of an svn checkout. >>>> >>> >>> Okay, thanks, but I don't think we have resources to do full tarball >>> this release, as was pretty extensively discussed. >>> >>> If I'm incorrect about that, sure, let's do it. We're certainly >>> resource-limited, so I think we should not spend a lot of effort on >>> icing the cake. >> >> The maketarball.sh script uses: >> >> ./configure --enable-maintainer-mode --with-libsndfile=local --with-lib-preference=\"local system\" >> >> As I understand it, if you try to build all the libs needed for the >> fullsrc using that ./configure, you end up with a failed configure >> "fails with unexpected EOF's at line 8525 and 8526" or similar >> (I can confirm that). > > > Thanks. > > So is that a -1 for full tarball for 2.0.3? > > Or +1 that we need to fix this and include it in 2.0.3? My 2p is that it would be "preferable" to have a full tarball for 2.0.3. Benjamin prefers it, and (IMO) it gives a *much* better impression vis-a-vis what we've always done in the recent past. I know Linux users are not the main user base, but in some ways we have a stronger connection with Linux than the other OS'es. If an expert was stepping up with a patch to enable a full tarball that meant we could have an rc2 at 22:00 GMT on 20 January I would be +1 on balance. In the absence of that happening I don't think we "need" to fix it at the cost of an indeterminate delay to the release. If we want the fullsrc tarball going forward and we don't fix it now, I think there should be a P2 bug to re-enable building it. Gale | From "Gale (Audacity Team)" <ga...@au...> | Sat, 19 Jan 2013 23:18:48 -0800 (PST) | Subject: [Audacity-devel] Tarballs > >>> "Vaughan Johnson" wrote:>> On 1/19/2013 4:19 AM, Gale Andrews wrote:>>>> > Benjamin wrote:>>>> I think it makes sense to keep the full source tarball > and use it for>>>> the Windows (and Mac?) builds. Then you can point user of > your built>>>> binaries to the corresponding source tarballs. This is in my > opinion>>>> easier than to point to a specific revision of an svn > checkout.>>>>>>>>>> Okay, thanks, but I don't think we have resources to do > full tarball>>> this release, as was pretty extensively discussed.>>>>>> If > I'm incorrect about that, sure, let's do it. We're certainly>>> > resource-limited, so I think we should not spend a lot of effort on>>> icing > the cake. >> >> The maketarball.sh script uses:>> >> ./configure > --enable-maintainer-mode --with-libsndfile=local > --with-lib-preference=\"local system\">> >> As I understand it, if you try > to build all the libs needed for the>> fullsrc using that ./configure, you > end up with a failed configure>> "fails with unexpected EOF's at line 8525 > and 8526" or similar >> (I can confirm that). > >> Thanks.>> So is that a -1 > for full tarball for 2.0.3?>> Or +1 that we need to fix this and include it > in 2.0.3?My 2p is that it would be "preferable" to have a full tarball for > 2.0.3.Benjamin prefers it, and (IMO) it gives a *much* better > impressionvis-a-vis what we've always done in the recent past. I know Linux > users are not the main user base, but in some ways we have a stronger > connection with Linux than the other OS'es. If an expert was stepping up > with a patch to enable a full tarball that meant we could have an rc2 at > 22:00 GMT on 20 January I would be +1 on balance. In the absence of that > happening I don't think we "need" to fixit at the cost of an indeterminate > delay to the release. If we want the fullsrc tarball going forward and we > don't fix it now,I think there should be a P2 bug to re-enable building it. > Gale > > > > -- > View this message in context: http://audacity.238276.n2.nabble.com/Tarballs-tp7557311p7557423.html > Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Vaughan J. <va...@au...> - 2013-01-20 08:20:19
|
On 1/19/2013 11:35 PM, Gale Andrews wrote: > > Sorry about that unreadable mess, I sent it using Nabble but > something went wrong. > > Readable version below. Oops, already replied to the prior one. Thanks for clarifying. :-) - V |
From: Gale (A. Team) <ga...@au...> - 2013-01-20 07:18:55
|
>>> "Vaughan Johnson" wrote:>> On 1/19/2013 4:19 AM, Gale Andrews wrote:>>>> Benjamin wrote:>>>> I think it makes sense to keep the full source tarball and use it for>>>> the Windows (and Mac?) builds. Then you can point user of your built>>>> binaries to the corresponding source tarballs. This is in my opinion>>>> easier than to point to a specific revision of an svn checkout.>>>>>>>>>> Okay, thanks, but I don't think we have resources to do full tarball>>> this release, as was pretty extensively discussed.>>>>>> If I'm incorrect about that, sure, let's do it. We're certainly>>> resource-limited, so I think we should not spend a lot of effort on>>> icing the cake. >> >> The maketarball.sh script uses:>> >> ./configure --enable-maintainer-mode --with-libsndfile=local --with-lib-preference=\"local system\">> >> As I understand it, if you try to build all the libs needed for the>> fullsrc using that ./configure, you end up with a failed configure>> "fails with unexpected EOF's at line 8525 and 8526" or similar >> (I can confirm that). > >> Thanks.>> So is that a -1 for full tarball for 2.0.3?>> Or +1 that we need to fix this and include it in 2.0.3?My 2p is that it would be "preferable" to have a full tarball for 2.0.3.Benjamin prefers it, and (IMO) it gives a *much* better impressionvis-a-vis what we've always done in the recent past. I know Linux users are not the main user base, but in some ways we have a stronger connection with Linux than the other OS'es. If an expert was stepping up with a patch to enable a full tarball that meant we could have an rc2 at 22:00 GMT on 20 January I would be +1 on balance. In the absence of that happening I don't think we "need" to fixit at the cost of an indeterminate delay to the release. If we want the fullsrc tarball going forward and we don't fix it now,I think there should be a P2 bug to re-enable building it. Gale -- View this message in context: http://audacity.238276.n2.nabble.com/Tarballs-tp7557311p7557423.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Vaughan J. <va...@au...> - 2013-01-20 08:11:13
|
On 1/19/2013 11:18 PM, Gale (Audacity Team) wrote: >>>> "Vaughan Johnson" wrote: >> On 1/19/2013 4:19 AM, Gale Andrews > wrote: >>>> Benjamin wrote: >>>> I think it makes sense to keep the full > source tarball and use it for >>>> the Windows (and Mac?) builds. Then > you can point user of your built >>>> binaries to the corresponding > source tarballs. This is in my opinion >>>> easier than to point to a > specific revision of an svn checkout. >>>> >>> >>> Okay, thanks, but I > don't think we have resources to do full tarball >>> this release, as > was pretty extensively discussed. >>> >>> If I'm incorrect about that, > sure, let's do it. We're certainly >>> resource-limited, so I think we > should not spend a lot of effort on >>> icing the cake. >> >> The > maketarball.sh script uses: >> >> ./configure --enable-maintainer-mode > --with-libsndfile=local --with-lib-preference=\"local system\" >> >> As > I understand it, if you try to build all the libs needed for the >> > fullsrc using that ./configure, you end up with a failed configure >> > "fails with unexpected EOF's at line 8525 and 8526" or similar >> (I can > confirm that). > > > Thanks. > > So is that a -1 for full tarball for > 2.0.3? > > Or +1 that we need to fix this and include it in 2.0.3? I don't know why your formatting was so messed up when it arrived to me. Anybody else have this problem? >My 2p > is that it would be "preferable" to have a full tarball for 2.0.3. > Benjamin prefers it, and (IMO) it gives a *much* better impression > vis-a-vis what we've always done in the recent past. Yes, we've heard that already. But my understanding is that overall, it's not *necessary* (even per Benjamin), so I don't see that precedent as stopping us from simplifying the task, now and going forward. And hey, Benjamin's wording was "makes sense to keep the full source tarball and use it for the Windows (and Mac?) builds". I should have read that more carefully the first time -- totally unnecessary imo. People who want to build on Win or Mac have access to SVN and/or min-tarball, and complete instructions on what else they need. Your saying "preferable" implies it's not necessary, and that's what we need to decide. We don't have resources to use on tasks that are not necessary. I asked you for +1 or -1 -- meaning is it necessary to change the decision already made? You didn't give +1 or -1. Looks like no to me. And especially, why are we discussing this again when we decided on it a few days ago? Just because it came up again, with no new info, in fact about narrower set of people (those who build on Win/Mac, excluding Linux)? Let's get the release completed. My RM final decision is to stick with what we decided a few days ago, no full-src tarball. >I know Linux users > are not the main user base, but in some ways we have a stronger > connection with Linux than the other OS'es. If an expert was stepping up > with a patch to enable a full tarball If an expert "were". It's subjunctive mood, because it's speculative -- not past tense "was". Past tense it was true, we had somebody who could/would do it. But now that speculation has been proven wrong, we don't have an expert stepping up to do it. Let's stop re-discussing decisions already made, and stop speculating what we would do with resources we do not have. Let's get this release out. >that meant we could have an rc2 at > 22:00 GMT on 20 January I would be +1 on balance. No testing?! It's already half-way through the 48-hour testing cycle. And who's going to do it? Nobody has volunteered. Too late. >In the absence of that > happening I don't think we "need" to fix it at the cost of an > indeterminate delay to the release. That's already been shown and determined. Nixed by RM. >If we want the fullsrc tarball going > forward and we don't fix it now, I think there should be a P2 bug to > re-enable building it. Gale -1. As I understand it, the experts don't think it's necessary. We're running on very limited resources, so we shouldn't resume full-src tarballs until we have resources, and stronger reasons than Win/Mac builders who have other ways to do it. And when we have more resources, there are many, much more important things to address. - V |
From: Gale A. <ga...@au...> - 2013-01-20 09:17:39
|
| From Vaughan Johnson <va...@au...> | Sun, 20 Jan 2013 00:11:41 -0800 | Subject: [Audacity-devel] Tarballs [...] > Your saying "preferable" implies it's not necessary, and that's what we > need to decide. We don't have resources to use on tasks that are not > necessary. > > I asked you for +1 or -1 -- meaning is it necessary to change the > decision already made? You didn't give +1 or -1. Vaughan, I'm not arguing/contradicting here, just clarifying. :=) We don't know the future. So I +1'ed if we have a patch in good time today, -1'ed if we don't. Obviously, leaving that door open might encourage a patch. What you're now saying (I think) is that if we had a patch to fix fullsrc this lunchtime, you wouldn't accept it, because it would delay the release (strictly) by two days. That looks like a valid view to me, especially given my "preferable" does indeed imply it's not really functionally "necessary". It's just a decision about whether something most agree is "preferable" is worth up to two days, should the opportunity arise. > >that meant we could have an rc2 at > > 22:00 GMT on 20 January I would be +1 on balance. > > No testing?! It's already half-way through the 48-hour testing cycle. Of course, testing. It would have to (strictly) delay the release by two days. Or RM could decide "nothing changed but the tarballs" so once tested we could only wait one day. > >If we want the fullsrc tarball going > > forward and we don't fix it now, I think there should be a P2 bug to > > re-enable building it. Gale > > -1. As I understand it, the experts don't think it's necessary. We're > running on very limited resources, so we shouldn't resume full-src > tarballs until we have resources, and stronger reasons than Win/Mac > builders who have other ways to do it. > > And when we have more resources, there are many, much more important > things to address. As I said, "if" we want fullsrc tarballs. IMO if we don't have a P2 for it, then we are making a policy decision to stop supporting fullsrc tarballs. We can't have fullsrc coming and going with releases according to if we have the resources. So if no P2, I think we should announce that as from this release, we only supply minsrc tarballs. I think supplying minsrc should be a commitment, but you don't, so I guess you would argue even supplying minsrc should be stated as "subject to resources"? At the very least, I think we've got to be clear here: http://audacity.sourceforge.net/download/source . what our intentions are. Gale |
From: Vaughan J. <va...@au...> - 2013-01-20 10:04:18
|
This point is decided for 2.0.3 -- no full-src tarballs. Taking rest of this discussion about interactions to team@, because I consider it "family matters", not relevant to getting tarballs per se, or testing this release in the 48-hour release candidate testing cycle -- which *should* be our top priority currently, not digresssions about decisions already made. - V |