Major issues triaging

[dmaluka]

I've added major label to some issues that are confirmed to be actual non-minor bugs (e.g. crashes, hangups, horribly slow performance, risk of losing user data, major UI annoyances etc), so that we remember which issues among 760+ open issues we should probably address with higher priority than others.

I haven't examined the entire list of those 760 issues (obviously), so these issues I've added to major are just those important issues that I happen to know/remember about. Pretty certainly there are more.

@JoeKar FYI. If you have some other known important issues in mind, feel free to add this label to them (but also let's try not to make this list too long, it would defeat the purpose).

[JoeKar]

Good idea. 👍

Edit:
Realized, that we are able to add milestones -> v2.0.14

Shall we add all of them to the next minor milestone? Especially the performance issues need a larger rework, which maybe break API compatibility.

[dmaluka]

Thanks, good to know. I've also added #3148 to it, since I think it is really important (as btw a really basic functionality for a text editor, which should have been implemented long ago).

Maybe let's not add more to this milestone for now?

[JoeKar]

Maybe let's not add more to this milestone for now?

I saw you added #2839 to legitimate #3127. Hopefully this plan isn't to overambitious and the next release not delayed too much.
The last two weeks I wasn't able to contribute anything due to vacation.

I can understand everyone waiting for the next release including more than 220 commits already.

I plan to add one more PR to the milestone, since I like to reduce our effort and mail ping-ponging for the upcoming release(s):

We already created the GitHub action for the nightlies and the most of the stuff, which we now need, is already present and tested. It shouldn't be much more work to add a new "release" action waiting for a semver tag to be created to automatically create the same asset files as we've with the nightly in the moment of tag creation.
For the maintainers it then only requires to create the tag...nothing more and nothing less. 😃

[dmaluka]

I saw you added #2839 to legitimate #3127.

Yep, since I owe you the review of #3127. Well, if there is such an impatience for 2.0.14, I'm fine with postponing it until 2.0.15 (if you are fine with that too). I realize that realistically the review of #3127 will not finish very soon. (Although I already added some new comments in #3127 (not sure if you already saw them), I'm still yet to get a good understanding of the implementation.)

And regarding #3148, since it turns out to be not so easy, and it is partially mitigated by #3009, I'm also fine with postponing it (again, if you are also fine with that).

Maybe let's at least finalize reviewing and merge #3353 and #3352 before the release, they seem quite useful and are probably ready for merging? Maybe also some others? (I also wanted to suggest #3335, but it changes behavior of existing actions, strictly speaking in an incompatible way, so may not be a good idea to merge it right before the release.)

And after merging those PRs, maybe let's not make the release right away, but first freeze merging PRs and let ourselves and others test the newest master for a week or two, to reduce the risk of regressions in the new release?

I plan to add one more PR to the milestone, since I like to reduce our effort and mail ping-ponging for the upcoming release(s):

Which PR?

We already created the GitHub action for the nightlies and the most of the stuff, which we now need, is already present and tested. It shouldn't be much more work to add a new "release" action waiting for a semver tag to be created to automatically create the same asset files as we've with the nightly in the moment of tag creation.
For the maintainers it then only requires to create the tag...nothing more and nothing less. 😃

We'd need to be careful not to make a release accidentally then, by creating a tag. :)

I see we have tools/release.sh, can't we use it? (And BTW we also have tools/nightly-release.sh. Is it obsoleted or what?)

[dmaluka]

For other reference, the context is this mini-discussion: #3380 (comment)

[JoeKar]

Well, if there is such an impatience for 2.0.14, I'm fine with postponing it until 2.0.15 (if you are fine with that too). I realize that realistically the review of #3127 will not finish very soon. (Although I already added some new comments in #3127 (not sure if you already saw them) [...]

For myself it doesn't matter, since I use the master or feature I'm working at. I'd go with the wish of the community.

I realize that realistically the review of #3127 will not finish very soon. (Although I already added some new comments in #3127 (not sure if you already saw them)

Yes and even if the review is finished for the moment I assume a lot of rework and testing again, till it's stable (since I know myself). and yes, I saw your comments already, but didn't focus on the highlighter PR again so far. I like to finalize my other already reviewed PRs first. So yes, unfortunately it isn't really realistic to have it included in the upcoming v2.0.14. Let us shift it to v2.0.15 as earliest release for it. Maybe it's then created faster than v2.0.14.

Maybe let's at least finalize reviewing and merge #3353 and #3352 before the release, they seem quite useful and are probably ready for merging?

Yep, for sure. I will try to have a look into their reviews too.
I've to excuse my lack of (free) time. This project deserves more, but obviously still lacks on resources (with sufficient permissions).

Maybe also some others?

I would not be surprised.

And after merging those PRs, maybe let's not make the release right away, but first freeze merging PRs and let ourselves and others test the newest master for a week or two, to reduce the risk of regressions in the new release?

That's a good idea. Here the community is encouraged to support with tests and daily usage to find possible regressions.

Which PR?

It's not created yet.

We'd need to be careful not to make a release accidentally then, by creating a tag. :)

Ok, maybe it's possible to start the action manually and give the tag as input. This gives the user with sufficient permissions some time to overthink the situation.

I see we have tools/release.sh, can't we use it? (And BTW we also have tools/nightly-release.sh. Is it obsoleted or what?)

Have a look into these scripts. All will use hub (local git extension) to interact with the GitHub API, for which you maybe need additional tokens...at least I'm not 100% sure here. What I know is, that I don't plan to use this kind of extension, when GitHub is already able to perform this kind of process directly at the server with the amount of automatism we like to have.

Edit:

Which PR?

It's not created yet.

It's #3397

[JoeKar]

Since v2.0.14-rc1 hit the road and v2.0.14 should be more or less one tag more to v2.0.14-rc1 it's now the question if we follow the agreement of releasing it around one week later when we don't discover any regressions?

[dmaluka]

Now with 2.0.14 released, should we remove 2.0.14-rc1? It consumes a lot of space on the https://github.com/zyedidia/micro/releases page, without much use since it is the same as 2.0.14?

Or maybe not remove it but clear its release notes (e.g. just leave a single line "Release candidate for Micro 2.0.14")?

[JoeKar]

[...] So no contributor is missed then.

Then it would be the opposite. Does it really care how long this list is? 🤔

[dmaluka]

Ah, if that is the point, why not add the full list of contributors to the 2.0.14 release notes instead? It seems to be the right place for it? Let me try...

2.0.14-rc1 release notes simply occupy disproportionally much space compared to its importance/usefulness, once we have 2.0.14.

[JoeKar]

Thank you for doing so. Now we can shrink v2.0.14-rc1 as suggested by you.

[dmaluka]

Ah, if that is the point, why not add the full list of contributors to the 2.0.14 release notes instead? It seems to be the right place for it? Let me try...

Done. Now there are 2 lists in the release notes: the full list of contributors and the full list of their userpics (seems there is no way around it with Github's UI, we have either both or none), so looks a little bit weird, but probably fine.

[JoeKar]

We should discuss how to proceed with bugs like...

• "cd a\" raises exception (Windows) #2666
  • unquote: Fix possible out of bounds access in splitWord() under Windows go-shellquote#1
• micro shows previous mangled text when scrolling up after resizing the terminal #3073
  • Enhanced Windows VT mode, and ALTSCREEN support gdamore/tcell#692
    • console_win: Try VIRTUAL_TERMINAL_PROCESSING aka modeVtOutput first and switch to alternate screen processing tcell#26 (should be replaced by the above)
• Binding raw escape sequences doesn't work #2950
  • Add support for parsing raw hex values via \x json5#1

...or long story short:
How do we plan to proceed with dependencies already forked but not under our control resp. where we've no sufficient rights.

Currently we have open issues with:

• https://github.com/zyedidia/go-shellquote
• https://github.com/zyedidia/tcell
• https://github.com/zyedidia/json5

As discussed within #2956 the best option is to have them (as well as micro itself) within the micro-editor organization, but this doesn't seem to happen in the near future.
The (best) alternative we have could be to fork them by our self into our space and exchange the dependency location within micro.

I'm open for ideas.

[dmaluka]

Forking them on our own seems to be the obvious (the only?) solution.

[dmaluka]

Or we could ask @zyedidia once again to grant us the permissions...

[JoeKar]

The maintainer role in the org should be feasible to do the necessary forks in there by our self.
At least it wouldn't be the workaround over our spaces.

Looks like we've to ping him once again directly via mail.

[JoeKar]

Considering the *.deb installation method (mentioned in #3254 (reply in thread)) questionable there is even a much more questionable decision in micro's history:
The second highlighted installation method present at https://micro-editor.github.io/ pointing to https://getmic.ro/ (under the control of @benweissmann?) pointing to (the content of) index.sh (as of now they don't differ).

So we point two times to an external resource not under the control of micro and advice the user to blindly interpret the content within his shell?

Domain Name: getmic.ro
Registered On: 2017-10-28
Expires On: 2024-10-26
Registrar: Gandi SAS
Referral URL: www.gandi.net

Expires in two months unless it isn't extended...

[dmaluka]

Indeed, weird. It was added by @zyedidia in micro-editor/micro-editor.github.io@745d778 but I've found no trace of a reason for that.

Also for example we have an open issue #1190...

One more reason to ask @zyedidia to grant us maintainer permissions for https://github.com/micro-editor/micro-editor.github.io. Who are its present maintainers, anyway?

[benweissmann]

Hey there! I'm the maintainer of getmic.ro. Zachary and I know each other tangentially, well enough that i guess he trusted me enough to suggest getmic.ro on the README.

Just to share a couple data points about getmic.ro:

• It's fairly popular. It's been used about 344,000 times from about 51,000 unique IPs in the past year.
• I've taken pains to separate the security of the getmic.ro repository from the getmic.ro production infrastructure; I've intentionally avoided automated deploys from the repo so that being able to edit the code on Github is separate from being able to publish to production.
• getmic.ro itself is hosted on AWS, using S3 + Cloudfront for static hosting. The AWS account is set up with a strong, randomly-generated password, and 2fa using hardkeys (2 redundant Yubikeys). AWS cloudtrail logging is set up to write to a bucket with object versioning to log all operations on the AWS account.
• The domain is registered through Gandi (since AWS Route53 Registrar doesn't support .ro domains), with DNS hosted on AWS Route53. Auto-renewal is enabled; i believe it kicks in about a month before the expiration date.

I'd be happy to transfer the gitmic.ro Github repository over to the micro-editor organization, if you'd like. Security-wise, I'd reiterate the control of the production infrastructure is entirely separate from control of the Github repo (to de-risk compromise of the Github repo, as well as to lower the barrier to adding additional committers to the repo). I'd also be happy to transfer the domain and/or the AWS account to the new maintainers of Micro (is sounds like Zachary has stepped back from the project?), under the following conditions:

• With the approval / at least no objections from Zachary
• If you'd like me to transfer the AWS organization, I'd request that you take over billing. I'm not comfortable giving access to the organization to anyone else while I'm footing the bill; the current bill is quite low (about $1.50/mo, of which $1.30/mo is the fixed costs of the DNS zone + KMS key for Cloudtrail log encryption and ~$0.20/mo is the variable costs of serving production traffic) but obviously with access to the AWS account, the new owner could rack up all sorts of charges.
• I'd want to discuss your plans for managing access control and securing the organization; as you've pointed out, the security of the production infrastructure is critical to the security of getmic.ro users. In particular, I'd want to be comfortable with your process for vetting any future maintainers who would have access to the AWS infrastructure, and for incident response / breach recovery processes if the production infrastructure were to be compromised by an outside actor or malicious maintainer.

[dmaluka]

Thanks for the extensive details. Sounds like we have no problem here: if you are gonna be around and keep maintaining getmic.ro and its server infrastructure (e.g. address issues with getmicro.ro if we report any, and so on), not abandon it, we can probably keep things as is for now.

Speaking for myself, I wasn't even thinking about taking over getmic.ro or the domain (god forbid), I was only wondering if we should keep recommending using it at micro's webpage https://micro-editor.github.io (I was taking about granting us permissions to this webpage, not to https://getmic.ro itself). If https://getmic.ro was abadoned (as github projects are more often than not), I think we would just need to remove this recommendation from the webpage, it's not a big deal to download a tarball or use a package manager instead, like normal people do.

is sounds like Zachary has stepped back from the project?

He is still the maintainer but barely spends any time on the project. He gave @JoeKar and me maintainer rights a few months ago (after we were spending tons on time on reviewing various PRs yet they were not getting merged, as Zachary had no time to look at them).

[JoeKar]

I wasn't even thinking about taking over getmic.ro or the domain (god forbid), I was only wondering if we should keep recommending using it at micro's webpage https://micro-editor.github.io/ (I was taking about granting us permissions to this webpage, not to https://getmic.ro/ itself).

I had exactly the same in mind. It wasn't about maintaining getmic.ro, but rather dropping the recommendation to use this kind of procedure.
We now know the details (for now) and may trust, but what's about the casual end-user get used to this approach?
Does he overthink the possible consequences of his doing (even in much more shady situations)? I don't think so and I would recommend not to get used to it.

micro is also present here, where it's highlighted as bad practice.

As already said, it's my personal opinion.

[dmaluka]

what's about the casual end-user get used to this approach?
Does he overthink the possible consequences of his doing (even in much more shady situations)? I don't think so and I would recommend not to get used to it.

These were my thoughts too.
I'm afraid many got used to it already (51000 last year according to @benweissmann).