Re: [OMPI devel] OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-198-g68bec0a

Paul Hargrove writes: > IIRC it was not possible to merge with a dirty tree with git 1.7. Nope. This warning was added to git-1.7.0: https://github.com/git/git/commit/e330d8ca1a9ec38ce40b0f67123b1dd893f0b31c Discussion thread:

Re: [OMPI devel] OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-198-g68bec0a

"Dave Goodell (dgoodell)" writes: > Most of the time a "pull" won't succeed if you have uncommitted > modifications your tree, so I'm not sure how pull/commit/push would > actually work for you. Do you stash/unstash in the middle there? Git will happily do the pull/merge

Re: [OMPI devel] Why no release tags in open-mpi/ompi repository?

"Dave Goodell (dgoodell)" writes: > You're not wrong about the advantages of a merge-based workflow. I > just don't think it changes what the community is choosing to do right > now. No worries. I didn't notice previous workflow discussion and I've seen history repeat

Re: [OMPI devel] Why no release tags in open-mpi/ompi repository?

"Jeff Squyres (jsquyres)" writes: > Meaning: we deliberately chose not to change the development style of > the community to "develop on release branch" when we moved to git. Understood. It's your choice, but workflow is a big feature of Git. >> Seems to me that most

Re: [OMPI devel] Why no release tags in open-mpi/ompi repository?

Ralph Castain writes: > We go the other direction - all code must be committed to master so it > can “soak” prior to moving to a release branch. Maybe we're miscommunicating. Normal lifecycle for a bug fix is # start from oldest maintenance branch to which the fix is

Re: [OMPI devel] Why no release tags in open-mpi/ompi repository?

"Jeff Squyres (jsquyres)" writes: > The ompi repo only contains the master branch. Releases are not made > from master, and therefore it doesn't make sense to tag it with > release tags. master is therefore not (directly) related to any given > release. You can have tags

[OMPI devel] Why no release tags in open-mpi/ompi repository?

You can get them locally by fetching from open-mpi/ompi-release, but the only tag in open-mpi/ompi is called "dev" and on a seemingly arbitrary commit. Isn't that awkward already, and more so with each passing year? Release tags in the development repository are useful to determine which released

Re: [OMPI devel] ompi github repository is NOT up to date

Ralph Castain writes: > No, it's okay - for some reason, Mike's last commit is labelled as > having been written 13 days ago. If you look at the commit log, you'll > see that everything is just fine. The commit was amended or rebased on Oct 5: $ git log -1 --format=fuller

Re: [OMPI devel] Bitbucket vs. GitHub (was: Conversion to GitHub: POSTPONED)

Paul Hargrove writes: > The GUIs for things like browsing commits, viewing diffs, etc are pretty > similar in capability and each is sufficiently intuitive (after a brief > learning curve) that I don't find I need any conscious effort to "mode > switch" between their use. The

Re: [OMPI devel] Conversion to GitHub: POSTPONED

"Jeff Squyres (jsquyres)" writes: > GerritHub claims to allow us to effectively have ACLs on branches. > I.e., everyone could commit on master, but only release managers can > commit on release branches. This would be nice, and would allow us to > avoid having the 2 repos,

Re: [OMPI devel] Contributor License Agreement

Ralph Castain writes: > I'm not a lawyer, but that agreement was formulated by the lawyers of > several national labs, universities, and corporations back at the very > beginning of the project, and so that's what we have to use. MPICH does the same thing, but the CLA grants

[OMPI devel] Contributor License Agreement

Ralph Castain writes: > Indeed, welcome! > > Just to make things smoother: are you planning to contribute your work > back to the community? If so, we'll need a signed contributor > agreement - see here: > > http://www.open-mpi.org/community/contribute/corporate.php This is

Re: [OMPI devel] TKR

"Jeff Squyres (jsquyres)" writes: > Before Fortran 08, there was no Fortran equivalent of C's (void*). > Hence, it was actually impossible -- using pure Fortran -- to have > Fortran prototypes for MPI subroutines that take a choice buffer > (e.g., MPI_Send, which takes a