Low Hanging Fruit

Development
1

I am sure there are some issues that are brain-dead simple to fix, but they aren’t fixed because of low ROI. Maybe I can help myself to better learn the codebase by tackling some of these issues.

Do any of you have anything in particular in mind in this category?

2

Super-low hanging fruit: fix checkstyle violations, look at the latest build under travis-ci.com/github/vassalengine/vassal (or build the master branch locally), fix the warnings that checkstyle spits out (currently whitespace). Once the current warnings are gone, we will turn them into build-breaking errors, and activate the next rules as warnings. There is still a lot to do in that area.

Other low-hanging fruit:

  • get rid of compiler warnings (might be a bit tricky sometimes but some are quite easy to get rid of)
  • write unit tests for simple classes (the ones that don’t access anything static)
  • find all the main() methods that are used for unit-testing, move that code into proper unit tests under src/test/java, just mark these unit tests with @Ignore so they are not executed automatically (IntelliJ has nice support for finding/creating unit tests for a given class, just press ctrl+T)
  • error handling, find catch() blocks that do nothing or call e.printStackTrace(), change that to proper logging

I can explain these things in more detail if you are interested.

3

Chasing down recently reported bugs in the bug tracker is always a good thing to do.

4

I have one more, as a newcomer you are best suited to write a wiki article about how to get started with Vassal development, using IntelliJ. We only have a guide for Eclipse, and none of us uses Eclipse anymore, and also most of us are too advanced and don’t know what the typical problems are from a newcomers point of view.

5

That’s a huge thumbs-up from me! Great idea! Especially because I intend to switch over from Eclipse soon.

6

You’re a DevOps guy, this is good, this is what we were missing. I am just a developer and usually have the luxury of having proper DevOps people setup all the build pipelines for me, I introduced this whole Maven+TravisCI pipeline here but a lot of it is new for me and I have to learn it as we go. There’s still a lot of room for improvement, we only use Travis for certain checks but the full beta/release builds are still done manually. Have a look at our build cycle, the Travis config, you’ll probably have good ideas what to do best to fully automate it. I was thinking something along the line of using git tags to initiate full release builds on Travis, and have Travis upload the release packages to some place. Also there’s the automated documentation-generation PR that will be merged shortly, it will generate pdf documents and it would be cool to generate online documentation as well and upload it to some place where people could access it by browser, like those other modern projects do.

7

I have no experience in specificly using Maven and/or TravisCI, but I do have generic CI experience. It shouldn’t be that difficult to adapt. It will be good to add that to my skillset too. I am more familiar with JenkinsX. And my Java is a few years old, but I will get current on that very fast.

8

Thus spake tinjaw via messages:

I have no experience in specificly using Maven and/or TravisCI, but I do
have generic CI experience. It shouldn’t be that difficult to adapt. It
will be good to add that to my skillset too. I am more familiar with
JenkinsX. And my Java is a few years old, but I will get current on that
very fast.

I will veto any use of Jenkins. We use Jenkins in my day job, and it has
been so miserable that I wish I’d never heard of it.

–
J.

9

Have no fear. I see this not as an opportunity to preach Jenkins as it is to learn Travis.

10

Thus spake tinjaw via messages:

I am sure there are some issues that are brain-dead simple to fix, but
they aren’t fixed because of low ROI. Maybe I can help myself to better
learn the codebase by tackling some of these issues.

Do any of you have anything in particular in mind in this category?

Tending to new bug reports in the tracker is valuable. The ones marked
“ABR” came in via the automatic bug reporter from uncaught exceptions;
the ones assigned to “bugs@vassalengine.org” aren’t assigned to anyone,
that’s the catch-all address.

The ABR ones should have stack traces with them and will have the
exception type in the title. Just marking duplicates is helpful, even
if you can’t figure out the cause. Fixing these is a force multiplier:
unfixed, we’ll see lots more of them; fixed, they’ll stop coming in.

The ones which aren’t ABR bugs were entered manually, so in some cases
have sufficient description for reproducing them. (The ABR ones you
often have to reason about from the stack traces and the code.)

When I mark duplicates, I transfer over any contact email that was left
to the main bug, and I try to email all the reporters when a bug is
fixed.

–
J.

11

Kind of off-topic, but I use Jenkins at work and have had far fewer problems with it than with our other solution. I am curious about what makes it so miserable for you. Not looking for an opportunity to change your mind, but I find the angry rants of others to be educational sometimes (i.e. perhaps your problems paint a useful picture of things to avoid). Could I encourage you to post a rant (maybe as a private message if this is not an appropriate place)?

12

Thus spake LoadEffectiveAddress:

“uckelman” wrote:

Thus spake tinjaw via messages:
I will veto any use of Jenkins. We use Jenkins in my day job, and it
has
been so miserable that I wish I’d never heard of it.

Kind of off-topic, but I use Jenkins at work and have had far fewer
problems with it than with our other solution. I am curious about what
makes it so miserable for you. Not looking for an opportunity to change
your mind, but I find the angry rants of others to be educational
sometimes (i.e. perhaps your problems paint a useful picture of things
to avoid). Could I encourage you to post a rant (maybe as a private
message if this is not an appropriate place)?

It’s a combination of things:

  • We have an authentication situation which seemeed supported, then we
    found was only halfway supprorted, but we couldn’t change the setup
    in which we had to work not to use it, so ended up fixing some plugin
    bugs and writing some code…

  • We have a rather large DAG of projects we build; we want what’s built
    for PRs to project A to be used by the build of downstream project B that
    successful builds of A trigger… This seems like a natural thing to want
    so that you can be sure upstream changes break nothing downstream… but
    then you find that Jenkins has nothing for figuring out branch matching
    in this kind of situation… so we ended up writing a lot of custom code
    for that.

  • It seems that the Groovy inside Jenkins has some oddball differences from
    real Groovy, which are just maddening trying to figure out empirically.

  • Jenkins in general has been an “attractive nuisance” at every step.
    We set out to do something with Jenkins that appeared easy. Then we’d
    fail to do it for several hours—but nonetheless, what we were trying
    to do would STILL have the appareance of being easy. Jenkins has this
    way of making it always look like you’re just about there, no matter
    how long you’ve been fruitlessly bashing away at it.

–
J.