4 ms·

The Jekyll code base would need major refactoring to allow for the lazy evaluation when using `serve` (and it would break some plugins) and likewise for the par

The Jekyll code base would need major refactoring to allow for the lazy evaluation when using `serve` (and it would break some plugins) and likewise for the parallel builds because this is done with `fork` (as Ruby doesn’t have proper concurrency with threads due to the global interpreter lock). So rather than try to refactor Jekyll, it would probably be a better strategy to use my re-implementation as the basis for a Jekyll 4.0, I’d say it’s 95% feature compatible with Jekyll and only about 2,500 lines of code. While writing it, I did want to reach out to the Jekyll maintainers to talk about this option, but it wasn’t clear to me how to actually get in touch with them (e.g. no jekyll-dev mailing list that I could find), and I didn’t want to open an issue about this.

kroger 8y ago
The Jekyll team is listed here: https://jekyllrb.com/team/ https://jekyllrb.com/team/ I'd contact the project lead.
- sorbits 8y ago
  The project lead seems to be about ensuring the community thrives and #2 on that list is about documentation. As alluded to in my grandparent, what I was looking for was a venue to submit my open-ended thoughts about how to transition Jekyll to parallel builds and lazy evaluation, which would spark a longer discussion about the feasibility of this (e.g. how will it affect existing plugins, would it be OK for some of them to break in 4.0, at least those relying on undocumented API, etc.). Many open source projects have a mailing list only about development which is great for discussing such things, and that is what I was looking for, as sending an unsolicited email to the project lead (who is tasked with ensuring the community thrives) is just not the same thing as starting a discussion on a development mailing list.
- deleted 8y ago
  [deleted]
alwillis 8y ago
While writing it, I did want to reach out to the Jekyll maintainers to talk about this option, but it wasn’t clear to me how to actually get in touch with them Jekyll is also one of the most popular projects on GitHub, with more than 35,000 stars; it’s not hard to find: https://github.com/jekyll/jekyll https://github.com/jekyll/jekyll
- sorbits 8y ago
  Proposing my code be used as the basis of Jekyll 4.0 would be a bit controversial and require a long discussion about pros and cons, a possible migration strategy for problematic plugins etc. Call me old fashioned, but opening an issue on GitHub is just not my idea of getting in touch with the development team to discuss such things.

kroger 8y ago

The Jekyll team is listed here: https://jekyllrb.com/team/ https://jekyllrb.com/team/ I'd contact the project lead.

sorbits 8y ago
The project lead seems to be about ensuring the community thrives and #2 on that list is about documentation. As alluded to in my grandparent, what I was looking for was a venue to submit my open-ended thoughts about how to transition Jekyll to parallel builds and lazy evaluation, which would spark a longer discussion about the feasibility of this (e.g. how will it affect existing plugins, would it be OK for some of them to break in 4.0, at least those relying on undocumented API, etc.). Many open source projects have a mailing list only about development which is great for discussing such things, and that is what I was looking for, as sending an unsolicited email to the project lead (who is tasked with ensuring the community thrives) is just not the same thing as starting a discussion on a development mailing list.
deleted 8y ago
[deleted]

alwillis 8y ago

While writing it, I did want to reach out to the Jekyll maintainers to talk about this option, but it wasn’t clear to me how to actually get in touch with them Jekyll is also one of the most popular projects on GitHub, with more than 35,000 stars; it’s not hard to find: https://github.com/jekyll/jekyll https://github.com/jekyll/jekyll

sorbits 8y ago
Proposing my code be used as the basis of Jekyll 4.0 would be a bit controversial and require a long discussion about pros and cons, a possible migration strategy for problematic plugins etc. Call me old fashioned, but opening an issue on GitHub is just not my idea of getting in touch with the development team to discuss such things.