search

alcap-org / AlcapDAQ

Alcap DAQ
alcap-org.github.io
8 stars 0 forks source link

Merging back 'blind analysis' branches #253

Closed benkrikler closed 9 years ago

benkrikler commented 9 years ago

I need to go back to the pile-up work for a bit and want to merge back my branch from the Si spectrum work. Since we all wrote a lot of code in the last month or so and worked on separate branches that we weren't merging regularly, how do we want to approach this?

I can see that we just merge everything back in one by one or do we want to be selective about things through pull requests? I'm not sure what is simpler / quicker since the first way we need less coordination but the second might reduce future bugs and issues..

AndrewEdmonds11 commented 9 years ago

Well, I've been putting a lot of my stuff in an Al50 subfolder so there shouldn't be any clashes in common code for me (I hope).

Obviously, the proper way to do this is to do pull requests but are we at the stage where we have time for this? I have no feeling of whether, as a collaboration, we are going to keep going full pelt to hit another deadline for a proper analysis or whether we now have time to go through in detail what people have coded (which may be good for the analysis itself) and merge things properly.

Also, personally, I'd rather not merge in right now since I want to get my thesis out of the way...

Equally, I don't think we should spend weeks and weeks discussing this...

On the other hand, I think having a big refactoring and a plan for future development before the second run would be a good idea...

In conclusion, I don't know...

benkrikler commented 9 years ago

I think you're right, we do need to evaluate goals and man-power to work out what we do with the analysis from now on. Personally I've let COMET things slide a bit since November and would really like to focus on that for at least a month or two.

I know I've touched some 'core' code in my work but I think it was only adding in things rather than changing functionality or renaming. Maybe I'll just open a pull-request for documenting the changes but then merge it in quite quickly?

AndrewEdmonds11 commented 9 years ago

Maybe I'll just open a pull-request for documenting the changes but then merge it in quite quickly?

Sure, I think that's the best of both worlds.

Also, I would support us taking a small break on this for a month or two (although we should probably discuss this with the whole collaboration).

jrquirk commented 9 years ago

I think either merge method works. It's a small project with only a few people and even fewer changes to common code. Also, since we're working on different enough things, merging doesn't seem necessary.

However, for oneself especially, if you walk away from a branch for a while you risk overhead refreshing yourself next time or redoing work you've forgot you've already done, or losing work when you just forget/ignore it. If you have any sort of hiatus plans I'd vote for tying things up as best you can and merging them in. You'll also be less overwhelmed next time you look at all of your branches. That's my plan at least.

benkrikler commented 9 years ago

Right, that's my main concern basically, I don't want a long-term branch hanging around.

Pull request is up now (#254). Since we seem to be in general agreement, I'll close this.