Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add explicit branch for 2.4i; pull 2.5j #136

Closed
anadon opened this issue Apr 10, 2018 · 4 comments
Closed

Add explicit branch for 2.4i; pull 2.5j #136

anadon opened this issue Apr 10, 2018 · 4 comments

Comments

@anadon
Copy link

anadon commented Apr 10, 2018

Hello,

I'd rather my changes to Hmmer2 be upstreamed. Added a default suffix of 2, but this is over-ridable. Also did some other various cleanups. In order to review and cleanly merge these, a branch at the 2.4i tag needs to be added.

@cryptogenomicon
Copy link
Member

I'm sorry, I don't know what you're talking about, and HMMER2 is no longer developed or maintained.

@anadon
Copy link
Author

anadon commented Apr 10, 2018

Regardless, it is still used. Since this is the case, I have a pull request pending a branch to merge with.

@cryptogenomicon
Copy link
Member

I'm sorry, let me be more clear, at risk of being less diplomatic. You haven't explained here what "your changes" are. You're asking me to make a branch at our 2.4i release tag, but 2.3.2 is the correct last public release of HMMER2; you didn't talk to me about where to base HMMER2 changes. You haven't given me enough to go on, and it takes time away from other things to look at any given issue or pull request.

You've spoken to me before in email, and I suppose the changes you're talking about are related to what you were discussing then. Your emails were, in my opinion, unprofessionally aggressive and inaccurate. I decided that you would be too difficult to work with and stopped replying to you. I have also seen public posts from you that reinforce my opinion.

I believe, based on the earlier emails, that you want to have 'make install' change the name of the HMMER2 executables so they can be installed together with HMMER3 executables. This would make it easier on some packages that depend on HMMER2 for global/glocal alignment, though HMMER3 is preferred for almost all other uses. Because HMMER executables are free-standing and can be copied and renamed at will, I think it's already easy enough for anyone to rename HMMER2 programs to anything that's convenient for their work. I know other people already do this.

Changing the default application names in HMMER2 itself creates other problems. For example, HMMER2 documentation is already widely distributed.

I see the problem with program name clashes between HMMER2 and HMMER3, and I agree that it's a problem. I would consider suggested fixes to it, if other people want to comment, and I would consider reopening a branch for HMMER2 development. However, based on interactions with you so far, I'm going to exercise a life's-too-short-for-this prerogative to not work with certain people. If you'd like to reset and take a more reasonable and collaborative tone than you've taken to date, I could reconsider. Best wishes for your work, and do feel free to use our code however you like.

@anadon
Copy link
Author

anadon commented Apr 11, 2018

I passed those exchanges by ~4 people, and we couldn't find your problem. Seriously, what is going on?

@EddyRivasLab EddyRivasLab locked as resolved and limited conversation to collaborators Apr 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants