search

fboender / multi-git-status

Show uncommitted, untracked and unpushed changes for multiple Git repos
MIT License
470 stars 73 forks source link

Can we get releases? #19

Closed bexelbie closed 5 years ago

bexelbie commented 5 years ago

I am packing multi-git-status for Fedora. I was wondering if you would consider creating versioned releases?

fboender commented 5 years ago

Absolutely. What would be most convenient for you? I'm thinking:

Would that work for you?

fboender commented 5 years ago

Can you take a look at commit https://github.com/fboender/multi-git-status/commit/2e6049d4286bf26ceabf5c6ec174bd6f5fc84b32? Is that satisfactory? Do you also need things such as release notes? I have no experience with Fedora packaging, only Debian / Ubuntu, but if there's anything I can do to make your life easier by including it in upstream (man page, etc), I'd be glad to do that.

fboender commented 5 years ago

In the future I'll make releases in the same way as I do for ansible-cmdb.

bexelbie commented 5 years ago

The commit looks good. I appreciate your making releases like ansible-cmdb. That is helpful and plays right into some ease of the packaging Fedora has done with forge macros :) and eases release monitoring.

I don't need Release Notes, but I wouldn't object to them. I don't know if others feel they provide more value than just reading the commit history. The rate of commits is low and releases make release monitoring easier.

Fedora encourages all packagers to suggest that upstreams add manpages. If you have one handy, lets do it. If not, I think we can survive for now :).

One question. I notice in your screenshot you call the binary multi-git-status however the code base contains mgitstatus. Is the intention to migrate the name or do you install for both?

fboender commented 5 years ago

I think I'll skip on the release notes in that case. It's a bit of work for each release, although it could be automated I guess. Given that there probably won't be many new features in multi-git-status, it doesn't seem worth the trouble.

Fedora encourages all packagers to suggest that upstreams add manpages

I can whip something up later today or tomorrow.

the binary multi-git-status however the code base contains mgitstatus. Is the intention to migrate the name or do you install for both?

I initially named the binary and the project "multi-git-status". However, "multi-git-status" is extremely annoying to type, and auto-completion on my system brings up a whole batch of other binaries starting with "mul" before completing to multi-git-status. So I renamed the script 'mgitstatus', which is easier to type. But now there's a discrepancy between the project name and the binary name, which is annoying for discoverability after installing a package, if the package is called 'multi-git-status' and the binary is called 'mgitstatus'.

I'm not sure what the best solution is, but probably we should just symlink 'multi-git-status' to mgitstatus or the other way around.

voxpelli commented 5 years ago

@fboender Maybe you can convert parts of your README to the man page?

See eg. https://www.npmjs.com/package/remark-man and also this recent Twitter thread: https://twitter.com/voxpelli/status/1155046090175131653

I also totally understand if you don't want to introduce such dependencies, just want you to be aware of the availability of such tools 🙂

bexelbie commented 5 years ago

I am not sure the mgitstatus vs multi-git-status really needs to require a project rename. I think we could easily a) do nothing; b) provide a symlink; c) have the packaging provide the alternate name (at least in Fedora I am fairly certain this can work).

I lean toward a or b. I do think we need to make sure docs, etc. are consistent.

I feel like remark-man is a massively heavy dependency for manpage generation. I don't feel rushed here, so I'd like to think about alternatives. I feel like this should be easier (Narrator: Famous last words).

fboender commented 5 years ago

I've changed all the references of 'multi-git-status' to 'mgitstatus' in the README to make things more consistent. I think I'd prefer the official project to be called "multi-git-status", but to provide everything as 'mgitstatus'. Kind of like how Apache's official name is "The Apache HTTP Server Project" but the packages are called "httpd" (they are on Fedora, right?)

I've committed a man page and its source file. See commit 86d785f41d0 The source is a Markdown file, which is converted to man/groff format using Pandoc. There's a build target 'man' in build.sla for this. But packaging shouldn't need pandoc. I'll keep the generated version in sync and committed too.

fboender commented 5 years ago

Was there anything else left to do? If not, I'll make a final pass on the docs and such to make sure they're correct and I'll create a v1.0 release.

bexelbie commented 5 years ago

I can't think of anything else at the moment. I've gotten the package landed as "multi-git-status". I can try to find out how to rename the package if you'd prefer. I can also just look into having both names work. Do you have a preference assuming either is possible?

If you want to test, it is live in Rawhide, or should be RSN (https://bodhi.fedoraproject.org/updates/FEDORA-2019-203b0bd48d). In F30 it is in testing: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c8e1c1c700 and soon to be in stable.

fboender commented 5 years ago

Cool, thanks so much for packaging it! I'll make a v1.0 release tomorrow, if I can find the time.

fboender commented 5 years ago

It kinda slipped my mind a little bit. I just made created a v1 github release. If there's anything else you need, please let me know!

bexelbie commented 5 years ago

The artifacts in the release seem slightly oddly named. They don't have the 'v' in front of the version. Were they manually created?