Clone wiki

SCons / BugParty / IrcLog2010-06-15

The SCons wiki has moved to

16:03:04  *      techtonik (~[]( has joined #SCONS 
16:31:51  *      garyo (~[]( has joined #SCONS 
16:47:50  *      bdbaddog (~[]( has joined #SCONS 
17:00:39  *      sgk (~sgk@nat/google/x-bfuzncsvocbkaddk) has joined #SCONS 
17:00:48  <garyo>        Hi guys 
17:00:53  *      You are no longer marked as being away 
17:00:53  <sgk>  hello hello 
17:00:57  *      [GregNoel](GregNoel) is here 
17:01:07  <garyo>        Hi Greg 
17:01:14  <[GregNoel](GregNoel)>     Hello, everyone; who all is here? 
17:01:29  *      sgk applauds [GregNoel](GregNoel) for getting 2.0.0 release 
17:01:30  <garyo>        Looks like me, sgk, Bill, you 
17:01:32  <sgk>  d 
17:01:36  <bdbaddog>     I'm here. 
17:01:58  *      Jason_at_Intel (~[chatzilla@](mailto:chatzilla@ has joined #SCONS 
17:02:00  <garyo>        Yes -- kudos to both Greg and Bill for getting through a lot of checkpoints and releases recently! 
17:02:04  <garyo>        Hi Jason 
17:02:15  <bdbaddog>     Garyo: Thanks. 
17:02:17  <Jason_at_Intel>       HI all 
17:02:34  <bdbaddog>     I guess 1.3.1 should go out soon. I'll get it done when I'm back from this conference. 
17:02:20  <[GregNoel](GregNoel)>     sgk, garyo, thanks.  We had a major earthquake leading to lots of network outages that made the process interesting... 
17:02:29  <sgk>  yow 
17:02:37  <garyo>        Oh yeah, I heard about that -- no major damage though? 
17:03:10  <[GregNoel](GregNoel)>     garyo, not to us.  A picture fell off a shelf and broke the glass. 
17:03:24  <Jason_at_Intel>       ? 
17:03:37  <garyo>        I thought people in California didn't put things on shelves :-/ 
17:03:45  <garyo>        (earthquake, Jason) 
17:03:55  <Jason_at_Intel>       ahh 
17:04:07  <[GregNoel](GregNoel)>     There are bookcases in our library. 
17:04:32  <garyo>        So wow, 2.0 is out and all kinds of stuff is now unblocked -- meaning I have to get to all those things I said I'd do post 2.0! :-) :-) 
17:04:30  <[GregNoel](GregNoel)>     Anyway, are we ready to go? 
17:04:36  <garyo>        Yes, I'm ready. 
17:04:41  <sgk>  ready 
17:04:46  <[GregNoel](GregNoel)>     2634, wontfix? 
17:05:03  <sgk>  i can go there 
17:05:05  <garyo>        I'm ok w/ that, he'll reopen if needed 
17:05:14  <[GregNoel](GregNoel)>     done 
17:05:16  <[GregNoel](GregNoel)>     2636, more time? 
17:05:20  <garyo>        yes 
17:05:34  <sgk>  yes, revisit next bug party 
17:05:43  <[GregNoel](GregNoel)>     done 
17:05:45  <[GregNoel](GregNoel)>     2639, consensus 2.1 p3, but needs an owner. 
17:05:54  <sgk>  russel brought it up, right? 
17:06:21  *      sgk wishes that's bug tracker had keyboard shortcuts 
17:06:30  <[GregNoel](GregNoel)>     {;-} 
17:06:33  <Jason_at_Intel>       loading spreadsheet.. but ready 
17:06:35  <garyo>        Maybe he'd do it.  Yes, he posted it. 
17:06:53  <garyo>        no wait, Steven did. 
17:07:33  <sgk>  yeah, i opened it to avoid another N emails where people debated whether or not an issue should be opened, and by whom 
17:06:53  <[GregNoel](GregNoel)>     Or how about techtonik?  He's interested in documentation. 
17:07:00  <garyo>        Greg: that's a good idea. 
17:07:27  <Jason_at_Intel>       anyone use the tiris ecplise of VS integration? 
17:07:54  <garyo>        jason: not me. 
17:08:06  <sgk>  if techtonik is interested, great 
17:08:13  <garyo>        OK, for 2639, assign to techtonik & see if he minds? 
17:08:19  <garyo>        Or ask first? 
17:08:27  <[GregNoel](GregNoel)>     OK, I'll ask him.  Is that the decision? 
17:08:32  <sgk>  yeah 
17:08:33  <garyo>        +1 from me 
17:08:45  <sgk>  and if he doesn't want it, then i'm okay with just giving it to Russel 
17:08:36  <[GregNoel](GregNoel)>     done 
17:08:39  <[GregNoel](GregNoel)>     2640, consensus 2.1 p2 Greg, unless Gary restores his offer...  {;-} 
17:08:39  <[GregNoel](GregNoel)>     2642, consensus 2.1 p3 Gary 
17:08:39  <[GregNoel](GregNoel)>     2643, consensus 2.x p3 Gary (I'm neutral about coercion v. error) 
17:08:39  <[GregNoel](GregNoel)>     2644, Steven, I don't think an organized text file is more of a custom file format than a "standard" XML binary format; quite the reverse, in fact.  Besides, I'm leery of requiring another external package to diff XML when all the python versions we support have difflib for text. 
17:09:23  <sgk>  re: 2644:  okay, suit yourself 
17:09:26  <garyo>        2644, I don't have an opinion either way 
17:10:36  <bdbaddog>     +1 on not requiring more packages for developer. 
17:10:32  <garyo>        2645 I can do, if you don't mind me doing it blind (no Fortran) -- I'll just check with the OP. 
17:10:33  <[GregNoel](GregNoel)>     2645, consensus 2.1 p2, but needs an owner. 
17:11:01  <garyo>        I'll take it 
17:11:30  <[GregNoel](GregNoel)>     done 
17:11:33  <[GregNoel](GregNoel)>     2646, consensus invalid 
17:11:33  <[GregNoel](GregNoel)>     2647, Steven solved a nasty problem and checked in a fix, but should that fix be scheduled toward a release of, 2.0.1, or 2.1? I added a workaround to the issue that should work (Gary's suggestion of [SideEffect](SideEffect)() works perfectly), so if we deem that good, I vote for 2.1. 
17:11:59  <sgk>  what's the difference between and 2.0.1 ? 
17:12:02  <sgk>  from a user perspective 
17:12:21  <[GregNoel](GregNoel)>     sgk, the former is a patch, the latter is a new release. 
17:12:41  <sgk>  and users need to know / care about that distinction because...? 
17:12:01  <bdbaddog>     Sideffect() is a workaround for the issue right? 
17:12:15  <Jason_at_Intel>       yep 
17:12:09  <garyo>        I vote for 2.1.  It's still a corner case. 
17:12:46  <Jason_at_Intel>       Well as a corner case i can't promote to Scons 1.2+ till it is in 
17:12:48  <bdbaddog>     post bugs, I think we need to discuss getting rid of the .final. 
17:12:50  <garyo>        Right, we shouldn't drop everything to release this fix basically. 
17:12:56  <[GregNoel](GregNoel)>     I'm seeing a consensus toward 2.1 
17:12:59  <Jason_at_Intel>       I have six products that broke cause of this 
17:13:16  <bdbaddog>     it's a regression right? 
17:13:21  <sgk>  yes, it worked in 1.2.0 
17:13:22  <bdbaddog>     2.0.1 
17:13:25  <Jason_at_Intel>       yep 
17:13:26  <[GregNoel](GregNoel)>     Jason_at_Intel, can you use [SideEffect](SideEffect)()? 
17:13:27  <garyo>        Hm, ok maybe it's an edge rather than a corner? :-) 
17:13:34  <sgk>  heh 
17:13:47  <bdbaddog>     we have a fix. 2.0.1, unless u think the fix might destability 2.0.0 
17:13:56  <bdbaddog>     destabilize that should be. 
17:14:12  <Jason_at_Intel>       Yes, i have people moving to it... but politics prevent a move to 2.0 cause of fear that something else if wrong 
17:14:22  <garyo>        I'm ok either way, just trying to reduce release churn so we can get some work done. 
17:14:38  <Jason_at_Intel>       I think that [SideEffect](SideEffect) is more correct in most of the cases this happens for me 
17:14:52  <garyo>        Jason: that's what I'd expect, given the testcase. 
17:15:02  <bdbaddog>     pushing the release button is all I have time for in the near future. so if I can get a handle on greg's changes I can do that. 
17:15:10  <Jason_at_Intel>       but the large products have 350 binaries in it 
17:15:29  <Jason_at_Intel>       so it hard to say that [SideEffect](SideEffect) will fix all cases developer have come up with 
17:16:11  <Jason_at_Intel>       we have some very cleaver people :-) 
17:16:10  <garyo>        If Bill's got time for a 2.0.1, I'm OK with that.  Is there anything else we should squeeze in? 
17:16:24  <Jason_at_Intel>       I can wait till 2.0.1 
17:16:29  <bdbaddog>     maybe any doc changes? 
17:16:29  <[GregNoel](GregNoel)>     Sounds to me that you should try to switch to [SideEffect](SideEffect)() and if it doesn't solve your problems, reopen the question. 
17:16:33  <Jason_at_Intel>       but i hope it is in 30 or so :-) 
17:16:42  <garyo>        30 what? 
17:16:48  <sgk>  yeah, doc changes:  i still owe a writeup on SConsignFile() 
17:16:53  <Jason_at_Intel>       30 days 
17:17:05  <garyo>        ok.  Yes, I owe some doc fixes too. 
17:17:08  <bdbaddog>     I also owe some doc work as well. 
17:17:10  <[GregNoel](GregNoel)>     also 
17:17:10  <garyo>        --warn in the UG I think. 
17:17:48  <garyo>        Steven, I sent you some doc a while ago, any opinion on where that could go? 
17:18:00  <sgk>  oh, right 
17:18:10  <sgk>  i vaguely remember looking at it and not having a good idea either 
17:18:14  <sgk>  same with SConsignFile 
17:18:30  <sgk>  if it's really homeless, putting it in the Misc chapter seems as good as any 
17:18:12  <[GregNoel](GregNoel)>     (I have a question about the doc work, too, but let's return to it later; resolve this issue first.) 
17:18:44  <garyo>        I'm hearing 2.0.1 for this issue. 
17:18:58  <sgk>  so 2.0.1 with a normal checkpoint cycle, right? 
17:19:06  <garyo>        Jason needs it, it's done, and Bill has time to push it out. 
17:19:08  <[GregNoel](GregNoel)>     I'd rather see if [SideEffect](SideEffect)() solves the problem. 
17:19:29  <garyo>        He should use [SideEffect](SideEffect) where possible anyway; it's more correct. 
17:19:39  <garyo>        Ties the dependency to the proper builder. 
17:19:34  <sgk>  Jason_at_Intel:  what would give your user base the most confidence? 
17:19:44  <sgk>  knowing that there's a better solution in the current code base, 
17:19:56  <sgk>  or fixing this behavior with Depends()? 
17:19:42  <bdbaddog>     [GregNoel](GregNoel): But is [SideEffect](SideEffect)() is a workaround? 
17:20:29  <garyo>        Depends() is weird in this case anyway.  It's brain-twisting that it even should work. 
17:20:31  <[GregNoel](GregNoel)>     Depends() is an accident; [SideEffect](SideEffect)() is really the right solution. 
17:20:49  <garyo>        (but I agree it should work.) 
17:20:36  <Jason_at_Intel>       I would say 2 things 
17:21:13  <Jason_at_Intel>       1) being backwards compatible.. so teh current build does not break ( minus stuff that is really broken) 
17:21:20  <Jason_at_Intel>       2) saying that something did not happen.. Scons is very silent on what it is doing 
17:21:23  <Jason_at_Intel>        ie 
17:21:49  <Jason_at_Intel>       it does not say .. i am ignoring this node as it has no builders... did you mean [SideEffect](SideEffect)? 
17:21:50  <sgk>  garyo:  i kind of view it as Depends() should work on a file without a Builder just like it does on one with 
17:21:57  <sgk>  it's just that without a Builder, the build action is null 
17:22:20  <sgk>  but that may be because i've been brainwashed by the current implementation 
17:22:31  <garyo>        sgk: you're right, I'm kind of exaggerating.  But I think everyone's right: 
17:22:40  <Jason_at_Intel>       people get unhappy when Scons when they don't get why it will not build something as they expect 
17:22:43  <sgk>  shuttle real soon.... 
17:22:40  <[GregNoel](GregNoel)>     sgk, then will you fix Alias() as well?  It has the same problem. 
17:22:56  <sgk>  [GregNoel](GregNoel):  good point 
17:23:05  <sgk>  since this behavior is fresh in my mind, i'll take a look now 
17:22:55  <garyo>        Depends() should be made to work as it did, and Jason should use [SideEffect](SideEffect) where it's correct to do so. 
17:23:20  <Jason_at_Intel>       it is not me... but the developer i support :-) 
17:23:22  <sgk>  biab 
17:23:23  *      sgk has quit (Quit: sgk) 
17:23:30  <garyo>        Jason: yep 
17:23:40  <Jason_at_Intel>       ya the Alias() and Depends() 
17:23:43  <[GregNoel](GregNoel)>     brb 
17:23:44  <Jason_at_Intel>       I like that to be fixed 
17:24:02  <Jason_at_Intel>       it would allow the Make virtual node idea to work as people expect 
17:24:08  <garyo>        Jason: no doubt in anyone's mind they should work. 
17:24:54  <garyo>        But do we *need* to put out an extra release, with checkpoints and bla bla bla, for it?  Maybe... let me see how many 2.1 tickets we have. 
17:25:18  <Jason_at_Intel>       I know... the problem i get is I have some very passionate developer that go back and say " in my day.. this did not happen... and pigs flew" 
17:25:35  <bdbaddog>     I'm thinking since we'll be adding a lot into 2.1, that this bug fix should go without all that additional changes. 
17:25:45  <garyo>        OK, we have 68 tickets open for 2.1.  This is going to take a while. 
17:26:10  <garyo>        So maybe 2.0.1 is appropriate. 
17:27:09  <garyo>        whoa, 20 of the 2.1 issues are mine :-/ 
17:27:33  <bdbaddog>     Yeah. I don't want to even look at that yet..:( 
17:27:56  <garyo>        You're OK, only 5. 
17:28:16  <[GregNoel](GregNoel)>     As I said before, Depends() is an accident; [SideEffect](SideEffect)() is really the right solution.  The regression should be fixed, but you should be using [SideEffect](SideEffect)(). 
17:29:12  <garyo>        I think we all agree on that now.  But looking at the tix for 2.1, I think 2.0.1 is OK if Bill's up for it. 
17:29:40  <bdbaddog>     yup. so we do a checkpoint? and then 2weeks later 2.0.1 right? 
17:29:44  *      Jason_at_Intel has quit (Ping timeout: 260 seconds) 
17:29:48  <bdbaddog>     this weekend is when I'll get to the build. 
17:30:18  <garyo>        Works for me; I should be able to get some doc in there too by then. 
17:30:32  *      Jason_at_Intel (~[chatzilla@](mailto:chatzilla@ has joined #SCONS 
17:30:55  *      sgk (~[sgk@](mailto:sgk@ has joined #SCONS 
17:31:07  <sgk>  am i back yet?  is this thing on? 
17:31:08  <[GregNoel](GregNoel)>     It could work.  It was surprisingly easy to cherry-pick individual changesets over via checkpoint.  But I'd oppose bringing over anything more.  (Well, maybe the doc.) 
17:31:37  <sgk>  what'd i miss? 
17:31:58  <Jason_at_Intel>       we agree that we have a lot of stuff to fix 
17:32:02  <bdbaddog>     2.0.1 with just that fix, checkpoint build this weekend, 2.0.1 2 weeks later. 
17:32:03  <garyo>        I think we're agreeing on 2.0.1 with a checkpoint first, including only this fix and some doc 
17:32:10  <bdbaddog>     yes. + doc. 
17:32:45  <[GregNoel](GregNoel)>     done 
17:32:22  <garyo>        (and that there are 68 tickets open for 2.1, 20 of which are mine, ack) 
17:32:27  <sgk>  okay 
17:32:48  <sgk>  (the other 48 are probably mine, given my track record... :-/) 
17:33:14  <garyo>        Actually a bunch are issues@scons which I don't understand 
17:33:43  <[GregNoel](GregNoel)>     sgk, 2.1 is scheduled for October, so you've got plenty of time... {;-} 
17:34:02  <garyo>        October 2009? :-) 
17:34:16  <garyo>        j/k 
17:34:20  <sgk>  garyo:  don't understand how they got that way?  I returned a whole bunch that were languishing with me 
17:34:25  <[GregNoel](GregNoel)>     garyo, probably +Easy that never got assigned. 
17:34:54  <garyo>        ok, sounds plausible 
17:35:01  <[GregNoel](GregNoel)>     garyo, no, October 2010, believe it or not; it's in the roadmap. 
17:35:26  <garyo>        excellent! 
17:35:51  *      sgk scores a point for garyo 
17:35:52  <garyo>        68 tickets in 4 months is doable I think. 
17:36:07  <sgk>  yep, sounds realistic 
17:35:51  <[GregNoel](GregNoel)>     OK, we seem to be agreed on that; resume the doc discussion? 
17:35:57  <garyo>        fine w/ me 
17:36:58  <[GregNoel](GregNoel)>     My question is where the command-line options live.  I was looking for a template to start with while I was waiting for the regression tests to finish and couldn't find one. 
17:38:13  <sgk>  in the User's Guide, they kind of just show up wherever it conceptually makes sense to introduce them 
17:38:17  *      sgk goes to look for an example 
17:38:31  <Jason_at_Intel>       the is a nice section in the man page 
17:38:52  <sgk>  example:  --tree= shows up in the troubleshooting section 
17:39:26  <sgk>  so it's a matter of thinking about where it makes logical sense to introduce the concept of "you can control warnings" 
17:40:10  <[GregNoel](GregNoel)>     Hmmm...  I think I have --warn= and Gary has --checkdisk, but neither of them seem to have homes. 
17:40:32  <sgk>  there is a chapter that's nominally about controlling your build from the command line 
17:40:38  <sgk>  doc/user/command-line.{in,xml} 
17:40:57  *      [GregNoel](GregNoel) looks at it... 
17:40:59  <sgk>  but it's a little more about Options and stuff like that 
17:41:14  <sgk>  but maybe it provides a logical home anyway 
17:41:25  <sgk>  i could also see --warn= in the troubleshooting section 
17:41:52  <sgk>  i could see users ending up there if they ask themselves, "where do I find out how to get SCons to STFU" 
17:42:26  <garyo>        I agree -- the man page is where we put all the options together; the UG should be task-oriented. 
17:42:47  <[GregNoel](GregNoel)>     Yeah, either is a possibility; I was afraid I'd have to do an entire new page... 
17:44:02  <[GregNoel](GregNoel)>     Now that I have a clue, I'll be able to hunt down a few more examples.  Thanks. 
17:44:34  <sgk>  okay 
17:44:40  <sgk>  what else? 
17:44:44  <[GregNoel](GregNoel)>     Anything else?  There were some other things about doc before; are all of those answered? 
17:45:05  <bdbaddog>     .final ? 
17:45:20  <[GregNoel](GregNoel)>     What about it? 
17:45:37  <garyo>        Can we omit it, per discussion on the ml today? 
17:45:39  <bdbaddog>     Are we going to drop it and have 2.0.1 and 2.0.0,etc for the actual release? 
17:45:44  <sgk>  yeah, i was surprised to see that show up in the actual package name 
17:45:45  *      Jason_at_Intel has quit (Ping timeout: 240 seconds) 
17:45:49  <bdbaddog>     well not 2.0.0 since it's out 
17:45:55  <sgk>  right 
17:46:45  <[GregNoel](GregNoel)>     I noticed that as the release was going out, but I didn't have time to do anything about it then. 
17:47:28  <garyo>        ok, for 2.0.1 then, we're all agreed? 
17:47:30  <[GregNoel](GregNoel)>     There's a distinction between the _package_ name (*.final.*) and the _release_ name (2.0.0). 
17:47:50  <[GregNoel](GregNoel)>     We need to figure out which is used where. 
17:48:00  <sgk>  [GregNoel](GregNoel):  conceptual distinction, or just in the way I implemented the SConstruct build long long ago? 
17:48:09  <[GregNoel](GregNoel)>     Yes 
17:48:25  <sgk>  which? 
17:48:28  <sgk>  let me ask another way 
17:48:54  <sgk>  we all agree the release should ideally be named 2.0.1, not, yes? 
17:48:59  *      Jason_at_Intel_ (~[chatzilla@](mailto:chatzilla@ has joined #SCONS 
17:49:00  *      Jason_at_Intel_ is now known as Jason_at_Intel 
17:49:22  <bdbaddog>     yes 
17:49:33  <[GregNoel](GregNoel)>     Yes, but when one refers to the package, it has the suffix.  They're different. 
17:49:53  <sgk>  that's the next question 
17:50:06  <[GregNoel](GregNoel)>     That is, you should download, but it should install 2.0.1. 
17:50:12  <sgk>  [GregNoel](GregNoel):  you're saying that you think the package should be named ? 
17:50:19  <[GregNoel](GregNoel)>     Yes 
17:50:34  <sgk>  why?  i don't know of another project that does that 
17:50:51  <sgk>  does it buy us anything other than the ordering?  or is that the main motivator 
17:50:57  <[GregNoel](GregNoel)>     Because it sorts alphabetically. 
17:51:48  <bdbaddog>     Doesn't seem to be a problem for other projects, so why be diffferent? 
17:51:48  <sgk>  i personally don't find that a compelling reason to make users map between the release number and a package with a different name 
17:52:03  <garyo>        Irrespective of anything else, I think the download file of 2.0.1 should be called scons-2.0.1.tar.gz unless we have a really good reason. 
17:52:11  <bdbaddog>     concur 
17:52:38  <garyo>        Checkpoints and betas should identify themselves as such though, just as we've been doing. 
17:52:45  <[GregNoel](GregNoel)>     Well, I've missed final releases because it was buried in the list of alpha, beta, ... releases, so I have personal motivation if nothing else. 
17:53:14  <garyo>        Still, look around -- nobody else calls their finals final. 
17:53:39  *      Jason_at_Intel has quit (Ping timeout: 260 seconds) 
17:54:17  <[GregNoel](GregNoel)>     I could be persuaded, but I'd still worry about it. 
17:54:08  <garyo>        Is either way technically more difficult than the other? 
17:54:29  <sgk>  i don't think so, but i haven't looked at that code in a while 
17:55:21  <[GregNoel](GregNoel)>     garyo, yes; update-release-info has to know which values to update; it's tricky for the case of pure text files with no hints. 
17:54:42  <sgk>  [GregNoel](GregNoel):  still worry about what aspect of it? 
17:56:14  <[GregNoel](GregNoel)>     sgk, people picking the last-listed (or first-listed) simply because they missed the actual release in the middle. 
17:56:49  <[GregNoel](GregNoel)>     Look at the RPM labeling to avoid that problem. 
17:57:24  <sgk>  ? 
17:57:26  <garyo>        Yes, rpm solves that cleverly.  But it's not purely alphabetical; it sorts the separate fields. 
17:57:23  <bdbaddog>     We can go non-final and see if we get any user issues.. 
17:57:34  <bdbaddog>     if not we stay that way, if so we revisit. 
17:57:41  <garyo>        There's no good way if sourceforge is purely alpha. 
17:58:26  <[GregNoel](GregNoel)>     I'm certainly open to suggestions. 
17:58:18  <garyo>        I think people will figure it out. 
17:58:51  <[GregNoel](GregNoel)>     garyo, _I_ missed it, more than once.  And I think I'm brighter than the average downloader. 
17:58:55  <garyo>        I think in the absence of brilliant new methods we should just do what everyone else does.  Innovate in the software, not the naming. 
17:58:59  <bdbaddog>     So I'm looking at the SF ui now. newest files are at the top. 
17:59:35  <garyo>        That would be sensible... 
17:59:38  <bdbaddog>     Highlighted in green with a table tile of "newest files" 
17:59:49  <bdbaddog>     then a section labelled "all files" 
17:59:59  <bdbaddog>     I think we'll be fine with vanilla 2.0.1 labelling. 
18:02:08  <[GregNoel](GregNoel)>     OK, identify which cases need the full label and which need the short label, and I'll see what I can do with update-release-info. 
18:02:35  <garyo>        Greg's right that in some cases it will probably not sort ideally.  But I think it's such a minor thing, and the ".final.0" sticks out like a sore thumb to me; for me it's mostly an aesthetic thing. 
18:02:40  <sgk>  alpha, beta, candidate all seem okay with the full label 
18:03:30  <sgk>  as a naive user, any added word (or abbreviation like "rc") is a flag to me that it's not a production release 
18:04:28  <bdbaddog>     so are we doign alpha and candidate now? or just alpha, beta, and released (where there's no additioinal text for the released version) 
18:05:00  <[GregNoel](GregNoel)>     Ah, bad timing; I'm called to dinner.  I'll collect my thoughts and continue the thread on the mailing list. 
18:05:23  <sgk>  darn, i had a testing topic i wanted to talk about 
18:05:30  <sgk>  okay, i can shift that to the mailing list, too 
18:05:40  <bdbaddog>     free beers at vendor party are waiting for me... 
18:06:04  <[GregNoel](GregNoel)>     I can stall a few minutes for another topic, but this one is drawing out.  Is it quick? 
18:06:11  <sgk>  probably not 
18:06:37  <[GregNoel](GregNoel)>     A quick general statement of the issue? 
18:06:40  <sgk>  trying to decide how to start converting the tests 
18:06:55  <sgk>  to the new sconstest- prefix idea 
18:06:23  <bdbaddog>     float it to release or dev mailing list? 
18:07:15  <[GregNoel](GregNoel)>     Ah.  Definitely not quick.  Mailing list it is.  We'd need Dirk for it anyway. 
18:07:23  <sgk>  yep, good point 
18:07:29  <sgk>  we're done? 
18:07:36  <[GregNoel](GregNoel)>     I think so; g'night all. 
18:07:40  <sgk>  bdbaddog:  i'll send to dev 
18:07:41  *      You have been marked as being away 
18:08:05  <sgk>  'night 
18:08:07  <garyo>        ok folks, see you again soon.  bdbaddog, have a beer for us! 
18:08:14  <bdbaddog>     will do! 
18:08:24  *      sgk (~[sgk@](mailto:sgk@ has left #SCONS 
18:08:55  *      bdbaddog has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.3/20100401064631]) 
18:09:30  *      garyo (~[]( has left #SCONS