IrcLog2010 06 15

William Deegan edited this page Jan 14, 2016 · 2 revisions
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 

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.