Is devttys0/libmpsse the de facto upstream for libmpsse?

[jhgit]

I would like to add some changes, but I'd like to understand if this is the "right place" for libmpsse now. Was this repo first? Should it be the default upstream for most of the world's consumers of libmpsse?

I'd also like to update the FreeBSD port which is still pointing to the googlecode home for libmpsse. That archive is still available, but obviously it's not an active project there anymore.

I see there are some pending unreviewed (or at least uncommented) issues. If this is to be the default upstream version, maybe the community should add some helpful comments to assist the current committers. Or maybe this repo (if it's the consensus official repo) should add some committers to help maintain it.

[jhgit]

The FreeBSD port has been updated to point to this repo (devttys0/libmpsse), including the proposed fix for issue 16 (support parallel build):

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217160

Please say so if there is a better upstream location.

[jhgit]

It would be a good idea to lay down a tag for the existing code base as version 1.3 (for git changeset f1a6744) since that is basically the same as the historical 1.3 googlecode version.

[l29ah]

As the repo seems to be dead i've forked it and pulled a few outstanding branches that looked sensible to me and going to maintain it for a while at least: https://github.com/l29ah/libmpsse
Contributions are welcome.

[jhgit]

It's too bad this repo (devttys0) has gone radio silent without explanation. Before going too far with new changes, what to you think about my previous comment (a tag for the historical 1.3 googlecode)? We should then target a new release (1.4?) with the first pass of improvements.

[l29ah]

On Mon, May 22, 2017 at 11:54:25AM -0700, John Hein wrote: It's too bad this repo (devttys0) has gone radio silent without explanation. Before going too far with new changes, what to you think about my previous comment (a tag for the historical 1.3 googlecode)? We should then target a new release (1.4?) with the first pass of improvements.

Sounds good, i've added the tag. I'm not sure about the version numbering scheme and release policy yet, but i'd call the maintenance versions 1.3.x and jump to 1.4 only when the existing api needs to be broken.

…

-- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments

[jhgit]

Okay. I'd be okay with a policy of major bump (2.0) for API changes, too. (e.g., http://semver.org/, https://en.wikipedia.org/wiki/Software_versioning#Degree_of_compatibility).

[l29ah]

On Mon, May 22, 2017 at 12:20:33PM -0700, John Hein wrote: Okay. I'd be okay with a policy of major bump (2.0) for API changes, too. (e.g., http://semver.org/, https://en.wikipedia.org/wiki/Software_versioning#Degree_of_compatibility).

http://semver.org/ policy code looks good, thanks, i'll use it.

…

-- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments