Loading ...
Sorry, an error occurred while loading the content.
 

BoD log 5-17-07

Expand Messages
  • Paul
    Well anyone have anything? I d be curious on James thoughts relative to the RC ok, work meeting over so I
    Message 1 of 1 , May 16, 2007
      <[OGL]Nylanfs> Well anyone have anything?
      <[Arch_2nd]thpr> I'd be curious on James' thoughts relative to the RC
      <[Code_SB]jdempsey> ok, work meeting over so I can focus here now
      <[Code_SB]jdempsey> I can chair easily enough
      <[Code_SB]jdempsey> Are the 2nds ready to do reports?
      <[Arch_2nd]thpr> I am
      <[Code_SB]jdempsey> I'll kick off with code
      <[PR2nd-PL]Maredudd> I'll do what I can . . .
      <[Code_SB]jdempsey> OK, code has 8 bugs scheduled for 5.12 outstanding
      <[Code_SB]jdempsey> The one Java 1.6 showstopper was fixed earlier
      this week
      <[Code_SB]jdempsey> None of the remaining bugs are too serious and I
      would be happy to go to RC with them present on the assumption that
      we try and fix them but may not get them all done
      <[Code_SB]jdempsey> Tom raised a good point regarding importing
      characters fro 5.10 - I think we should treat that as a separate
      agenda item after the team reports.
      <[Code_SB]jdempsey> PS: Thanks to all fo the code monkeys who pitched
      in a fixed so many bugs, particularly Tom. This is the best the code
      base has ever looked!
      <[Code_SB]jdempsey> Any questions?
      <[Arch_2nd]thpr> not from me
      <[PR2nd-PL]Maredudd> not about code
      <[OGL]Nylanfs> Not I.
      <[Code_SB]jdempsey> OK, lets move on to Architecture then - Tom
      <[Arch_2nd]thpr> Okay - CDOM discussions have taken place on the -
      devel list, I think that has resolved for me how tokens will work (I
      have most rewritten, just not checked in)
      <[Arch_2nd]thpr> It has also resulted in answers for how the
      PlayerCharacter class will likely work
      <[Arch_2nd]thpr> I have been working on 0.4 of the arch doc in order
      to get the full explanation written down; still work to do before it
      goes out
      <[Arch_2nd]thpr> I have also started a local 5.14 branch to work on
      the changes that will happen there.
      <[Arch_2nd]thpr> Will wait for guidance from you, James,on when 5.14
      that gets branched or becomes Trunk
      <[Arch_2nd]thpr> Any questions?
      <[Code_SB]jdempsey> I think the general consensus was that the 5.12
      branch will be created when the first RC comes out. Then Trunk
      becomes the 5.13 line destined for 5.14
      <[Code_SB]jdempsey> Good news on the tokens - there were some complex
      issues you raised there
      <[Arch_2nd]thpr> ok, I'll just wait for word from you on that
      <[Code_SB]jdempsey> np
      <[Code_SB]jdempsey> Any further architecture questions?
      <[OGL]Nylanfs> How close would you think we are on permenantly
      supporting tags for future releases?
      <[OGL]Nylanfs> I'm thinking of the CMP data and older homebrew
      <[Arch_2nd]thpr> A few answers to that:
      <[Arch_2nd]thpr> (1) Any changes I hope to make in 5.13 or 5.15 are
      in the wiki. Anything not mentioned there is syntax frozen
      <[Arch_2nd]thpr> (2) With respect to CHOOSE in particular
      (the biggest open item), much of that can remain unchanged
      <[Arch_2nd]thpr> oh, (1a) any 5.15 changes are fully automated
      <[Arch_2nd]thpr> and thanks for the reminder - I meant to bring this
      up...
      <[Arch_2nd]thpr> With respect to conversion, are we doing prettylst
      as the official converter?
      <[Code_SB]jdempsey> We might add that as a topic at the end too. I
      think it needs discussion
      <[Arch_2nd]thpr> If we don't want to go that direction, we can look
      at other things
      <[Arch_2nd]thpr> But if we dont' do prettylst as the conversion tool,
      then we may want... okay, I'll wait
      <[Code_SB]jdempsey> Last call for arch questions
      <[OGL]Nylanfs> I'd prefer something that is incoporated into the
      pcgen code base or at least run through it.
      <[Code_SB]jdempsey> Yep, we'll cover that shortly
      <[Code_SB]jdempsey> ok, content report - Eddy?
      <[Data_Second]mosat> Sorry guys, RL is hitting me hard
      right now, I've not really had a chance to even peek at things since
      last meeting.
      <[Data_Second]mosat> other than that True 20 is ready (from a data
      perspective), I'm not sure what's going on
      <[PR2nd-PL]Maredudd> I'm still working the permissions from the pubs.
      <[Data_Second]mosat> saw your note in the tracker
      <[Arch_2nd]thpr> Tir resolved at least some of the ADD: LIST issues
      <[Data_Second]mosat> I hope they know we're close to a production
      release
      <[Code_SB]jdempsey> That presumably could hold up the release
      <[PR2nd-PL]Maredudd> I didn't give them a date but I told them we
      were very close.
      <[PR2nd-PL]Maredudd> Chris seems rather short in his last note to me.
      <[Data_Second]mosat> cool, I hope they make it in
      <[PR2nd-PL]Maredudd> Pramas that is, of GR.
      <[PR2nd-PL]Maredudd> I got word back toay on Mecha vs Kaiju. They're
      in.
      <[Data_Second]mosat> great
      <[Code_SB]jdempsey> That's good news
      <[PR2nd-PL]Maredudd> Only GR and Golden Elm Media left, and I can't
      find anything on Golden Elm.
      <[PR2nd-PL]Maredudd> On MvK, The Corebookis about to be released and
      they want us to do it as well.
      <[PR2nd-PL]Maredudd> I already sent a copyof Caliphate Nights to
      Frank.
      <[PR2nd-PL]Maredudd> The full sourcebook.
      <[PR2nd-PL]Maredudd> But that has nothing to do with 5.12.
      <[Code_SB]jdempsey> Nice
      <[PR2nd-PL]Maredudd> It turns out that Paradigm Concepts has teir
      main office about thiry minutes from my house.
      <[PR2nd-PL]Maredudd> I may have to go do lunch ith them:-)
      <[OGL]Nylanfs> Privateer Press's IKCG is ready for inclusion by OGL.
      <[Data_Second]mosat> does it need a data chimp review next?
      <[OGL]Nylanfs> The mechanika creation mechanics I don't think work
      correctly, I'm looking at those
      <[OGL]Nylanfs> Well it loads without errors. :)
      <[Data_Second]mosat> do we have permissions?
      <[PR2nd-PL]Maredudd> I don't remember a note on them. I'll dig into
      it.
      <[OGL]Nylanfs> There isn't anything in the sets from them
      <[PR2nd-PL]Maredudd> brb
      <[Data_Second]mosat> like I said, I don't have a report ready, we
      should move on to the next agenda item
      <[Code_SB]jdempsey> no problems
      <[Code_SB]jdempsey> I think that covers all of the teams
      <[Code_SB]jdempsey> Next item - Loading characters from 5.10 into 5.12
      <[Code_SB]jdempsey> Tom raised this question a few days ago
      <[Code_SB]jdempsey> I've been able to load characters from 5.10 into
      the 5.11 series successfully
      <[Arch_2nd]thpr> My concern isn't the file format as much as the
      underlying data changes
      <[Code_SB]jdempsey> Yep
      <[OGL]Nylanfs> like animal companions :)
      <[Code_SB]jdempsey> Yes, but they were fixed quite promptly
      <[OGL]Nylanfs> We are going to need to start htinking about a
      character convertor like prettylst
      <[Arch_2nd]thpr> Lots of things where the data monkeys have converted
      to using variables to help homebrews, used more/different hidden
      feats, etc.
      <[Arch_2nd]thpr> I guess my question with writing a converter is
      knowing what we are converting
      <[Code_SB]jdempsey> Well, anythign that is automatically added should
      be fine as they are added to the character on load
      <[Arch_2nd]thpr> I don't know how much sense that makes, because I
      don't know how many issues there are
      <[Arch_2nd]thpr> I liked your idea James, of having people test with
      the RC and reacting from there
      <[Code_SB]jdempsey> Yes that might be best. We know that not all
      characters will be affected
      <[Arch_2nd]thpr> Might also be able to evaluate based on the LST
      files, but there have been so many changes, it probably would require
      writing a program just to do that evaluation :)
      <[Code_SB]jdempsey> Would someone have time to test a
      ranger and a monk created in 5.10? These ones have choices which we
      need to confirm coipy across ok
      <[Code_SB]jdempsey> Lets make sure the core classes load for srd and
      rsrd - that covers a large part of our audience and then we can go
      with reacting to reports
      <[Code_SB]jdempsey> How does that sound?
      <[Arch_2nd]thpr> Just open a Sev 9 support request on each class,
      then people can claim them as they have time
      <[Arch_2nd]thpr> Each is a small enough chunk that I can get to some
      of them, it will just be a matter of timing
      <[Arch_2nd]thpr> or use prios to prioritize what we should be doing,
      e.g. make Ranger and Monk 9, others <=8
      <[Code_SB]jdempsey> Yep I'l go with that
      <[Code_SB]jdempsey> So we need to do that before RC, so I'll release
      a beta in the next day or so.
      <[Code_SB]jdempsey> as I can't see us getting through all of those in
      the next day or so
      <[Arch_2nd]thpr> not happening on my end :)
      <[Code_SB]jdempsey> Any last comments on the chaaracter migration?
      <[Arch_2nd]thpr> not from me
      <[Code_SB]jdempsey> ok moving on
      <[OGL]Nylanfs> Should we ask on the CMP boards for volunteer's?
      <[Code_SB]jdempsey> Once we release the RC, yes I think we should
      <[OGL]Nylanfs> K
      <[Code_SB]jdempsey> We should do the basics ourselves though
      <[Code_SB]jdempsey> Next item is LST conversion
      <[Arch_2nd]thpr> you leading this discussion or me?
      <[Code_SB]jdempsey> Go for it Tom - means I can eat my lunch :)
      <[Arch_2nd]thpr> ok :)
      <[Arch_2nd]thpr> I know there has been concern about using prettylst
      as the converter
      <[Arch_2nd]thpr> there is concern from the data monkeys over
      supporting it
      <[Arch_2nd]thpr> and getting folks on Windows to be able to use it
      requires a perl install, which may ruffle a LOT of feathers
      <[Arch_2nd]thpr> Personally, I'm concerned about using the existing
      code base to do a conversion; I don't have a high level of trust in
      the getPCCText() methods in our current core
      <[Arch_2nd]thpr> There is a huge testing task ahead if we go that
      direction
      <[Code_SB]jdempsey> I'd agree there - the getPCC isn;t set up for
      that and has not been tested for it
      <[Code_SB]jdempsey> It also misses the objective of being data driven
      <[Arch_2nd]thpr> What do you mean by data driven?
      <[Arch_2nd]thpr> I think the discussion is Token syntax, right?
      <[Code_SB]jdempsey> One of the objectives is that the transdforms are
      not hard coded.
      <[Code_SB]jdempsey> Well, that's one aspect the other is things like
      the will/willpower conversion that happened in 5.10
      <[Arch_2nd]thpr> Afraid I'm not familiar with that one
      <[Code_SB]jdempsey> The intent was to be able to support variable
      renames etc and that those were in an input
      file
      <[Arch_2nd]thpr> but that's almost a refactoring issue, not a
      conversion issue
      <[Code_SB]jdempsey> Again this is something that prettylst already
      does I believe
      <[Code_SB]jdempsey> Yes to some extent
      <[Arch_2nd]thpr> okay
      <[Arch_2nd]thpr> 3 separate issues in my mind
      <[Arch_2nd]thpr> 1) Pure token syntax changes that are deterministic
      <[Arch_2nd]thpr> 2) Personalized token syntax changes due to items we
      can't predict
      <[Arch_2nd]thpr> 3) custom dataset changes reacting to changes in
      SRD, et al.
      <[Arch_2nd]thpr> does that capture everything you are referring to,
      James?
      <[Code_SB]jdempsey> 1 and 3 look good - not sure about #2 - could you
      provide an example please?
      <[Code_SB]jdempsey> (or a bit more explanation)
      <[Arch_2nd]thpr> Yea, thinking
      <[Code_SB]jdempsey> :)
      <[Arch_2nd]thpr> Assume #1 was built to handle the following
      transformation:
      <[Arch_2nd]thpr> Convert ADD:FEAT(y,y)z to ADD:FEAT|x|y,y
      <[Arch_2nd]thpr> whoops messed up the x and z there, but hopefully
      you get the idea
      <[Arch_2nd]thpr> Now if someone has: ADD:FEAT(y,y our converter
      from #1 might miss it
      <[Arch_2nd]thpr> This is actually legal in PCGen 5.12
      <[Arch_2nd]thpr> and AFAIK, if people are using those undocumented
      features, they get to write their own data conversion rule
      <[Arch_2nd]thpr> to your point about data driven conversion
      <[Arch_2nd]thpr> Also, we don't want CLASSES:.CLEAR to automatically
      convert, because it's magical
      <[PR2nd-PL]Maredudd> ?
      <[Arch_2nd]thpr> we want the user to choose whether that converts to
      CLASSES:.CLEARALL or both CLASSES:.CLEARALL <tab> DOMAINS:.CLEARALL
      <[Data_Second]mosat> Tom, quick question, will the new ADD syntax
      fail if used in 5.10.2?
      <[Arch_2nd]thpr> for those that missed the reason for the .CLEARALL
      change, CLASSES:.CLEAR in Spell LST files implicitly clears DOMAINS
      as well
      <[Code_SB]jdempsey> Well to be honest I wouldn't expect someone to
      write a conversion rule for their own code - I'd think they would be
      more likely to get in and change it directly
      <[Arch_2nd]thpr> which I thought was a nasty side effect, so we got
      rid of it
      <[Code_SB]jdempsey> Of course the CMP data may well be an exception
      to that
      <[Arch_2nd]thpr> okay, so if we drop #2, is the only data driven one
      #3?
      <[Arch_2nd]thpr> Unfortunately, not being a CMP customer, I don't
      have access to that data to evaulate it
      <[Code_SB]jdempsey> I think so yes - what do others think?
      <[OGL]Nylanfs> If it's undocumented it shouldn't work
      <[OGL]Nylanfs> Tom PM
      <[Arch_2nd]thpr> Barak would probably disagree with you on that :)
      <[PR2nd-PL]Maredudd> That I can buy into.
      <[Code_SB]jdempsey> Agreed - but we are in the process of digging
      ourselves out of that hole
      <[OGL]Nylanfs> No because it should be documented no matter how
      obscure it is :)
      <[Code_SB]jdempsey> and yes the CMP guys have used some undocumented
      stuff particularly for their harp? dataset
      <[Arch_2nd]thpr> okay, so let's address #1 for a moment
      <[Code_SB]jdempsey> Well there has been extensive work on the doco
      and Tom has been tightening up the syntax, so we are on our way to
      fixing that
      <[Code_SB]jdempsey> ok
      <[Arch_2nd]thpr> Having worked out thoughts on the tokens and how
      they will work in the future (6.x), I think I'm willing to back off a
      bit on the severity of deprecation
      <[Arch_2nd]thpr> If anyone read my comments on WotC's board
      yesterday, I talked about shipping a 6.0 LST parser along with 5.14
      <[Arch_2nd]thpr> I think that should be the plan
      <[Arch_2nd]thpr> So I'd suggest removing some deprecation warnings
      from 5.12 (even though Tir will want to kill me)
      <[Arch_2nd]thpr> And putting them back in for 5.14, with some caveats
      <[Arch_2nd]thpr> First, deprecation has a different "error level"
      than pure error messages, if we can parse the old syntax cleanly
      <[Arch_2nd]thpr> So what we do in 6.0 is "guarantee" 5.14
      compatibilty for well formed LST files
      <[Arch_2nd]thpr> and partial compatibility for 5.10-5.12
      <[Arch_2nd]thpr> That partial compatibility will be identified by a
      separate executable we ship with 5.14
      <[Arch_2nd]thpr> Since I can then use the 6.0 code to do
      import/export we avoid the getPCCText problem
      <[Arch_2nd]thpr> And the way my thinking has been going, this doesn't
      really hurt the load system any, as I was already looking into how to
      get multiple "backwards compatibility" tokens with the same token name
      <[Arch_2nd]thpr> That way, we are not introducing a lot of fear in
      5.12 due to the quantity of warnings people would get on load
      <[Code_SB]jdempsey> So you would use the 6.0 token load and write
      code to read in the 5.10 LST file and write
      out a 6.0 compatibile one?
      <[Arch_2nd]thpr> They only get them when they can actually see what
      it means - when we have the compatibilty exec in 5.14
      <[Arch_2nd]thpr> Effectively, yes.
      <[Arch_2nd]thpr> Some tokens will be guaranteed to fail (such as
      those that don't function in 5.10/5.12 - think UATT)
      <[Arch_2nd]thpr> But those where the syntax changed, we can define
      what the well-formed 5.12 version is and have compatibility there
      <[Arch_2nd]thpr> Thinking ADD:, AUTO:, REMOVE, CHOOSE in particular
      <[Arch_2nd]thpr> By deferring the issue to 5.14, we also get some
      time to develop that compatibility and test it vs. CMP and some
      homebrew datasets.
      <[Code_SB]jdempsey> OK, so rather that doing a converter for these in
      5.12 we back away from deprecating them as we aren't going to be
      dropping them from 5.14 anyway
      <[Arch_2nd]thpr> correct
      <[Code_SB]jdempsey> Sounds interesting and doable - Eddy
      how is this all sounding to you?
      <[Data_Second]mosat> difficult to follow ;p
      <[Code_SB]jdempsey> :)
      <[Arch_2nd]thpr> So should that be the plan of record for #1?
      <[Data_Second]mosat> I've actually got to sign off now, sorry I've
      not been much help tonight.
      <[Code_SB]jdempsey> Eddy, I think the core idea is that rather than
      deprecating so much in 5.12, as we now have a 5.14 where it will be
      supported anyway we silence the deprecations until then
      <[Code_SB]jdempsey> no probs - thanks for coming along
      <[Data_Second]mosat> sounds good
      <[Data_Second]mosat> night all
      <[Code_SB]jdempsey> cya
      * [Data_Second]mosat has left #pcgen
      <[Arch_2nd]thpr> Okay, #3
      <[Arch_2nd]thpr> That's more of a challenge :)
      <[Arch_2nd]thpr> It also can't be deferred, I suspect
      <[Arch_2nd]thpr> because so many data changes happened in 5.10/5.12
      <[Arch_2nd]thpr> especially with variables
      <[Arch_2nd]thpr> I also haven't thought about it much - I didn't
      really realize what the data driven converter meant until about 30
      minutes ago :P
      <[OGL]Nylanfs> :)
      <[Code_SB]jdempsey> That's fair enough - it hasn't been heavily
      discussed despite being fairly important
      <[OGL]Nylanfs> Okay I should be getting off to bed also. Somebody
      don't forget to post the log to the BoD and main list.
      <[Arch_2nd]thpr> Let's take this one to -devel
      <[Arch_2nd]thpr> Not going to try to solve it on the fly
      <[Code_SB]jdempsey> no problems Tom
      <[Code_SB]jdempsey> ok, so was there anything else to discuss? If not
      we can close the meeting
      <[Arch_2nd]thpr> If that's it, we can still make Paul post the log :D
      <[PR2nd-PL]Maredudd> I have a question concerning the docs, or more
      specifically the Ability File page.
      <[Code_SB]jdempsey> yep
      <[OGL]Nylanfs> Also James, I talked to an old code
      monkey. Oddmage He might be hitting you up.
      <[Code_SB]jdempsey> As in coming back to the team?
      <[OGL]Nylanfs> Yep :)
      <[Code_SB]jdempsey> Excellent
      <[OGL]Nylanfs> What was your question Eric?
      <[PR2nd-PL]Maredudd> The current Ability File page file is located in
      the globaltagfile file directory. As I understand it, the tags are
      used only in the Ability File, so the whole thing should probably be
      moved to the datatagfile directory. Any thoughts?
      <[Arch_2nd]thpr> I think you're correct in that
      <[Arch_2nd]thpr> in moving it
      <[OGL]Nylanfs> If they are only used with the Ability tag I'd agree
      with that statement
      <[Code_SB]jdempsey> The ABILITY tag is global
      <[OGL]Nylanfs> There should also be a push to identify with "global"
      tags are truely global and what ones can be used with mutiple items
      <[PR2nd-PL]Maredudd> There is a global ABILITY tag, but there are
      about 9? tags that are specifically listed as for the Ability File.
      <[Arch_2nd]thpr> He's referring to things like CATEGORY and MULT ...
      yea , taht
      <[Arch_2nd]thpr> not global
      <[PR2nd-PL]Maredudd> Is that correct?
      <[PR2nd-PL]Maredudd> Tha is correct Tom. Those tags.
      <[Code_SB]jdempsey> Hmm, I am having troubles finding those. I think
      the autobuild didn't run last night so the published docs don't have
      your latest changes included
      <[OGL]Nylanfs> It should be noted in the gobal tags that ability is
      global with associated tags in the datatag file
      <[Arch_2nd]thpr> look under FEAT, James
      <[OGL]Nylanfs> Cool Meebo has chat rooms now
      <[PR2nd-PL]Maredudd> Try here:
      http://pcgen.svn.sourceforge.net/viewvc/*checkout*/pcgen/Trunk/pcgen/d
      ocs/listfilepages/globalfilestagpages/globalfilesability.html
      <[Arch_2nd]thpr> While James is looking, Paul, to your point on
      Global vs. Limited...
      <[Code_SB]jdempsey> Yes it looks like it belongs in the specific tags
      folder to me. The global and gamemode
      entries just refer to the relvant files
      <[Arch_2nd]thpr> I think that's noble, but due to how complicated the
      code is, I'm afraid to do it right now... those relationships are
      very subtle based on where certain triggers in the code are located
      <[PR2nd-PL]Maredudd> Thats what I thought.
      <[Arch_2nd]thpr> It took hours and hours just to check token syntax
      in the docs, and that was mosly browsing the token code
      <[Arch_2nd]thpr> the rules also change when we get to 6.0 - most of
      those limited file restrictions on the global tags will all change...
      so not sure it returns on the effort
      <[Arch_2nd]thpr> to do it today
      <[OGL]Nylanfs> Yes, but what I was thinking is that a doc tracker
      monkey should poll the senior data monkeys on the global tags listed
      and find out from them which ones are semi-global and which ones are
      truely, in their experience At least it give a better baseline
      <[OGL]Nylanfs> It might not be totally accurate, but it's a good
      start.
      <[Code_SB]jdempsey> I think just doing CHOOSE would be a huge
      benefit - even if it only applies until 6.0 comes out
      <[Arch_2nd]thpr> Point on CHOOSE, James.
      <[Code_SB]jdempsey> That one is causing some real confusion amoungst
      LST coders
      <[Arch_2nd]thpr> ...and if the data monkeys can identify a handful of
      specific questions, we can check those. An exhaustive review of all
      global tokens is too much
      <[Arch_2nd]thpr> can someone create a doc tracker for the CHOOSE item
      <[Code_SB]jdempsey> Does that cover the question Eric?
      <[PR2nd-PL]Maredudd> Yes. I'll set out my plan for the move of the
      file and make it happen.
      <[Code_SB]jdempsey> It might be there already as Tir raised the same
      point - I was just reiterating it
      <[Code_SB]jdempsey> ok, anything else? We are almost at 2 hours now
      <[Arch_2nd]thpr> ok, I'll check and create one if not
      <[Code_SB]jdempsey> Thanks Tom
      <[Arch_2nd]thpr> ok, sleep for me, I have early morning
      commitments
      <[OGL]Nylanfs> K grabbing log
      <[PR2nd-PL]Maredudd> nite
      <[Code_SB]jdempsey> Thanks for attending everyone
      <[Code_SB]jdempsey> nite all
      <[Arch_2nd]thpr> 'night all
    Your message has been successfully submitted and would be delivered to recipients shortly.