Dev Meeting Log 20121103

Below is the log of our developer IRC chat on Saturday night/Sunday morning. The focus was what we would like to do for the 6.1 cycle.

Summary

• Tom - Core Cleanup
• Javier - Client/Server PCGen
• Devon - Quick tasks (e.g. tag cleanup), text parsing of sources, investigate GIT
• James - Remove old UI code, FreeMarker output, start looking at LST editor
• 6-9 month cycle with branches used for larger projects

Actions

• None

Transcript

(10:03) James[Code_SB]: Let's start
(10:03) [Arch_SB]thpr: I'll note I did manage to have a discussion mid day with Javier on his stuff, so he's here by some level of proxy
(10:04) James[Code_SB]: That's good to hear - it sounds like he has some big plans
(10:04) James[Code_SB]: What I wanted to chat about is what people wanted to volunteer for for the 6.1 cyle
(10:05) devonjones: what is the expected length of the 6.1 cycle?
(10:05) James[Code_SB]: Once we have an idea of the code team POV we can see what other work is desired by other teams and see what is doable
(10:05) James[Code_SB]: I was thinking 6-9 months
(10:06) James[Code_SB]: I really do not want to exceed a year
(10:06) James[Code_SB]: 5.16.4 to 6.0 will end up around 2 years due to two very large projects going on
(10:07) [Arch_SB]thpr: which got us in trouble on Java currency
(10:07) James[Code_SB]: yeah
(10:07) James[Code_SB]: and the cycle looks like it is speeding up now too
(10:08) James[Code_SB]: I think many of our regular users have already jumped to the 5.17 releases as a result too
(10:09) James[Code_SB]: but found it disruptive to have a new version out every two weeks :)
(10:09) James[Code_SB]: So with a shorter cycle I think we'll better match what people expect as far as releases
(10:10) James[Code_SB]: So is everyone happy with that approach to the meeting?
(10:10) [Arch_SB]thpr: yep... you're in charge :)
(10:10) James[Code_SB]: Who would like to start?
(10:11) [Arch_SB]thpr: I can start

Tom

(10:11) [Arch_SB]thpr: My primary focus will be finishing the core cleanup to stop cloning and have consistent behavior across the objects. Since that's primarily Ability objects at this point, that would be the focus area
(10:12) [Arch_SB]thpr: once done, that provides a huge side effect of cleaning up much of pcgen.core
(10:12) [Arch_SB]thpr: Secondary project if it can fit is probably cleanup up languages. I think Javier will need that for his project
(10:13) [Arch_SB]thpr: Oh, the cleanup there is that we can have 2 languages with the same key today, and that can cause some issues
(10:13) James[Code_SB]: That's languages such as Common I assume?
(10:13) [Arch_SB]thpr: yes
(10:13) [Chair]Andrew: If I may
(10:13) [Chair]Andrew: Modern was cleaned up to not have the same KEY
(10:14) ***[Chair]Andrew got tired of the duplicate messages.
(10:15) [Arch_SB]thpr: ok, then we should decide if we start to withdraw support for duplicate keys
(10:15) [Arch_SB]thpr: on Languages. Because I think the system allows that as an exception to "normal" behavior today
(10:15) [Arch_SB]thpr: So deprecate in 6.2 and remove 6.4 (or perhaps it forces a 7.0 vs 6.4 based on that, not sure)
(10:16) James[Code_SB]: Code name 6.4 for now perhaps? :P
(10:16) [Arch_SB]thpr: would anyone have concerns with that?
(10:16) [Arch_SB]thpr: sure
(10:16) James[Code_SB]: I'm in favour of reducing exceptions
(10:17) [Chair]Andrew: Agreed
(10:17) [Arch_SB]thpr: ok, so I'll take on making that capability deprecated in 6.2
(10:17) James[Code_SB]: I have a suspicion that the UI might not cope well with duplicates anyway - it isn't something I have tested with
(10:17) [Arch_SB]thpr: k
(10:18) [Arch_SB]thpr: That's the scope I was planning to focus on
(10:18) [Arch_SB]thpr: questions or comments?
(10:19) [Arch_SB]thpr: Should I cover Javier's stuff next?
(10:20) James[Code_SB]: None from me - that sounds good
(10:20) James[Code_SB]: Sure

Javier

(10:20) [Arch_SB]thpr: So Javier is looking at effectively making PCGen handle client/server capabilities, meaning the PC can be on a central server, and a remote client updating that PC
(10:20) [Arch_SB]thpr: HE is already familiar with a Java mechanism to do that type of update, so that is not an issue
(10:21) [Arch_SB]thpr: Size also doesn't seem to be a big deal, it's smaller than most of the libraries we already have, and only a few 100K
(10:21) [Arch_SB]thpr: General idea is the server is the master (if not only) copy of the PC and sends change requests out to the client (e.g. pick a feat) to be addressed
(10:22) [Arch_SB]thpr: there will need to be discussion about whether any data is local on the client (tradeoff is less network traffic vs. having to handle inconsistencies between data)
(10:22) [Arch_SB]thpr: It also is sending data in a serialized form between the two endpoints, so may take some work to ensure that comes out right
(10:23) [Arch_SB]thpr: especially with some of the enumerations we have and ensuring those are properly reconstructed at the destinatoin
(10:23) [Arch_SB]thpr: He didn't seem too concerned about it and was planning to look into setting up a small demo to show the function works (to the first order)
(10:24) devonjones: I'm going to suggest that making a server side PCGen is probably not going to finish in 6-9 months, so you may not want this to block on this cycle
(10:24) devonjones: or consider putting server side into it's own project that can be released on it's own timeline
(10:24) [Arch_SB]thpr: the work needs to go into a sandbox
(10:25) James[Code_SB]: Yeah that's why I was thinking of wider use of branches this time around so we don't get into a situation where the trunk is broken and blocking release
(10:25) [Arch_SB]thpr: agree that there is risk/challenge with getting onto a 6-9 mo cycle
(10:25) [Arch_SB]thpr: That's pretty much what I managed to capture of his thoughts

Devon

(10:26) devonjones: should I go since I already broke in?
(10:26) James[Code_SB]: I'll be a pretty cool thing to add to pcgen
(10:26) James[Code_SB]: Sure
(10:27) devonjones: So I moved from New York to Denver, which took out my time at the end of last cycle, and I have a child coming at the end of January
(10:27) [Arch_SB]thpr: congrats!
(10:27) devonjones: thanks :)
(10:27) devonjones: so I think I want to keep my focus on quick hits
(10:27) James[Code_SB]: Congratulations
(10:28) devonjones: there are lots of little tag bugs that Andrew would love to have get done, and I started on that last cycle, taking them out one by one
(10:28) devonjones: I plan on continuing that in this cycle
(10:28) devonjones: the second thing I want to look at is this. as I have mentioned, I have an SRD app for android - creating this has resulted in me creating code that can parse the SRD
(10:29) devonjones: I can pull out much but not all of the semantic data from the raw text
(10:29) James[Code_SB]: Nice
(10:29) devonjones: I think taking this and making something that can output at least a skeleton of the rules for a book could speed us up on data, at least for SRD related materials
(10:30) devonjones: so I want to explore that
(10:30) devonjones: That's it for me
(10:30) [Arch_SB]thpr: A while back I did some stuff unrelated to PCGen that involved parsing PDFs. I'll have to see if I can dig up that code
(10:31) [Arch_SB]thpr: Because that might help understand more than just raw text formats
(10:31) [Chair]Andrew: That would be very helpful too!
(10:31) devonjones: yeah, I've started some of that
(10:31) devonjones: I have something that can pull all start blocks out of a pdf
(10:31) devonjones: floating around somewhere
(10:32) devonjones: so one thing I should disclose - while the code I release for android is open source, I will be charging for some of them
(10:32) devonjones: the code I use to parse this feeds into that, so if that makes anyone uncomfortable, I should know about it ahead of time
(10:33) James[Code_SB]: It shouldn't matter so long as the code that you commit to PCGen is licensed to the project under LGPL
(10:33) devonjones: yep
(10:33) devonjones: just wanted to make sure I'm up front about that
(10:33) devonjones: my observation is that many people are happy to pay for an app on tablets, even if you make it available as open source and for free
(10:34) devonjones: so I have no intention of using closed licenses
(10:34) James[Code_SB]: Sounds good
(10:35) James[Code_SB]: Jonas did you want to go next?

James

(10:36) James[Code_SB]: I might go next then
(10:36) James[Code_SB]: So the things I wanted to look at this time around were
(10:36) James[Code_SB]: 1. Removing the old UI from the code base
(10:37) James[Code_SB]: Which I started in earnest this morning
(10:37) James[Code_SB]: This will also involve moving some last bits of the old UI still in use
(10:38) James[Code_SB]: 2. Providing freemaker as an option for output and deprecating the old export structure (e.g. |FOR..|) once it is is stable
(10:38) devonjones: oh, can you also make multiline LST default?
(10:39) James[Code_SB]: I think if it works well enough we can just make it standard
(10:39) James[Code_SB]: but we'll need to make sure the converter plays nice with it
(10:39) [Arch_SB]thpr: So help me with what Multiline LST means?
(10:39) James[Code_SB]: and of pretty lst needs to know about it
(10:39) James[Code_SB]: Sure
(10:40) James[Code_SB]: A few months ago, I added the capability that a line starting with a tab would be parsed as a continuation of the previous line
(10:40) James[Code_SB]: This matches a common development format that Andrew and a few other LST monkeys use
(10:40) James[Code_SB]: It is currently controlled by a default off preference
(10:41) [Arch_SB]thpr: Converter wont' like that
(10:41) devonjones: having used the vim extension it's /so/ much easier to edit LST that way
(10:41) James[Code_SB]: Yeah I suspected that
(10:41) [Arch_SB]thpr: ok. That's going to require the converter learn more context than it does right now
(10:41) [Arch_SB]thpr: that's not bad - we want that anyway - just puts it on a particular schedule
(10:42) [Arch_SB]thpr: and that may depend on some things in the core. A bit rusty on the particulars there
(10:43) [Arch_SB]thpr: ok, thanks for the explanation, sorry for the tangent
(10:43) James[Code_SB]: no problems, good one to have
(10:43) James[Code_SB]: 3. New LST editor (the big task)
(10:44) James[Code_SB]: and then some general housekeeping such as deprecating some things that we didn't get deprecated last cycle and deleting the current deprecated token classes
(10:44) James[Code_SB]: any questions or comments there?
(10:45) [Arch_SB]thpr: freemarker and editor in 6-9 mo?
(10:45) James[Code_SB]: Excellent question :)
(10:45) James[Code_SB]: Freemarker yes I think that should be a shorter sub-project
(10:46) James[Code_SB]: but the editor could be much bigger
(10:46) [Arch_SB]thpr: ok
(10:46) [Chair]Andrew: How many branches are we going to have for the subprojects work?
(10:46) James[Code_SB]: and has to be done in a branch/sandbox so that it doesn't gate anything

Branching

(10:47) James[Code_SB]: Andrew, that;s a good segue into the branching discussion
(10:48) James[Code_SB]: One sandbox per sub-project is a logical starting point
(10:48) James[Code_SB]: you can bring the branch up to date with the trunk relatively easily and in fact that is a first step (in SVN) for merging it back into the trunk
(10:49) James[Code_SB]: but what do others think?
(10:50) [Chair]Andrew: I think it sounds good.
(10:50) [Arch_SB]thpr: curious where the threshold is for things in the trunk
(10:50) James[Code_SB]: Fuzzy thing really
(10:50) [Arch_SB]thpr: One extreme is everything gets done in branches and then we do a couple merges right before we go beta
(10:50) [Chair]Andrew: ick, be hard to catch things till we went beta.
(10:51) [Arch_SB]thpr: another is things that are likely to produce relatively unused code if the project is not finished must go into a sandbox
(10:51) James[Code_SB]: For the new UI we got it to the point where it could do most fo the basics and then merged in to trunk
(10:52) James[Code_SB]: It was still disruptive as it was a huge change
(10:55) [Arch_SB]thpr: So if I'm doing refactoring changes like I was doing in 5.14
(10:55) [Arch_SB]thpr: Trunk, or branch, and if branch, how often does it get merged?
(10:55) James[Code_SB]: It is probably much simpler in trunk
(10:55) James[Code_SB]: refactoring in a branch is not fun
(10:55) [Arch_SB]thpr: hence my question :)
(10:55) James[Code_SB]: :)
(10:56) James[Code_SB]: but there is an expectation that the trunk is always usable which again makes refactoring a bit harder.
(10:58) James[Code_SB]: Really all I want to avoid is getting to (say) May next year and having the situation where we can't go to beta as feature X is not complete
(10:58) [Arch_SB]thpr: ok
(10:59) [Chair]Andrew: James that also gives a segue into the discussion of GIT. Pros vs. Cons and if we want to switch over to it.
(10:59) James[Code_SB]: and conversely to not hold up the start of work that people are keen to do because it might not fit into the timetable

Git

(11:00) James[Code_SB]: Devon, Tom, have you done much with DVCS?
(11:01) devonjones: I work with Git every day now
(11:01) [Arch_SB]thpr: 0
(11:02) devonjones: honestly I prefer it
(11:02) devonjones: it took me a long time to get there, the learning curve is a bitch
(11:02) devonjones: but the flow is much more natural
(11:02) devonjones: you can make svn an upstream for git
(11:02) devonjones: so you /could create a git repo
(11:03) devonjones: and start migrating builds to that
(11:03) devonjones: and use it as a way to merge in approved patches/branches
(11:03) devonjones: and then slowly migrate people off of SVN
(11:03) devonjones: that does work
(11:03) James[Code_SB]: Interesting
(11:03) [Arch_SB]thpr: Is there a way to not lose our 20K or whatever history of checkins?
(11:03) James[Code_SB]: My experience level is also zero
(11:03) [Arch_SB]thpr: I hate when I have to go open CVS to find ancient history
(11:03) James[Code_SB]: but I'll be starting to play with it soon
(11:04) James[Code_SB]: Yeah not a fan of that either!
(11:04) [Arch_SB]thpr: Don't get me wrong, I'm not opposed to it, just want to learn and understand the consequences of the change
(11:04) [Arch_SB]thpr: eyes open and all that
(11:05) [Chair]Andrew: If I understand correctly, we can preserve the histories. And also get the cvs ones - but it depends on the access SF grants.
(11:05) devonjones: history: I don't know
(11:05) devonjones: I;ll find out
(11:05) TiBook: just having real tags would be nice.
(11:05) James[Code_SB]: real tags?
(11:06) TiBook: the first time I checked out the pcgen codebase, I filled the disk on my laptop.
(11:06) TiBook: (I checked out the root of the repo, and so checked out the "tags" dir.)
(11:07) devonjones: right, tags in git refer to a checkin
(11:07) devonjones: instead of being a directory
(11:07) devonjones: I will say
(11:07) devonjones: despite preferring git
(11:07) TiBook: tags in git are like tags in CVS -- they're a label, not a copy.
(11:07) devonjones: if I'm the only one with git experience, I think it's not a good idea to move the project
(11:08) TiBook: devonjones, I use git for my local projects.
(11:08) devonjones: ok
(11:08) TiBook: I use SVN at work.
(11:08) devonjones: Git /is/ more social
(11:08) devonjones: we may get more patches if we are on git from other coders
(11:08) [Arch_SB]thpr: I'm ok with evaluating it
(11:09) James[Code_SB]: Ditto
(11:09) devonjones: it's /much/ easier to take patches from people, because each person has a repo
(11:09) [Arch_SB]thpr: Heck, This was the first place I used SVN and can't imagine going back to RCS or CVS
(11:09) [Arch_SB]thpr: so have pushed subversion elsewhere
(11:09) devonjones: so you don't have to merge them until ready
(11:09) devonjones: heh
(11:09) devonjones: yeah, same happened to me
(11:10) [Arch_SB]thpr: Can I ask one other question on git?
(11:10) James[Code_SB]: but as I've said publicly before - this needs a champion who is very familiar with the project (and to the team) who is prepared to shepherd the change through
(11:11) [Arch_SB]thpr: One of the things that I end up with a lot when I'm in cleanup mode is like 30 or 40 different checkins that are all in short order, how does that work? Is there some final signature that is the sum of those 30-40 changes and other folks need simply import that one signature?
(11:11) [Arch_SB]thpr: @James, clearly it's Devon or bust LOL
(11:12) devonjones: yeah
(11:12) devonjones: I'll consider if I want to tackle this
(11:12) devonjones: so with git
(11:12) devonjones: you can convert those all to one "pull" (if it's Github)
(11:12) [Chair]Andrew: I've been using GIT. But I don't consider myself an expert
(11:12) devonjones: or you can take a bunch of patches and "squash" them into one patch for review/merge
(11:13) devonjones: so I don't think we can sort this out here, because it's actually a big project
(11:13) [Arch_SB]thpr: ok
(11:13) James[Code_SB]: @TiBook was it you who set up the github pcgen passthrough?
(11:13) devonjones: I'll take "investigating GIT" and add that to my list
(11:13) James[Code_SB]: Thanks Devon
(11:13) TiBook: James[Code_SB], no.
(11:13) devonjones: sorry, I need to blaze
(11:14) devonjones: I was free until 6 (my time)
(11:14) James[Code_SB]: k, thanks for making the tiime - been a great discussion
(11:14) devonjones: :)
(11:14) James[Code_SB]: Anything else we want to cover?
(11:16) [Arch_SB]thpr: not here
(11:16) James[Code_SB]: Andrew?
(11:16) [Chair]Andrew: I'm good. I'll help out where needed as usual.
(11:16) [Chair]Andrew: ;)
(11:16) James[Code_SB]: Anything missing from the above list that we think is needed for 6.2?
(11:17) [Chair]Andrew: NPC Generator was mentioned on the list
(11:17) [Arch_SB]thpr: That's a BIG project
(11:17) James[Code_SB]: I think Connor was the keenest on that but haven't heard from him in a bit
(11:18) [Chair]Andrew: Well, if anyone picks it up, I'm sure it'll be a branch project
(11:18) James[Code_SB]: Absolutely
(11:19) [Chair]Andrew: Henk was the one who set up a github
(11:19) James[Code_SB]: Cooll, thanks for that
(11:20) James[Code_SB]: ok, well we might call the meeting there
(11:20) James[Code_SB]: Thanks for coming everyone