Package release

[alphapapa]

I think we should go ahead and get this on MELPA. The client-ng/API-0.3.0 branch can continue, but I don't think we should wait for that to release the package, because as far as I'm concerned, there's no urgency or deadline for that branch to merge to master (although it may not be that far from being ready).

@jgkamat What do you think? :) If you agree, let's put together a checklist for release...

[alphapapa]

Release checklist

• Ensure macros and functions begin with package prefix
• Update dependency headers
• Perhaps tidy up and rearrange some defs among files
• Update headers and commentaries
  • Update authorship/credits/history info
• Ensure lexical-binding is used in all files
• Write readme
  • Maybe shameless plug for frame-purpose.el which helps to make a dedicated Matrix frame
  • Document security issues regarding how access token is (optionally) stored
• Check all package-lint warnings
• Fix byte-compile warnings
• Test installing in MELPA sandbox
• autoloads
• tab-complete usernames (optionally with @ prefix?) when input is empty (this might be easier in the client-ng branch where we save more room state)
• Ability to accept room invitations (users would probably be surprised if they have to use Riot to do this)
• ...?

[jgkamat]

Yup, this sounds good to me! I'll give another look over to the melpa guide and make sure we aren't missing anything, but I don't think we did so far. I'll start to work on some of the points as well :)

[alphapapa]

Yeah, we'll need to do a full check with package-lint, test installing it in the sandbox, etc. All the "usual" things I do but easily forget to do for a new package. :)

[alphapapa]

Actually I think we need to slow down a bit. I think we definitely need to resolve #25 before we consider any kind of official release or package. Maybe we don't need request anymore. Maybe we could write a few wrapper functions or macros and use url. However, like I said in that issue, we need to confirm that it doesn't leave temp files or expose URLs in command line arguments.

[tidux]

Bumping now that #25 is closed.

[alphapapa]

@tidux Thanks. Actually, since you prompted me to look at it, I reopened that issue, because I think it needs to be looked at again.

But besides that, I'm not currently interested in publishing this on MELPA because of all the extra requirements that entails. Not being subject to MELPA's stricter requirements allows the code to be more interesting and fun to work on (Matrix can be a bit tedious at times).

Also, I don't know what the long-term prospects of this package are. Matrix, as a protocol, seems to be getting more complicated, and if it requires significant changes to this package to maintain compatibility in the future, I don't know if I'll keep my interest in it. And I wouldn't want to publish it on MELPA and then have it break someday.

So for now, I think it's best to let users install it with Quelpa or similar tools.

[Thaodan]

But besides that, I'm not currently interested in publishing this on MELPA because of all the extra requirements that entails. Not being subject to MELPA's stricter requirements allows the code to be more interesting and fun to work on (Matrix can be a bit tedious at times).

What kind of restrictions?

Calling something not "fun" that has reasons sounds a bit strange to me.

[lebensterben]

You can always fork this repository if you found it fun to do whatever you think. You however are not in the position to ask people to do what they decide not to.

[Thaodan]

You however are not in the position to ask people to do what they decide not to.

Did you actually read my comment? I asked a question about what restrictions hold them back not what decided not do. In any case I don't see that you in the position (to use your lingo Herr Leben) to tell me in what position I am and not.

[lebensterben]

Did you actually read my comment?

In this PR you request a change to just to work with how your Emacs is built.
#103 (comment)

Here the author introduced an alternative UI but you made a comment about "trustfulness". I completely missed your point.
#15 (comment)

And in this issue you just made your judgement on the choice of the author. Does anyone asked you for your opinion on whether it's okay not to feel fun to do something?

In any case I don't see that you in the position (to use your lingo Herr Leben) to tell me in what position I am and not.

I don't know what you call a nobody coming out from thin air, judging other people's choices, and demanding features, but not making any contribution himself.

[Thaodan]

> Did you actually read my comment? In this PR you request a change to just to work with how your Emacs is built. #103 (comment) 10

Nope I linked how it was done there as reference if someone (that someone could be me) want to continue on that. I listed my own experience using just that nothing else.

Here the author introduced an alternative UI but you made a comment about "trustfulness". I completely missed your point. #15 (comment) 101

Why don't you comment on that then?

And in this issue you just made your judgement on the choice of the author. Does anyone asked you for your opinion on whether it's okay not to feel fun to do something?

The project is open in public if you are allowed to decide something and are against people commenting on the project that disable that.

> In any case I don't see that you in the position (to use your lingo Herr > Leben) to tell me in what position I am and not. I don't know what you call a nobody coming out from thin air, judging other people's choices, and demanding features, but not making any contribution himself.

I did not demand anything I shared my experiences and my opinions. Stop turning what I say around, if you don't like my opinion ignore it, thanks.

[jgkamat]

Björn Bidar writes:

What kind of restrictions?

Melpa's restrictions are documented on their contributing docs: https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org#making-your-package-ready-for-inclusion

Calling something not "fun" that has reasons sounds a bit strange to me.

The primary motivation for working on any project (without pay, I suppose) is fun. I hope that context makes things more clear.

[Thaodan]

> What kind of restrictions? Melpa's restrictions are documented on their contributing docs: https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org#making-your-pack age-ready-for-inclusion

I guessed that, I thought there are some in particular that create issues and could be helped with.

> Calling something not "fun" that has reasons sounds a bit strange to me. The primary motivation for working on any project (without pay, I suppose) is fun. I hope that context makes things more clear.

It does thanks. My point is that these restrictions while not bein fun have a reason.

[alphapapa]

Everyone, I appreciate your comments of interest and support, but please, let's be friendly to each other. This is Emacsland, after all, and we all share common interests and goals.

My point is that these restrictions while not bein fun have a reason.

@Thaodan I have published a few MELPA packages, and I often review new submissions. I am aware of the issues involved. Fixing up this package to make it suitable for publishing on MELPA would require a lot of work, which I'm not inclined to do anytime soon, as I have many other, higher priorities. Instead, I started a new client, designed to be suitable for publishing from the beginning. If you're interested in helping with it, feel free (though, be advised that it is not a high priority for me now, either). https://github.com/alphapapa/ement.el#rationale

[alphapapa]

Closing issues and archiving repository. Please see https://github.com/alphapapa/ement.el for the new client.