Version 0.2 of pubgrub

[mpizenberg]

This is for publication of version 0.2 of pubgrub. Once this is merged in dev, I'll just create a merge commit in master.

[Eh2406]

This feels like a good opportunity to make sure that the github org has permission to publish on crates.io.
Also we should probably mark it as a release on github, and add a git tag.

[aleksator]

By the way, master has 1 additional commit compared to dev. Should dev branch be rebased?

[aleksator]

Also we should probably mark it as a release on github, and add a git tag.

If we do that I think we should tag 0.1 as well.

[Eh2406]

While we are changing the readme, can we add a code of conduct? Preferably the RustCOC.

[mpizenberg]

By the way, master has 1 additional commit compared to dev. Should dev branch be rebased?

With our setup it's normal, master will progress one commit at a time for each realease, everytime 1 commit ahead of dev. It's not a problem. It does something like this:

                 v0.1.0             v0.2.0             v1.0.0
master:          *------------------*------------------*
                /                  /                  /
dev: *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

can we add a code of conduct?

Yes, also changelog would be nice

[mpizenberg]

With our setup it's normal, master will progress one commit at a time for each realease

Do you mind if I rename "master" into "release"?

[mpizenberg]

RustCOC

@Eh2406 where can we find this? could you add it?

[mpizenberg]

This feels like a good opportunity to make sure that the github org has permission to publish on crates.io

I don't know how that works. I just know how I can add owners to the crates.io package. Currently Alex and me are identified as owners

[Eh2406]

Do you mind if I rename "master" into "release"?

Please do!

where can we find this?

https://www.rust-lang.org/policies/code-of-conduct

I just know how I can add owners to the crates.io package.

I think it is cargo owner --add github:pubgrub-rs, but I am not sure. Just adding individuals one at a time works.

[aleksator]

While we are changing the readme, can we add a code of conduct? Preferably the RustCOC.

I see personally 0 value in having them 🤷‍♂️ From what I saw they are often used selectively by admins to justify banning someone they don't like or by SJWs to bully people.
For those reasons it has very negative connotations for me.

The guidelines for any communication can in my opinion be expressed in one sentence: "Don't be a dick".
That's not specific and it's a feature: you know when you see one. Having explicit "rules" just makes trolls try to find a way to circumvent them.

When you see the behavior you deem unacceptable you can just say so, I don't see why it should necessarily be enforced with a link to some CoC.

Yes, also changelog would be nice

We should look into tools for auto generating them. Maybe following conventional commits has some advantages here, also @mpizenberg suggested another one that analyzes the history without depending on commit messages. I'll see if I can find it.

Do you mind if I rename "master" into "release"?

I don't mind.

I think it is cargo owner --add github:pubgrub-rs, but I am not sure. Just adding individuals one at a time works.

If we can list the organization it would be better as we wouldn't have to worry about updating it if the roster changes.

[mpizenberg]

• renamed "master" into "release"
• created a "crates-io" team in org pubgrub-rs and granted it publish access to crates.io. @Eh2406 Since you're not listed as an owner of the crate but member of that team we will be able to verify that it works if you do the v0.2 publication when it's ready.

[mpizenberg]

For reference, here are some changelogs:

• mpizenberg/elm-pointer-events: simple changelog
• nalgebra: notable changes
• serde: decided to not add a changelog file and uses release notes instead.
• criterion: based on Keep a Changelog format

[mpizenberg]

I've added a note regarding friendly contribution in the readme. Do you think that's enough for now @Eh2406 . We could change it later if we observe abuse.

[mpizenberg]

So the last things to do seem to be

• Check that the guide is ok(ish), does not have to be perfect, we can change it when we want since it's not in this repo.
• CHANGELOG.md. I can do this one manually, following the "Keep a Changelog" format for v0.2, and later Alex could try automated things.

Anything else I'm missing?

[Eh2406]

I do think it is important to state somehow that we don't tolerate abuse. One might think that should be obvious, but unfortunately there are communities where abuse is passively or intentionally accepted. Many of my friends have been pushed out of technical spaces for their religion or how they dress or who they sleep with. So this matters to me.

I think like a license this is a decision that is easier to make when the community is small. That is why I brought it up now. "Don't be a dick" works as a set of rules, but at some point we may need to express who to tell if you see a dick and what they can do about it. How long winded we want to make that statement and where, can reasonably be discussed. If we want something that fit in the README.md instead of CODE_OF_CONDUCT.md that works. YAGNI would suggest that @mpizenberg's text is more than adequate for now. On the other hand I'd rather have it in place before we need it.

[mpizenberg]

I don't have anything against adding a CoC if this is the kind of things that would help people not being afraid of contributing. On the other hand @aleksator seems to view it negatively because of people circumventing it or distorting it. I don't know how we can solve this. Maybe we can add a line in the contribution section, something like:

We want everyone to feel welcomed, let us know with a private message on zulip if you don't feel that way.

[Eh2406]

I would be ok with that sentence in our readme. If we need to, we can always add and formalize things as we grow.
We also need to ensure that we are all welcome, so @aleksator what would make you comfortable?

[mpizenberg]

@aleksator while progressing on the changelog, I spotted this change from

/// No version exist in that range.
NoVersion(P, Range<V>),

to

/// No versions from range satisfy given constraints.
NoVersions(P, Range<V>),

Ok for the plural form but the comment is not correct. This really means that there exist no version in the given range. So for example if that range is 2.1.0 <= v it means there doesn't exist any version higher than 2.1.0 (included) for this package. I'll change it back, but was there something in particular that made this confusing for you?

[mpizenberg]

Alright guys once #65 is merged this is ready for prime time, finally! :)
Now waiting for your approval or remarks.

[Eh2406]

I'm good with it!

[aleksator]

Ok for the plural form but the comment is not correct. This really means that there exist no version in the given range. So for example if that range is 2.1.0 <= v it means there doesn't exist any version higher than 2.1.0 (included) for this package. I'll change it back, but was there something in particular that made this confusing for you?

Answered in the PR: #65 (comment)
TLDR we refer to the same thing, but my wording is more confusing.

[mpizenberg]

docs(changelog): improve changelog