Adding a Stable Tag

[phikal]

Hi,

I'm a MELPA Stable user, which means that I can only install software from MELPA that has had a tag added to the repository to indicate a "stable" state. Sadly racket-mode doesn't seem to have any published tags, so I wanted to ask if it a (somewhat?) stable point in history could be tagged?

[greghendershott]

Although I'm not necessarily opposed to doing this, ever, I'm reluctant. I'm concerned that it might be "dishonest" --- create an expectation that I'm unable or unwilling to fulfill.

The status quo:

• I set this repo so that even I can't push commits directly to master. And I can't merge until Travis CI says the tests pass for a wide variety of versions of Rackets and Emacs. I always create a topic branch. Even to fix a doc typo. Even if the tests pass, if some feature or fix feels risky, I wait before merging.

• On the other hand, the tests are very far from 100% coverage. Also I don't administer any "beta testing" program (I'm not sure there are even enough Racket Mode users, total, for the notion of a beta tester subset to be practical).

That is the level of care and responsibility that I have time to aim for, currently.

---

As a result, I could add a "stable" release tag to some commit, from time to time. Call it "version 1.42". But honestly it would still mean "unstable" MELPA's "version date-and-time", or "version commit digest" -- the status quo, masquerading as something else.

I would not want to do this, for you, and discover I have created some expectation that I'm unwilling or unable to satisfy, for other people.

---

Having said all that, I'll mull this over.

Meanwhile you could install only Racket Mode from "unstable" MELPA. Of course I understand you might not want to do that, I just want to make sure you knew about that option.

[dedbox]

According to my totally scientific and unbiased Google search, users seem to view a MELPA stable tag like a GitHub release tag, which is as you just described. I use GitHub release tags to keep track of project state at major events like release announcements and conference talks.

In any case, if you start a backlog specifically for improving the existing code base -- tests, docs, whatever -- I would totally grind on those tickets in my spare time.

[phikal]

As long as there are plans to add a tag sometime in the future, I am satisfied. I've just run into too many projects that just forgot about it.

Meanwhile you could install only Racket Mode from "unstable" MELPA. Of course I understand you might not want to do that, I just want to make sure you knew about that option.

Yeah, I know about that possibility -- I've tried it but it never worked out the way I wanted it to. If I really needed it, I could also just clone the repo.

[greghendershott]

@dedbox If that's the expectation, I'd feel better.

@phikal I think where this trips me up is, I already use my best effort to make sure master is stable, all the time. I don't have any extra special process that I would do, to "cut a release". (If I did, I'd want to automate it and have it happen automatically for every single commit to every topic branch, too.)

And for example, when I was working on the step-debugger feature, it was on a topic branch for some weeks or months. Not iterating on master.

So if you ask me today, is HEAD stable, right now? I'd say, yes, to the best of my knowledge. And I use Racket Mode myself nearly every day, so many of its features get pretty heavily dog-fooded.

But I don't know what I don't know. And with Emacs, people can be using many different mixes of modes that I do not personally dog-food. So, I'm aware it is a pretty big set of don't-knows.

[dedbox]

On Wed, Jul 10, 2019, 10:07 AM Greg Hendershott [email protected] wrote:

But I don't know what I don't know. And with Emacs, people can be using many different mixes of modes that I do not personally dog-food. So, I'm aware it is a pretty big set of don't-knows.

By this standard, would MELPA stable be empty?

[dedbox]

Sorry if that sounded cheeky. I'm genuinely curious, but that's not so relevant.

More directly, it sounds like you're setting an impossibly high standard for an ecosystem as messy as Emacs'. Is there a better way to increase the user base to surface cross-compatibility issues?

Eric

On Wed, Jul 10, 2019, 10:28 AM Eric Griffis [email protected] wrote:

On Wed, Jul 10, 2019, 10:07 AM Greg Hendershott [email protected] wrote:

But I don't know what I don't know. And with Emacs, people can be using many different mixes of modes that I do not personally dog-food. So, I'm aware it is a pretty big set of don't-knows.

By this standard, would MELPA stable be empty?

[dedbox]

And on second thought, another way of looking at it is that you've done your due diligence in MELPA unstable (and then some), and maybe it's time to take the leap because the release process and code base are stable enough.

Of course, that's a big subjective 'maybe', because even a quality product release would entail some amount of prep and follow-up that perhaps only you could do at this point.

On Wed, Jul 10, 2019, 10:52 AM Eric Griffis [email protected] wrote:

Sorry if that sounded cheeky. I'm genuinely curious, but that's not so relevant.

More directly, it sounds like you're setting an impossibly high standard for an ecosystem as messy as Emacs'. Is there a better way to increase the user base to surface cross-compatibility issues?

Eric

On Wed, Jul 10, 2019, 10:28 AM Eric Griffis [email protected] wrote:

On Wed, Jul 10, 2019, 10:07 AM Greg Hendershott [email protected] wrote:

But I don't know what I don't know. And with Emacs, people can be using many different mixes of modes that I do not personally dog-food. So, I'm aware it is a pretty big set of don't-knows.

By this standard, would MELPA stable be empty?

[greghendershott]

Just to touch base, I haven't forgotten about this, I've just been busy and keep deferring it. Realistically it will be at least another week or two until I can look at it again.

[phikal]

I'd like to bring up the issue again, but this time not from the perspective of MELPA Stable but NonGNU ELPA, the new archive for packages without copyright assignments to the FSF. It will be enabled OOTB from Emacs 28 onwards, meaning that any package in NonGNU ELPA can be installed without any further configuration.

Compared to MELPA, NonGNU distributes "stable" or "tagged" releases by default. The ELPA build system doesn't determine these by checking for the most recent Git tag, but by finds the last commit that bumps the version attribute in the package header.

If there is any interest in adding racket-mode to NonGNU ELPA, all that has to be done is to add such a version tag (which also has the advantage that users can manually download and install the package via package-install-file) and maintain it in the future.

[greghendershott]

Thank you for following up.

Racket Mode still has the same "rolling release" model I described above.

I have no extra steps to make a "release" that is "more stable" than any other commit on the main branch.

As a result:

• Putting it on MELPA Stable: I don't have stable releases. Could I pretend to -- make up some "stable" release version number tag for every single merge to the main branch? Sure, but that would offer users nothing vs. plain MELPA, be dishonest, and be a more cumbersome workflow. More work, to get no actual benefit for anyone.

• Putting it on NonGNU ELPA: Although intended to host "stable" releases, I see a couple packages like lua-mode using timestamp "versions" like "20210802". Which is what I would do there, if I had to. But that offers users nothing vs. plain MELPA (aside from adding an item to package-archives). And it seems an even more cumbersome workflow than git tags, hacking a version string into an .el for every merge to the main branch.

---

If someone prefers stable releases to rolling releases: I understand, empathize, and respect that. I just don't have stable releases to offer.

If someone is fine with rolling releases but prefers to use NonGNU ELPA instead of plain MELPA: Although I appreciate they have a preference unfortunately I'm not willing or able to accommodate it.

[greghendershott]

If someone is fine with rolling releases but prefers to use NonGNU ELPA instead of plain MELPA: Although I appreciate they have a preference unfortunately I'm not willing or able to accommodate it.

I think that sounded kind of dogmatic.

Let's say I create some automated process that runs every 3 months. It goes into the repo, and regardless of whatever the latest commit is, bumps the version string in racket-mode.el to "YYYY-Q" or "X.Y" or whatever, and commits that. Soon after, NonGNU ELPA notices and says I have a new version.

So it's easy for me. And it's on NonGNU ELPA. And everyone is happy.

Right?

Really??

• I won't get people asking, "Well, where are the release notes?" and "How could such a serious bug have ended up in a stable release?" and so on? It's supposed to be a stable release. This entails expectations. Why else would some people prefer stable to rolling? They don't prefer it for no reason. There are reasons.

• If a serious bug is fixed, and it's urgent enough not to wait for the next quarterly auto-release, what do I do? Do I tell people, "just wait N months", or "switch to MELPA for now", with a straight face? Or am I now in the business of doing "hot fix" stable point releases?

• If a less-serious bug is fixed, do I make users decide whether they want to cross that rolling vs. stable boundary, just for that fix?

I just don't understand how my reality of rolling releases, would map onto the (entirely reasonable) expectations of people who expect stable releases to be.... stable releases, including all the associated perceived benefits.

[phikal]

You may be interested in this thread. The current proposal is to extend ELPA by a option to have "rolling release" packages (i.e. like the devel archive), if packages like yours use this development model. As you have already said that you do your best to keep the master branch stable, I think that this would be a good compromise, do you agree?

[greghendershott]

Thank you for following up.

We could add to elpa-admin.el some flag that makes it behave the same for the -devel and the non-devel repositories

I don't understand how that works, so a dumb question:

Would this mean I wouldn't even need to add artificial, periodic "Just bumping the 'version' in racket-mode.el" commits?

If so that sounds better than a good compromise, it sounds perfect.

Otherwise I'd like to learn more.

(Either way, I appreciate the user-expectations discussion elsewhere in that thread, that's helpful!)

[phikal]

Greg Hendershott @.***> writes:

Thank you for following up.

We could add to elpa-admin.el some flag that makes it behave the same for the -devel and the non-devel repositories

I don't understand how that works, so a dumb question:

Would this mean I wouldn't even need to add artificial, periodic "Just bumping the 'version' in racket-mode.el" commits?

Yes.

If so that sounds better than a good compromise, it sounds perfect.

Ok, I will see what can be done.

Otherwise I'd like to learn more.

(Either way, I appreciate the user-expectations discussion elsewhere in that thread, that's helpful!)

I might have missed that, what are you referring to?

-- Philip Kaludercic

[greghendershott]

Ok, I will see what can be done.

Thank you!

(Either way, I appreciate the user-expectations discussion elsewhere in that thread, that's helpful!)

I might have missed that, what are you referring to?

Probably "discussion" over-states it; I just meant: https://mail.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg01818.html

Remember, my whole introduction to NonGNU ELPA is via this issue, titled "Adding a Stable Tag". Plus the NonGNU ELPA web site packages mostly do have "stable"-like version numbers. Plus the web site doesn't talk about "stable" vs. "rolling" --- is it silent because "stable" is assumed as the obvious right thing, or, because it's not trying to take a position either way? It helped to see Stefan Kangas say it's the latter. Even if that's just the opinion of one maintainer and not "official GNU policy", it's more than nothing; it's some indication.

Combine that with:

• A few packages there already seemingly use a rolling date for "Version".

• A proposed devel flag to automate that.

And it sounds encouraging, especially with the final item.

[phikal]

After an inanpropriate delay, support for rolling release packages has been added to {NonGNU,GNU} ELPA. If you are still interested, we can progress with adding racket-mode to NonGNU ELPA.

[greghendershott]

Thanks for following up.

A few questions:

1. So IIRC you would add Racket Mode using the new :rolling-release attribute. Going forward, if I push a new commit to the repo here on GitHub, it would automatically update on NonGNU ELPA, much like with MELPA?

2. On MELPA, the "version numbers" are timestamps. Out of curiosity, would it look like non NonGNU ELPA?

3. It look like a few packages currently use :version-map for what seems to be a rolling release, for example:

   ("smartparens"		:url "https://github.com/Fuco1/smartparens"
     :ignored-files ("LICENSE" "dev" "doc" "images" "test")
     ;; See https://github.com/Fuco1/smartparens/issues/1095
     ;;
     ;; Until a version tag is added, the commit of the latest tag is
     ;; used to mark the last stable release:
     ;; https://github.com/Fuco1/smartparens/releases/tag/1.11.0
     :version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
   

   Out of curiosity, do you expect to change these to use :rolling-release, instead?

[greghendershott]

Two tiny questions/concerns:

1. The rules in README.org include:

   *** The package must follow the rules in https://www.gnu.org/prep/standards/, node References. This means it may not refer users to any nonfree software or nonfree documentation, except as stated there. Leading users to run a program, and suggesting they run it, or depending on it to be installed, are forms of referring users to it.

   Although I'm not aware of doing this, currently, I also don't worry about it. If some Emacs or Racket package seems relevant, then I just point it out to people -- on the theory it's information: Each person can decide if it is actually useful, and, usable (licensing), for them.

   In practice is that going to be OK, or, be a Huge Issue if something has e.g. MIT or no explicit license at all?

2. The MELPA package definitions are in terms of files to include, whereas the NonGNU ELPA ones seem to be in terms of files to ignore. So e.g. once upon a time I added a new top-level tests directory -- but didn't need to ask for the MELPA definition to be updated. If I do that going forward, I'd need to contact you wrt :ignored-files, correct?

   (I'm not objecting, or asking you to change the definition model just for me. Really I'm just double-checking what I might need to remember to do differently.)

[phikal]

Greg Hendershott @.***> writes:

Thanks for following up.

A few questions:

1. So IIRC you would add Racket Mode using the new :rolling-release attribute. Going forward, if I push a new commit to the repo here on GitHub, it would automatically update on NonGNU ELPA, much like with MELPA?

Right.

2. On MELPA, the "version numbers" are timestamps. Out of curiosity, would it look like non NonGNU ELPA?

ELPA uses "inverted timestamps", ie. it appends the timestamp to the current value of the version tag. Take for example org-mode: https://elpa.gnu.org/devel/org.html. The version is: org-9.6pre0.20221107.72305

This makes switching between development snapshots and actual releases easier.

3. It look like a few packages currently use :version-map for what seems to be a rolling release, for example:

   ("smartparens"		:url "https://github.com/Fuco1/smartparens"
     :ignored-files ("LICENSE" "dev" "doc" "images" "test")
     ;; See https://github.com/Fuco1/smartparens/issues/1095
     ;;
     ;; Until a version tag is added, the commit of the latest tag is
     ;; used to mark the last stable release:
     ;; https://github.com/Fuco1/smartparens/releases/tag/1.11.0
     :version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
   

No, this is used to pin a release for packages that don't have a version tag. As I have mentioned above, the version tag is prepended to the timestamp, so it is still necessary for the package to have a non-0 version (which won't mean much, and might as well consist of a single number).

Out of curiosity, do you expect to change these to use `:rolling-release`, instead?

This has not been discussed. The main problem with these packages is that they don't follow the packaging conventions that are elaborated in (elisp) Simple Packages, requiring packages to have a proper version tag. If the maintain requests the usage of a "rolling release" system, we can grant that, but it is preferred to use the regular release system.

Greg Hendershott @.***> writes:

Two tiny questions/concerns:

1. The rules in README.org include:

   *** The package must follow the rules in https://www.gnu.org/prep/standards/, node References. This means it may not refer users to any nonfree software or nonfree documentation, except as stated there. Leading users to run a program, and suggesting they run it, or depending on it to be installed, are forms of referring users to it.

   Although I'm not aware of doing this, currently, I also don't worry about it. If some Emacs or Racket package seems relevant, then I just point it out to people -- on the theory it's information: Each person can decide if it is actually useful, and, usable (licensing), for them.

   In practice is that going to be OK, or, be a Huge Issue if something has e.g. MIT or no explicit license at all?

NonGNU ELPA does not insist on GPL code, as NonGNU ELPA packages are explicitly not part of Emacs (as opposed to GNU ELPA). So MIT shouldn't be a problem. No license is tricky, because that is -- legally speaking -- non-free code that you are not allowed to modify, distribute, etc. Is this something you anticipate?

2. The MELPA package definitions are in terms of files to include, whereas the NonGNU ELPA ones seem to be in terms of files to ignore. So e.g. once upon a time I added a new top-level tests directory -- but didn't need to ask for the MELPA definition to be updated. If I do that going forward, I'd need to contact you wrt :ignored-files, correct?

You can also maintain these in your repository, by adding an .elpaignore file that will list files to be excluded during packaging (in the backend this makes use of GNU tar's "-X" flag).

(I'm not objecting, or asking you to change the definition model

just for me. Really I'm just double-checking what I might need to remember to do differently.)

No problem, I'm glad to help!

All of this is documented in greater detail in the ELPA-Admin README: https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README?h=elpa-admin.

[greghendershott]

NonGNU ELPA does not insist on GPL code, as NonGNU ELPA packages are explicitly not part of Emacs (as opposed to GNU ELPA). So MIT shouldn't be a problem. No license is tricky, because that is -- legally speaking -- non-free code that you are not allowed to modify, distribute, etc. Is this something you anticipate?

No, I don't anticipate it. I was trying to say that I don't think about it, at all. If some package seems potentially useful, my inclination is to mention it -- and let each user do their own due diligence. The rule seems to say I should not even talk about the existence of non-free items (or whatever "refer" means here).

Probably I am over-thinking this rule. If, someday, I list some "suggested package" that turns out to have a license defect, we can figure it out, then.

You can also maintain these in your repository, by adding an .elpaignore file that will list files to be excluded during packaging (in the backend this makes use of GNU tar's "-X" flag).

Oh, great. I had skimmed both README and README.org, but overlooked that.

---

Thank you very much for your help explaining things. I think it all looks good now. What would be the next steps?

Should I for example:

• [ ] Add such an .elpaignore
• [ ] Add back a Version: field to racket-mode.el (which I'd intentionally removed when I realized was really doing a rolling release)
• [ ] Give you my attempt at the package definition for https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/elpa-packages

[greghendershott]

I added a commit 22f45f6 with a first draft of updating racket-mode.el as well as adding a .elpaignore.

[phikal]

Greg Hendershott @.***> writes:

NonGNU ELPA does not insist on GPL code, as NonGNU ELPA packages are explicitly not part of Emacs (as opposed to GNU ELPA). So MIT shouldn't be a problem. No license is tricky, because that is -- legally speaking -- non-free code that you are not allowed to modify, distribute, etc. Is this something you anticipate?

No, I don't anticipate it. I was trying to say that I don't think about it, at all. If some package seems potentially useful, my inclination is to mention it -- and let each user do their own due diligence. The rule seems to say I should not even talk about the existence of non-free items (or whatever "refer" means here).

Probably I am over-thinking this rule. If, someday, I list some "suggested package" that turns out to have a license defect, we can figure it out, then.

I would also expect that if any issue like this were to arise, they could usually be resolved by a simple email exchange.

You can also maintain these in your repository, by adding an .elpaignore file that will list files to be excluded during packaging (in the backend this makes use of GNU tar's "-X" flag).

Oh, great. I had skimmed both README and README.org, but overlooked that.

Yeah, they are a bit messy.

---

Thank you very much for your help explaining things. I think it all looks good now. What would be the next steps?

Should I for example:

• [ ] Add such an .elpaignore

Yes.

• [ ] Add back a Version: field to racket-mode.el (which I'd intentionally removed when I realized was really doing a rolling release)

Yes.

• [ ] Give you my attempt at the package definition for https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/elpa-packages

That is not necessary, I can take care of that.

[phikal]

Here is my current build log:

$ make build/racket-mode
emacs --batch -Q -l admin/elpa-admin.el \
         -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
emacs --batch -l /home/philip/Source/nongnu/admin/elpa-admin.el	\
         -f elpaa-batch-make-one-package racket-mode
Cloning branch racket-mode:
+refs/heads/*:refs/remotes/origin/*
Preparing worktree (resetting branch 'elpa/racket-mode'; was at 3b92a5bfcb)
HEAD is now at 22f45f6284 Prepare to be added to NonGNU ELPA

======== Building tarball archive-devel/racket-mode-1.0.20221107.124046.tar...

racket-mode.texi:754: warning: @image file `scenario-0' (for HTML) not found, using `scenario-0..svg'
racket-mode.texi:760: warning: @image file `scenario-1' (for HTML) not found, using `scenario-1..svg'
racket-mode.texi:764: warning: @image file `scenario-2' (for HTML) not found, using `scenario-2..svg'
racket-mode.texi:768: warning: @image file `scenario-3' (for HTML) not found, using `scenario-3..svg'
racket-mode.texi:772: warning: @image file `scenario-4' (for HTML) not found, using `scenario-4..svg'


######## Built new package archive-devel/racket-mode-1.0.20221107.124046.tar!
======== Building tarball archive/racket-mode-1.0.20221107.124046.tar...

racket-mode.texi:754: warning: @image file `scenario-0' (for HTML) not found, using `scenario-0..svg'
racket-mode.texi:760: warning: @image file `scenario-1' (for HTML) not found, using `scenario-1..svg'
racket-mode.texi:764: warning: @image file `scenario-2' (for HTML) not found, using `scenario-2..svg'
racket-mode.texi:768: warning: @image file `scenario-3' (for HTML) not found, using `scenario-3..svg'
racket-mode.texi:772: warning: @image file `scenario-4' (for HTML) not found, using `scenario-4..svg'


######## Built new package archive/racket-mode-1.0.20221107.124046.tar!

I have also attached a tarball to this message so you can see how that looks like (I had to compress it because GitHub rejects plain .tar files?):

racket-mode-1.0.20221107.124046.tar.gz

Your .texi trick seems to have worked.

[greghendershott]

Your .texi trick seems to have worked.

Well, not quite. Experimenting with tar -X .elpaignore I noticed it let slip a couple files with 3-letter extensions, .org and .css.

I was trying to be too clever, forcing it into an inclusion rule. I just changed that.

Also I fixed some other things in .elpaignore (e.g. it was including the whole test subdirectory), which I just force-pushed to that topic branch in commit 7499927.

---

As for those five image files: I'm not sure why it's referring to "(for HTML)" as opposed to the Info generation. I do generate HTML for the https://racket-mode.com web site. I'm not sure why your build script would attempt that by default? Are those warnings harmless in your opinion, or do we need to work on that?

[phikal]

Greg Hendershott @.***> writes:

Your .texi trick seems to have worked.

Well, not quite. Experimenting with tar -X .elpaignore I noticed it let slip a couple files with 3-letter extensions, .org and .css.

I was trying to be too clever, forcing it into an inclusion rule. I just changed that.

Also I fixed some other things in .elpaignore (e.g. it was including the whole test subdirectory), which I just force-pushed to that topic branch in commit 7499927.

That seems to have worked.

Generally, do you force-push a lot? ELPA that prefers to fast-forward the mirror if possible, so force-pushing can cause conflicts.

As for those five image files: I'm not sure why it's referring to "(for HTML)" as opposed to the Info generation. I do generate HTML for the https://racket-mode.com web site. I'm not sure why your build script would attempt that by default? Are those warnings harmless in your opinion, or do we need to work on that?

The documentation for every package is converted both to .texi and to .html, one to be bundled with the package another to be distributed on elpa.{non,}gnu.org (see https://elpa.nongnu.org/nongnu/doc/). My best guess would be that that caused the message, but I would have to investigate the issue some other time to be sure.

Either way, it is not a blocking issue.

[greghendershott]

Generally, do you force-push a lot? ELPA that prefers to fast-forward the mirror if possible, so force-pushing can cause conflicts.

Absolutely never to the main branch (master), to which ELPA would be pointed. In fact I have GitHub branches configured to guard against this.

Sometimes I do force-push to a "topic" branch -- as in this case, the nongnu-elpa branch -- particularly if I know I'm going to squash down to one commit before merging, anyway. And if the spirit is to fix some typo or dumb mistake in the previous commit, and I don't think anyone is really following along with the changes one by one. Sorry if that caused any confusion, for you, here!

[greghendershott]

As for the doc warnings, thanks for confirming that.

I think I've done all I need to, on my end? Of course please let me know if there's more that I should do, or anything I can do to help you.

[phikal]

Greg Hendershott @.***> writes:

Generally, do you force-push a lot? ELPA that prefers to fast-forward the mirror if possible, so force-pushing can cause conflicts.

Absolutely never to the main branch (master), to which ELPA would be pointed. In fact I have GitHub branches configured to guard against this.

Great!

Sometimes I do force-push to a "topic" branch -- as in this case, the nongnu-elpa branch -- particularly if I know I'm going to squash down to one commit before merging, anyway. And if the spirit is to fix some typo or dumb mistake in the previous commit, and I don't think anyone is really following along with the changes one by one. Sorry if that caused any confusion, for you, here!

No worries, I just wanted to preempt any future issues.

Greg Hendershott @.***> writes:

As for the doc warnings, thanks for confirming that.

I think I've done all I need to, on my end? Of course please let me know if there's more that I should do, or anything I can do to help you.

It looks like it. I'll try and find the time to test the package this week and report back if there are any issues or of the package was released.

[greghendershott]

Oh, if you're pointing ELPA to the master branch at GitHub, I should probably go ahead and merge my changes from the topic branch to that main branch.

Even if there were problems or additional changes to make wrt to NonGNU ELPA, that should be N/A with respect to everything else (nothing else looks at .elpaignore, or really cares about the Version or Maintainer metadata in racket-mode.el, AFAICT).

[greghendershott]

As a heads up, I just merged a commit changing a few .md files to .org, including the package's README.

So I think the definition would now be something like:

 ("racket-mode"             :url "https://github.com/greghendershott/racket-mode"
  :rolling-release t
  :readme "README.org")

or even (IIUC) simply:

 ("racket-mode"             :url "https://github.com/greghendershott/racket-mode"
  :rolling-release t)