meh, I just published it.

I'd strongly discourage that

It'll get very confusing very fast

Development is recommended to happen on a named feature branch on your fork

e.g. I always have branches like

That makes sense if you're going to work on multiple features at a time

Some people do

myfork/my_name.rbN

where N is the RB

But I have no idea when or if I'll ever do another PR

It makes sense if you're going to work on more than one feature ever

Otherwise you're going to have to force push to clean your master (which doesn't stay up to date tracking upstream master by default btw) when your feature lands

It's a small change; should I rename the branch for PR approval? Or is it ok for now?

I'm OK with that

Okay, yeah. We don't really care, as long as the PR works as expected

I got an email about https://rbcommons.com/s/twitter/r/3413/ but I don't see an email for it on https://groups.google.com/forum/#!forum/pants-reviews

Did it fail? Do I need to do something here?

can take a little while. but also, you need to have signed up (yea, awkward)

A general ping about: https://rbcommons.com/s/twitter/r/3185/

cc @jolly-chef-92794

This is killing us internally

I'm probably just going to fork in order to consume the patch I posted there

@better-park-26723: I like to have the pants bug number in my branch if there is one.

something like molsen/<bug>_description

it means its easy to lookup any discussion on the issue based on the branch name.

@better-park-26723: Also a couple of notes. Just put the pull request number in the bugs field, it figures out the link for you. Also if this is ready for review, you need to call out specific reviewers in People on the bottom right

@better-park-26723: I had to one-time approve you for the mailing list. You email should show up now and they'll show up instantly in the future.

how do you aggregate test reports for jenkins?

@bored-art-40741: I’m ok with not invalidating compiles due to resources/etc dependencies, as long as that behavior is behind a flag. We actually go out of our way internally to invalidate the incremental zinc compile when resources which affect annotation processing change (invalidating the java_library target isn’t enough, because zinc’s incremental compile behavior short-circuits as it thinks nothing relevant has changed. We have a plugin that goes and wipes the zinc incremental compile directory for the relevant target under .pants.d if the resources files change)

Can we cut a new jarjar release to pull in the bugfix I landed yesterday?

(Looks like it hasn’t been released since april?)