search

openmod-initiative / toolchest

A common repository for tools used in energy modeling.
BSD 3-Clause "New" or "Revised" License
5 stars 4 forks source link

readme #2

Closed gidden closed 8 years ago

gidden commented 8 years ago

Hey everyone,

I've added a barebones readme. Please take at least a cursory look, especially on the Contributing and Conflicts sections. I know the conflict stuff sounds silly now, but I've found that having a agreed-upon resolution mechanism in place is never a bad thing.

A simple +1 from all of you is fine with me for pulling this in.

coroa commented 8 years ago

+1

@sjpfenninger @ojdo : you might want to watch toolchest! I just caught @gidden 's pullrequest by chance.

coroa commented 8 years ago

i see the split into develop/master as one which makes sense, but only at a somewhat later stage, once the first users are in place. Since you're pulling into master i guess, you somewhat agree. Let's not forget to implement this split later!

sjpfenninger commented 8 years ago

I'm not a fan of develop branches. Why not pull into master and tag releases off of master? That's kind of the default I expect when I reach a project's repo. We can always add a release or stable branch if necessary.

gidden commented 8 years ago

Hey @sjpfenninger, the rationale for having develop branches is explained here

In short, develop is used as a back-stop in case some issue is found with a code before release. That is, develop can be considered unstable, but master is stable.

For example, after this and the License PR, I would make a develop branch and make it the default. While I've found this development model quite useful, I don't want it to hinder us at the beginning. Perhaps @ojdo can weigh in and I'll update the PR accordingly.

Finally, note that there is also a License PR!

ojdo commented 8 years ago

@coroa thanks for the mention, repo is on watch now. @gidden right now I would opt for the simpler "no develop branch" model, and simply creating releases whenever we have the feeling of having reached a new milestone. I wager that the PR peer reviews will do a good enough job to keep master reasonably stable. Just my 2ct, though :smile: The explicit conflict resolution vote seems fine to me (apart from the typo 'solutoin').

gidden commented 8 years ago

ok, I believe I've addressed everyone's comments, this should be good to go

coroa commented 8 years ago

My suggestion would be to start with a simple master only work-flow, all the while the pr's are used as gatekeepers, and use tagging to indicate major feature set changes as @sjpfenninger had already suggested.

When we later notice any instabilities creeping in, we can easily switch to the more conservative separate develop/master approach.

coroa commented 8 years ago

ah, I should read ALL my mails before replying :)

i don't have write access, so can't merge!

gidden commented 8 years ago

You've been added. There's a team called "toolchest-pullers" on the openmod-initiative group. Everyone in it has Admin access (thus should be able to add others). You have to be a "member" of the github org to be in the team I think. Once we get some additions to the repo, I think we should advertise it more broadly on the list serv.

On Tue, May 3, 2016 at 2:07 PM, Jonas Hörsch notifications@github.com wrote:

ah, I should read ALL my mails before replying :)

i don't have write access, so can't merge!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/openmod-initiative/toolchest/pull/2#issuecomment-216508376