Meeting 2015 01 02

PCGen Meeting for January 2nd, 2015

Attendance

• Tom P. [Arch]
• Andrew M. [Content/Chair]
• Paul G. [PR]
• Stefan R. [OS 2nd]
• Douglas L. [Data 2nd]
• Jeff
• Andrew W.
• David B.

Summary

• ACTION ITEM: (Stefan assigned) - Update WIKI to reflect best practices for GIT and GITHUB per PCGen standards.
• Unknown ETA for CI by Jenkins on the pcgen main repo. James to handle.
• Long discussion regarding the GIT workflow - how-to do PRs, how to operate the git clients, etc.
  • Tom: Requesting we focus on one project approved tool "How To" aid.
  • Was mentioned that we had a data contributor push to the SVN. Locking or leaving unlocked discussed. UPDATE: PER JAMES - SVN is now READ-ONLY.
• Release Plans: (Pending James' confirmation) Anticipated June/July release of 6.6 pending confirmation and schedules involved.
• Active Projects for Release cycle 6.6:
  • TOM: FACT/FACTSET integration - active work currently
  • TOM: FORMULA PARSER - Unconfirmed pending Time Frame for release schedule of 6.6 and previous project work of FACT/FACTSET
  • ANDREW M.: Pathfinder Book: Mythic Adventures
  • ANDREW M.: Work on Data/OS side of the proposed projects with Tom
  • ANDREW W. & DOUGLAS: Pathfinder Book - Advanced Class Guide
  • JAMES: Pending Confirmation from James - LST Editor

Raw Log

• [15:00] <@[Chair]Andrew> *Bangs gavel*
• [15:01] <@[Chair]Andrew> Welcome all to the PCGen Board of Directors meeting January 2nd, 2015 - first meeting of the year. Our agenda is as follows:
• [15:01] <@[Chair]Andrew> (1) Post transition SVN to GIT issues and updates? (Arch, Code and Content)
• [15:01] <@[Chair]Andrew> (2) Planned 6.5 roadmap Release Schedule (Release)
• [15:01] <@[Chair]Andrew> (3) Current planned Roadmap Items (All Teams)
• [15:01] <@[Chair]Andrew> (4) Open Forum
• [15:02] <@[Chair]Andrew> I'll begin with #1.
• [15:02] <@[Chair]Andrew> We've successfully migrated our main operations to the GITHUB. James has not gotten Jenkins set up to do our CI and autobuilds on the GITHUB yet, no ETA given either.
• [15:03] <@[Chair]Andrew> The expected rocky transition for the teams went as well as could be expected. Learning new interfaces and processes.
• [15:04] <@[Chair]Andrew> For the content side, since we had a head-start with newsources, the transition went smoothly, just a few monkeys who needed a bit of a hand to get up and running. :)
• [15:05] <@[Chair]Andrew> Tom, representing Arch and Code, any issues or areas of concern regarding the transition?
• [15:06] <Tom[Arch_SB]> Not necessarily concern. I think there is just learning on the new workflow for everyone, and we will want to clean up our docs about how we would like folks to contribute (i.e. use PRs)
• [15:07] <Tom[Arch_SB]> I'm finding the "auto fast forward" is VERY touchy
• [15:07] <Tom[Arch_SB]> and so still only successful about 50% of the time of avoiding a merge commit
• [15:08] <Tom[Arch_SB]> that's my observations so far
• [15:09] <@[Chair]Andrew> Sounds good. Any other members wish to chime in?
• [15:09] <@[Chair]Andrew> (or questions before moving forward)?
• [15:10] <[OGL]Nylanfs> I'm still wrestling with getting my workflow understood in Git, but that's just me :)
• [15:10] <Distant_Scholar> I would like clear, jargon-free, step-by-step instructions (with examples) on how to deal with git, because it's kicking my butt.
• [15:11] <Distant_Scholar> Apparently, (or so I heard recently), one is only supposed to do one pull request per issue? So only one pull request for an entire new source? Am I understanding that correctly?
• [15:11] <@[Chair]Andrew> Okay, jargon free might be a tall order, but we can definitely work on making it lay person understandable.
• [15:11] <Distant_Scholar> How would two people work on the same new source?
• [15:12] <Tom[Arch_SB]> I think the key thing is we will need to pick a tool and document it
• [15:12] <@[Chair]Andrew> Newsources aren't required to use branches, different beast.
• [15:12] <Tom[Arch_SB]> right now we have different team members on different tools, so we can't build the docs that way
• [15:12] <Tom[Arch_SB]> folks will get overly confused
• [15:12] <Tom[Arch_SB]> but we probably need James for that discussion
• [15:13] <Tom[Arch_SB]> so we can figure out what he is using
• [15:13] <Distant_Scholar> Andrew: Why and how are newsources different?
• [15:13] <@[Chair]Andrew> So, consensus - better documentation - check.
• [15:15] <@[Chair]Andrew> distant_scholar - in a nutshell, easier work flow. Newsources are worked on by multiple people with different areas of focus, branched PRs are fine, but at this point, not an absolute requirement. As opposed to our main development which is one person to an issue typically, and we have a bunch of different issues.
• [15:15] <Tom[Arch_SB]> I'm actually still confused though
• [15:16] <Tom[Arch_SB]> Wouldn't you want a new source entirely done in a branch?
• [15:16] <Tom[Arch_SB]> or in another repository, and then brought in via one PR?
• [15:17] <@[Chair]Andrew> Multiple thoughts on it. When migrating, we kept the all purpose model, but we can look at doing it by branch or repo... though by repo might be a bit much.
• [15:17] <@Zaister> since each source is its own directory with no influence on other sources, there's not really a need for branching
• [15:18] <Tom[Arch_SB]> Except I disagree
• [15:18] <Tom[Arch_SB]> we have tests that check the entire repository for missing files, et al
• [15:18] <Tom[Arch_SB]> So a half-complete source is an issue
• [15:18] <Tom[Arch_SB]> given the structure of git, the HEAD really should be clean
• [15:18] <@Zaister> We'r talking about the newsources, right?
• [15:19] <@[Chair]Andrew> Those tests are applied to the main pcgen repo, not newsources which is considered a work in progress.
• [15:19] <Tom[Arch_SB]> I'm still not sure what the model is
• [15:19] <Tom[Arch_SB]> Newsources is a separate repo? and then.... how are things brought into the main repo?
• [15:19] <Tom[Arch_SB]> one PR?
• [15:19] <@[Chair]Andrew> newsources is it's own separate repo.
• [15:19] <@[Chair]Andrew> Basically a squash commit dump. :P
• [15:20] <Tom[Arch_SB]> so one PR when the new source is complete
• [15:20] <@[Chair]Andrew> i.e. removed from newsources and added to pcgen.
• [15:20] <@[Chair]Andrew> Can't do a PR Tom.
• [15:20] <@[Chair]Andrew> Repos don't share a common ancestor
• [15:21] <@[Chair]Andrew> i.e. NewSource is not a fork of pcgen. It's a separate entity.
• [15:22] <Tom[Arch_SB]> I'm still not sure we are all on the same page for workflow
• [15:22] <Tom[Arch_SB]> I thought everything was a PR
• [15:23] <@Zaister> once its in the main repo
• [15:23] <@[Chair]Andrew> There isn't much concern for the history since it's being created, and we get some that are dumped in newsource as complete - case in point, Zaister's AP, or some are done piecemeal - case in point Advanced Class Guide. So, dumping it in PCGen it's basically history free.
• [15:23] <Tom[Arch_SB]> so if that means you need to put it into your fork and then PR it into the main, then that's the way it would happen
• [15:24] <@[Chair]Andrew> Is everyone signed up for the new commit list?
• [15:25] <Tom[Arch_SB]> I'm confused about the workflow still
• [15:25] <Tom[Arch_SB]> not sure what that has to do with the commit list
• [15:25] <Tom[Arch_SB]> I think we need to clearly write down the expected workflow so everyone can see it
• [15:25] <Tom[Arch_SB]> right now it seems like a bit of fly-by-the-seat-of-the-pants
• [15:26] <@[Chair]Andrew> I'm not sure if we'd decide whether to have the maintainers do PRs, but for the non-maintainers - contributions use the PR method.
• [15:27] *** PapaDRB has quit IRC: Quit: ~ Trillian Astra - www.trillian.im ~
• [15:28] <Tom[Arch_SB]> That's why we write it down. So people have the discussion and become sure
• [15:28] <[OGL]Nylanfs> Work flow should be exactly like it was with the addition of a PR (which needs added to the JIRA) by the Silverback
• [15:28] <[OGL]Nylanfs> Right?
• [15:30] <Distant_Scholar> That hasn't been my experience.
• [15:31] <@[Chair]Andrew> @Paul - We need to add PR submitted or something to that effect to the JIRA and then PR accepted to the JIRA. Since we can't say something is resolved when it's waiting to be reviewed, so in the regards, you are correct.
• [15:32] <@[Chair]Andrew> For the Newsources we aren't moving the JIRA forward till the set his it's milestone - i.e. completed.
• [15:32] <@Zaister> I see it like this: 1) create branch on local repo. 2) work, then commit. 3) repeats (2) until finished. 4) push to fork on github. 5) create PR. 6) when PR is merged, delete locale branch
• [15:33] <@[Chair]Andrew> @Zaister - Yes, that's how the normal GIT workflow should go.
• [15:33] <@Zaister> 7) pull changes from PCGen/pcgen into local repo master branch
• [15:35] <@[Chair]Andrew> Action Item: Add more concise documentation for GIT Workflow.
• [15:35] <Tom[Arch_SB]> @Andrew: Is there a not normal GIT workflow we are doing in any situation?
• [15:35] <Distant_Scholar> I'm speaking more from the point of view of a long-term issue, like a new source, but it could happen with any issue ...
• [15:35] <@[Chair]Andrew> Just newsource, but we can change that.
• [15:35] <Distant_Scholar> What if someone else's change affects what one is working on? ...
• [15:36] <@Zaister> Distant_Scholar: same thing as with svn, someone will have do merge the files
• [15:36] <@[Chair]Andrew> Conflict will be caught by github and won't allow a merge. Requires manual intervention at that point.
• [15:36] <Distant_Scholar> Let me try this step-by-step:
• [15:36] <Distant_Scholar> 1.) I create a "fork" for the Advanced Class Guide.
• [15:37] <@Zaister> branch, not fork!
• [15:37] <Distant_Scholar> OK, I can't even get one step right. I give up.
• [15:37] <@Zaister> Distant_Scholar: are you now talking about the nesources repo?
• [15:37] <@[Chair]Andrew> Fork = Repo Copy
• [15:37] <[OGL]Nylanfs> I think he's talking about starting from scratch Stefan
• [15:38] <@Zaister> Distant_Scholar: every developer should have his own fork of the main repo on github
• [15:38] <@Zaister> so, I have Zaister/pcgen and Zaister/pcge-newsources, since I work on both
• [15:39] <@Zaister> I push my changes to these repositories only, and the maintainers, ie. James and Andrew merge them into the main repos with PRs
• [15:41] <@Zaister> On pcgen-newsources, branches aren't strictly necessary since each source is independent from the others while in development, but I don't think it's bad practice to use them
• [15:42] <@[Chair]Andrew> A "branch" is basically your own sandbox to make the changes you want without affecting the rest of the items. It has only the changes i.e. commits, that you make. Then by pushing those to your repo "fork" you are asked if you want to submit a PR to the upstream. Only those isolated commits are requested, keeping the PR small.
• [15:43] <@Zaister> we should make it best practice to keep commits atomic
• [15:43] <@Zaister> i.e. don't put twio fixes in a single commit
• [15:44] <@[Chair]Andrew> Agreed. Makes issue tracking much easier.
• [15:44] <@Zaister> makes for better history, and commits don't cost anything, they don't even "cost" revision numbers
• [15:44] <Tom[Arch_SB]> I mostly agree
• [15:45] <Tom[Arch_SB]> However, there are times when there are a lot of interacting issues, like when I redid how abilities are processed and fixed like 12 issues at once
• [15:45] <Tom[Arch_SB]> So in those cases, it was as atomic as it was going to get
• [15:45] <@[Chair]Andrew> Related issue...
• [15:45] <@Zaister> that's ok
• [15:45] <@[Chair]Andrew> We're talking about not putting unrelated fixes in one commit.
• [15:45] <@Zaister> it shouldn't be dogmatic, just best practice
• [15:45] <Tom[Arch_SB]> just making sure it's clear for those following along at home
• [15:46] <@Zaister> pushing to the fork, though, can be done in bulk, but PRs should be made only with things that are part of the same issue
• [15:47] <@[Chair]Andrew> So, for those following along, a Branch should be one issue, and may contain as many related commits to that issue. Separate issues should be in separate branches for submission by PR.
• [15:47] <@Zaister> and... it's ok to commit unfinished stuff. committing something very different then in svn
• [15:47] <Tom[Arch_SB]> unfinished as long as it's in a branch and pre-PR
• [15:48] <@Zaister> probably even pre-push
• [15:48] <@Zaister> just for local convenience
• [15:48] <Tom[Arch_SB]> fair enough
• [15:48] <@[Chair]Andrew> commit = take a snapshot of my work. push = make this public by pushing it to a remote location.
• [15:49] <@[Chair]Andrew> Zaister - you up to handling the documentation aspect of this action item?
• [15:49] <@Zaister> I think so
• [15:49] <Distant_Scholar> Let me see it when you're done, and I
• [15:50] <Distant_Scholar> will point out all the things that you think are clear that I don't. :-)
• [15:50] <@Zaister> So say, if Tom fixes a bug I need for my work, he pushes that out to his fork and creates a PR. Now who knows when James has time to merge, but I can still get Tom's cody from HIS fork even though it's not in the main repo yet.
• [15:50] <@Zaister> Distant_Scholar: good idea :)
• [15:51] <@[Chair]Andrew> Thanks. Let's take the continued issues for this topic to one of the lists and move forward, I have a couple more agenda items, and people tend to want to leave after an hour (which is in 9 minutes) :P
• [15:51] <@Zaister> ok
• [15:51] <@[Chair]Andrew> (2) Planned 6.5 roadmap Release Schedule (Release)
• [15:52] <@[Chair]Andrew> This would be the Admin and Release 2nd. I don't have any word from James on this outlook. Tabling this for his comments when he can.
• [15:53] <@[Chair]Andrew> We do have 6.5.0 out, so we aren't in any rush to release. And I'm figuring we'll get Jenkins back up prior to any official releases to have proper public feedback per normal.
• [15:53] <@[Chair]Andrew> Any questions?
• [15:53] <Tom[Arch_SB]> nope
• [15:53] <@[Chair]Andrew> (3) Current planned Roadmap Items (All Teams)
• [15:53] <@Zaister> One more thing: we should set the SVN repo to read-only now, I saw a commit earlier today, that will probably go nowhere.
• [15:54] <@[Chair]Andrew> @Zaister - we contacted and corrected.
• [15:54] <@Zaister> good
• [15:54] <@[Chair]Andrew> Might be best to leave svn on so we can redirect the monkeys who didn't get the message.
• [15:55] *** Nuance has joined #pcgen
• [15:55] <@[Chair]Andrew> Failing to commit is frustrating... since there wouldn't be a clear reason why it failed
• [15:55] <@Zaister> hm
• [15:56] <Tom[Arch_SB]> I'm kind of with Andrew on this one. Better to have it work and be corrected than just fail
• [15:56] <@Zaister> Ok then
• [15:56] <Tom[Arch_SB]> not forever, but for some reasonable period of time
• [15:56] <@[Chair]Andrew> *nod* yes, a couple of months should be sufficient.
• [15:57] <@[Chair]Andrew> Okay, Tom - I think we know what you have planned for 6.6, but for those following at home, can you outline your anticipated projects for inclusion in 6.6?
• [15:57] <Tom[Arch_SB]> Without knowing the schedule....
• [15:57] <Tom[Arch_SB]> I think it's best just to say where I'm focused right now
• [15:58] <Tom[Arch_SB]> which is on FACT/FACTSET and revising output (using FreeMarker rather than our traditional output tokens)
• [15:58] <Tom[Arch_SB]> There is a separate branch (OutputFact) in my respository (thpr/PCGen) which contains the working code
• [15:59] <Tom[Arch_SB]> This implements FACT and FACTSET as documented here: http://wiki.pcgen.org/FACT_Token http://wiki.pcgen.org/FACTSET_Token
• [15:59] <Tom[Arch_SB]> Andrew has already been doing some testing to work out the rust
• [16:00] <Tom[Arch_SB]> As that progresses, we will get into a discussion of which tokens we can retire
• [16:00] <Tom[Arch_SB]> since some will be superfluous once those are in the main repository
• [16:01] <@Zaister> I saw you closed a hundred old NEWTAG requests :)
• [16:01] <Tom[Arch_SB]> Other than a few file types (Ability probably the major one) it is fully implemented
• [16:01] <Tom[Arch_SB]> yes, I closed a bunch of NEWTAG requests that are moot based on the proposals
• [16:01] <Tom[Arch_SB]> It actually isn't even a complete list, others will be closed as well... those were just the easy to find ones.
• [16:02] <@[Chair]Andrew> (only 55 by my count...)
• [16:02] <Tom[Arch_SB]> lots, suffice it to say
• [16:02] <@[Chair]Andrew> Yes, a lot... nice chunk to remove.
• [16:04] <@[Chair]Andrew> Anything else Tom?
• [16:04] <Nuance> You closed at least one that I thought might not be replaceable with a FACT. "Pilot's DEX modifier" seems like it's a property of the pilot and dynamic.
• [16:04] <Tom[Arch_SB]> Hee hee, Andrew M caught that too
• [16:05] <@Zaister> yes but it its a function of the character, why would we need a tag in the first place?
• [16:05] <Tom[Arch_SB]> Either we can reopen or we can say it will be a variable in the new system and leave it closed :)
• [16:05] <Nuance> than I thought it's probably going to be a local variable
• [16:05] <Tom[Arch_SB]> yes, that :)
• [16:05] <Nuance> so I didn't bring it up on the list
• [16:05] <@[Chair]Andrew> Yes, several will actually be vars in the new system.
• [16:06] <Tom[Arch_SB]> Anyway, very interested for folks to try it out and see what they think
• [16:07] <Tom[Arch_SB]> that's it from me
• [16:07] <Nuance> Are local variables in scope for 6.6?
• [16:07] <Tom[Arch_SB]> maybe
• [16:07] <Tom[Arch_SB]> depends on the schedule and how many holes get found in FACT/FACTSET
• [16:07] <Tom[Arch_SB]> I hope so
• [16:07] <Tom[Arch_SB]> ...but one can't be sure
• [16:07] <Nuance> GOOD :=)
• [16:08] <Nuance> oops shouty
• [16:08] <Tom[Arch_SB]> Andrew has also been testing that out based on the svn sandbox, and finding some issues
• [16:09] <Tom[Arch_SB]> so it is going to take some time to work through those details and get it polished
• [16:09] <Tom[Arch_SB]> but I want to guarantee one project, and that's FACT/FACTSET since it's further cooked
• [16:10] <Tom[Arch_SB]> ok, back to you Andrew
• [16:10] <Nuance> will we have a way to convert the data of things retired by FACT, or is it manual?
• [16:11] <Tom[Arch_SB]> actually that's a good discussion
• [16:11] <Tom[Arch_SB]> Conversion actually has some quirks to it, but I think it can be made into something reasonable
• [16:12] <Tom[Arch_SB]> What we can do is provide a file that says: Here are FACT/FACTSET definitions as (pseudo-)implemented in the current code and thus required by "old" tokens
• [16:12] <Tom[Arch_SB]> The user would then be responsible for putting that as a DATACONTROL: file in their PCC if they intend to use the old tokens
• [16:13] <Tom[Arch_SB]> once loaded with that and written by the converter, it would write FACT/FACTSET out and thus the DATACONTROL file would make a whole lot more sense
• [16:13] <Nuance> ooh, sneaky. I like it
• [16:13] <Tom[Arch_SB]> Is that reasonable to folks?
• [16:13] <@[Chair]Andrew> Sounds great to me.
• [16:13] <Tom[Arch_SB]> ok
• [16:13] <@Zaister> do you have an example of existing things that will fall by the wayside due to this?
• [16:13] <@[Chair]Andrew> SOURCEPAGE
• [16:13] <Tom[Arch_SB]> Deity's SYMBOL is probably the poster-child for it
• [16:14] <Tom[Arch_SB]> SOURCEPAGE not so much
• [16:14] <Tom[Arch_SB]> there is some magic there
• [16:14] <Nuance> deity's alignment
• [16:14] <Tom[Arch_SB]> so we need to be careful about what the code depends upon
• [16:14] <@Zaister> hm ok
• [16:14] <@[Chair]Andrew> ABB is magic, but once decoupled, it'd be a candidate
• [16:14] <Tom[Arch_SB]> the main problem is that we have various ways of writing out sources, and they pull on SOURCEPAGE
• [16:15] <Tom[Arch_SB]> so a LOT more code changes (and code being tied to a specific FACT, which I wouldn't like)
• [16:15] <Tom[Arch_SB]> so it's going to be a one-by-one thing of working between code and data to do them
• [16:15] <Nuance> what multiple ways?
• [16:15] <@Zaister> I can see deity's symbol, but alignment seems to be integrated
• [16:15] <Nuance> integrated?
• [16:16] <Tom[Arch_SB]> pcgen.cdom.enumeration.SourceFormat to be specific
• [16:16] <@Zaister> yes, for example a clerics access to spells is regulated by his deity's alignment
• [16:16] <@Zaister> the symbol is just a text, but the alignment carries meaning in PCGen
• [16:17] <Nuance> Does that mean it has similar problems to SOURCEPAGE?
• [16:18] <@[Chair]Andrew> As Tom said, it'll be a one-by-one tag process.
• [16:18] <Nuance> Data/Code interaction
• [16:18] <Tom[Arch_SB]> I am not sure it does
• [16:18] <Tom[Arch_SB]> PREDEITYALIGN I think is the controlling mechanism, which would convert to PREFACT
• [16:18] <@Zaister> I'm just wondering why did you pick up deity's alignment out of all our tags?
• [16:18] <@Zaister> why not, say spell school
• [16:18] <Nuance> it's something about the Deity that does NOT change
• [16:19] <Nuance> ever!!!!
• [16:19] <Tom[Arch_SB]> I'm not sure we want to dwell on details of given tokens here
• [16:19] <Tom[Arch_SB]> seems like that's a bit of a tangent to progressing the meeting
• [16:19] <Nuance> sorry
• [16:19] <@[Chair]Andrew> Yes, let's move on.
• [16:19] <@[Chair]Andrew> For the Content Team - I'm anticipating a 6.6 release for June/July - which is roughly a 4 month development cycle, pending confirmation with James and his personal schedule of course.
• [16:19] <@[Chair]Andrew> I plan on finishing up Mythic Adventures (80% complete), and any bug clean up or Freqs I can do.
• [16:19] <@[Chair]Andrew> I anticipate being busy syncing to Tom's work in the OS and Data areas. Once he goes full throttle with the project.
• [16:19] <@[Chair]Andrew> I'm also going to be less available in 10 days due to college/university.
• [16:20] <Tom[Arch_SB]> @Nuance: no worries
• [16:20] <Distant_Scholar> Is the tag editor still on the table for 6.6?
• [16:21] <@[Chair]Andrew> That was a James project, but he isn't here to answer if that's still a go.
• [16:21] <@[Chair]Andrew> Does anyone else have projects they anticipate including in PCGen for 6.6?
• [16:22] <@[Chair]Andrew> Books, NewTags, Features/Improvements
• [16:22] <Nuance> Paizo's Advanced Class Guide would be good to get in
• [16:22] <Nuance> I'm working on it ATM
• [16:22] <Distant_Scholar> Finishing ACG is my intention.
• [16:23] <@[Chair]Andrew> Distant Scholar and Nuance are tackling the ACG, anyone else?
• [16:25] <@[Chair]Andrew> If I can ask the teams to review the JIRA project trackers. We have several requested issues and bugs that could always use attention.
• [16:26] <@[Chair]Andrew> Also, if you're assigned to an issue but don't think you'll complete it or intend on completing it within the next 8 months, please un-assign yourself (unless it's a special project that only you can handle).
• [16:27] <@[Chair]Andrew> That's it from me, any questions or comments before I close us out?
• [16:27] <Swiftbrook> Just to be clear for all us occasional contributors … GIT/GITHUB is new location for the program and files, but we still use JIRA for tracking and reporting issues, correct?
• [16:27] <@[Chair]Andrew> Correct on both counts.
• [16:30] <@[Chair]Andrew> *bangs gavel* Thanks for coming everyone! Meeting is adjourned.