Actual relase

[carrotIndustries]

#159 has turned out to be more of a wishlist than features really essential for a release. Several people are already using horizon EDA for actual projects, so a release with the current set of features seems appropriate.

Some non-feature things that we'll need to work out:

• Version number "1.0" seems ok. Are there any existing packaging options that would break?
• Several people hinted that user documentation might be nice
• Improve out-of-the-box experience: explain what pools are and how to use them (either use pool manager's github integration or use git manually)
• Update sales pitch (https://github.com/carrotIndustries/horizon/wiki/Feature-overview)
• Finalize win32 installer Call for installer artwork #192
• Packges for various distributions
  • Arch Linux (AUR)
  • Debian
  • Flatpak
  • Appimage (?)
• The project wiki is a bit suboptimal for documentation since wikis aren't really suitable for collaboration (no PRs). Github pages seems about right, since I want a zero-maintenance solution and don't really care about custom looks as long it doesn't look completely out of whack. Docs moved to readthedocs.

[atoav]

If you need any help, just post here.

[carrotIndustries]

I figured that github pages doesn't really cut it, currently moving the wiki over to https://horizon-eda.readthedocs.io/. Repo: https://github.com/carrotIndustries/horizon-docs

[atoav]

Ah, had good experience with readthedocs, good choice. I'll have a look at the repo

Edit: Are there any goals what should be part of the documentation for 1.0? There has been also a discussion on how to contribute to the pool. It might be a good idea to make the new documentation the single source of information for these matters too. I suggest we use the issues in the horizon-docs repo to collect topics the documentation still misses.

Maybe you could also post an issue there whenever you add some feature to horizon that might need documentation or when you change something that breaks existing documentation, so we can help with that.

[carrotIndustries]

All content from the wiki has been moved to readthedocs, so we can getting the docs ready for 1.0.

Are there any goals what should be part of the documentation for 1.0?

The basic stuff one needs to get up to speed and how to contribute to the pool. Also update outdated screenshots and feature overview. We also need to think of how to organize the table of contents.

[carrotIndustries]

If you need any help, just post here.

It'd be really great if you could come up with some basic structure of the docs. Once we know which topics to cover, writing the actual content shouldn't be too difficult.

[atoav]

Maybe I got a chance to figure something out tomorrow.

[frmdstryr]

It would be good to add Horizon to the comparison at https://en.m.wikipedia.org/wiki/Comparison_of_EDA_software once released

[carrotIndustries]

I've moved all repos over to https://github.com/horizon-eda

[fruchti]

@carrotIndustries: I can transfer the convention repository to you if you want to have it as a part of the new organisation. IMHO it makes sense to keep it as a separate repository for now and only integrate it into the documentation later, as it is still work in progress.

[carrotIndustries]

@carrotIndustries: I can transfer the convention repository to you if you want to have it as a part of the new organisation.

Yes, that's definitely the right thing to do.

IMHO it makes sense to keep it as a separate repository for now and only integrate it into the documentation later, as it is still work in progress.

I'd have merged it into the documentation right away and marked it as WIP. The ongoing development could be done in a separate branch.

Anyhow, we'll need to convert the pool convetion from markdown to rst sooner or later as that's what sphinx uses (Github renders rst as well). Since the document contains very little special markup, that should be just one invocation of pandoc.

[fruchti]

Anyhow, we'll need to convert the pool convetion from markdown to rst sooner or later as that's what sphinx uses (Github renders rst as well). Since the document contains very little special markup, that should be just one invocation of pandoc.

I let pandoc translate the file and on first impression it looks fine. I have no experience with RST so far, so please have a look.

I'd have merged it into the documentation right away and marked it as WIP. The ongoing development could be done in a separate branch.

That is definitely a good idea for the discoverability. OTOH, I'd like it to be its own repository so discussion about the convention can take place in the issues. Also, are the existing issues transferred if the convention is merged into the docs repository? Maybe the convention can be a git submodule?

[fruchti]

@carrotIndustries: I can transfer the convention repository to you if you want to have it as a part of the new organisation.

Yes, that's definitely the right thing to do.

I couldn't transfer it to the horizon-eda organisation directly, so I transferred it to you instead.

[carrotIndustries]

I let pandoc translate the file and on first impression it looks fine. I have no experience with RST so far, so please have a look.

LGTM

Also, are the existing issues transferred if the convention is merged into the docs repository? Maybe the convention can be a git submodule?

Let's keep it in a separate repo for now, I'll investigate the submodule approach.

[atoav]

AFAIK submodules have some nitty, gritty details about them and you need to know how to properly manage them (e.g. with git submodule sync or git submodule foreach 'git pull' and things like these). It is definitly not as straightforward as one might think, and there is room for mistakes (e.g. a normal git clone will not automatically clone the contents of the submodules and changes within submodules need to be commited twice (once in the submodule and then in the parent module).

The normal use case with the documentation will be that we jast wanna work on documentation, so lets keep it simple. Should the specification change, let's just copy it over manually, it shouldn't happen that frequenctly anyways.

[fruchti]

Let's keep it in a separate repo for now, I'll investigate the submodule approach.

Thanks!

Should the specification change, let's just copy it over manually, it shouldn't happen that frequenctly anyways.

IMHO, we shouldn't work around the version control here. This procedure obscures the history and opens the door for discrepancies.

AFAIK submodules have some nitty, gritty details about them […]

Yes, they aren't perfect. But the normal use case would be viewing the documentation via redthedocs and if that supports submodules I see no reason not to use them. PRs to the documentation won't work with the submodules at all; it's just for including the convention in the display.

It's worth investigating either way.

[atoav]

IMHO, we shouldn't work around the version control here. This procedure obscures the history and opens the door for discrepancies.

You've got a point there.

I just wanted to spell out a warning, because I worked with submodules quite a bit and I wouldn't see it as a quick fix that can be thrown onto just any repo without planning. But if it is well investigated and tested out, it just might be a good solution, so why not.

[fruchti]

I just wanted to spell out a warning, because I worked with submodules quite a bit and I wouldn't see it as a quick fix that can be thrown onto just any repo without planning.

Absolutely justified. I only used submodules a few times and so far they were well-disposed towards me, but I know they can be tricky.

@carrotIndustries: Should I now “manage” the convention repository as before or do you rather want exclusive write access now that its “official“? I'm fine with either way.

[carrotIndustries]

@carrotIndustries: Should I now “manage” the convention repository as before or do you rather want exclusive write access now that its “official“? I'm fine with either way.

Go on as before, you're doing a great job!

[fruchti]

@carrotIndustries: Should I now “manage” the convention repository as before or do you rather want exclusive write access now that its “official“? I'm fine with either way.

Go on as before, you're doing a great job!

Thanks! I'm glad if I can help a little.

[carrotIndustries]

I recently registered horizon-eda.org so we'll have a proper website for the release. The website content is in https://github.com/horizon-eda/horizon-eda.org.

As far as I'm concerned, there shouldn't be all that much content on https://horizon-eda.org apart from a link to the releases, docs and the repo.

[atoav]

I recently registered horizon-eda.org so we'll have a proper website for the release. The website content is in https://github.com/horizon-eda/horizon-eda.org.

Very cool

As far as I'm concerned, there shouldn't be all that much content on https://horizon-eda.org apart from a link to the releases, docs and the repo.

Agreed. I think we should treat it a little like a businesscard – so visitors should by visiting the page:

• understand what horizon-eda is in a nutshell
• see where to get it (Link to releases)
• see where to learn more about it (Link to documentation)
• see where to contribute to it it (Link to repo)

For the webpage: I like simple webpages that don't load in a ton of stuff and I know my CSS. So maybe a handmade HTML-one-pager without any frameworks or external CDNs will do? I traditionally like this approach because of Datensparsamkeit (data minimization), performance and robustness.

I could certainly help with making that look nice : )

[fruchti]

Great! For now, we should keep the site minimal and I think @atoav listed everything that should be on there.

I agree as well that a simple static site is the way to go, but I think we should look into static site generators. The advantages would be:

• Starting with a minimal ‘business card’ site with a standard design is straightforward and won't look too bad.
• We can use an off-the-shelf template at first and have the option to create or own later.
• Content and design are separate. This makes updating the content a lot easier, since you mostly don't have to worry about layout.
• Later, even the documentation could be rendered to the main site, probably without too much work.

GitHub Pages has native support for Jekyll, which should be more than capable enough and easy to get running. I also wouldn't feel bad for using an off-the-shelf theme since there are plenty and that would be the way of least effort.

So far, I only have experience with Hugo but I'd be happy to help, too.

[carrotIndustries]

Good to know that we're all on the same page on what should go on the horizon-eda.org landing page.

Since that landing page shouldn't have all that much content and is more about looking pretty and call to action, hand-written HTML and CSS is the way to go.

So maybe a handmade HTML-one-pager without any frameworks or external CDNs will do?

Exactly.

[atoav]

but I think we should look into static site generators.

You are right, I have no issues using Hugo or Jekyll and I am no stranger to templating languages either. I just thought that "for now" a very basic (but future proof) layout could do even without static site generator. Turning a simple HTML-page into a template after the fact isn't all that hard anyways, if the person writing the HTML isn't a complete and utter maniac.

[fruchti]

I just thought that "for now" a very basic (but future proof) layout could do even without static site generator. Turning a simple HTML-page into a template after the fact isn't all that hard anyways, if the person writing the HTML isn't a complete and utter maniac.

For a small single-page site there isn't really a difference. If you'd do the design yourself anyway, hand-written HTML and CSS would be the way to go for the first iteration.

[atoav]

If you'd do the design yourself anyway, hand-written HTML and CSS would be the way to go for the first iteration.

I usually do, I hate the clutter that comes from templates and frameworks. It is usually just not needed. But I am open for everything : )

[atoav]

@carrotIndustries Head ups for that .org domain... https://www.searchenginejournal.com/dot-org-registry-sold/336763/#close

[carrotIndustries]

I titled my talk for FOSDEM next year "Horizon EDA - Version 1.0", so I better have the release ready by then.

From my point of view, we're good to go in terms of features, so the only (?) thing left to do is to update the feature overview and a more pretty website.

[atoav]

I titled my talk for FOSDEM next year "Horizon EDA - Version 1.0", so I better have the release ready by then.

Hehe bolds strategy – maybe in January once my exam stress is over.

From my point of view, we're good to go in terms of features, so the only (?) thing left to do is to update the feature overview and a more pretty website.

I think we need to compile a list of things that are really needed for 1.0, but as things stand it already feels 1.0-ish. Are there things that could hurt if they change after 1.0?

[carrotIndustries]

Are there things that could hurt if they change after 1.0?

Can't think of anything particular off the top of my head.

I finally got around to do a flatpak package: flathub/flathub#1294 From a technical perspective, it's done but the copywriting and screenshots need some work to be ready for 1.0

[carrotIndustries]

@atoav at 36c3, projects can run ads in the breaks between the talks: https://36c3.info-beamer.org/ Perhaps you could quickly come up with something?

[atoav]

@carrotIndustries
I am just between flights, but managed to cobble this together:

[carrotIndustries]

thanks a lot, it's up

[atoav]

How is horizon-eda.org built right now? Basic html? Or a static site generator? It might be good to add Download Links (to get going quickly), maybe a image and a bit of style..

[carrotIndustries]

How is horizon-eda.org built right now? Basic html?

Yes, https://github.com/horizon-eda/horizon-eda.org gets published to horizon-eda.org by github pages. Whatever is in that repo will be on horizon-eda.org.

[fk0815]

Is there a changelog that can be used for creating distribution packages?

[carrotIndustries]

Is there a changelog that can be used for creating distribution packages?

Not yet since there haven't been actual releases before this one (apart from the 0.9 series used to test things)

Apart from that, seems like we're good to go for the release on Wednesday. Anyone got some last-minute ideas?

[endofexclusive]

I believe example projects is a good way for new users to familiarize themselves with Horizon. And demonstrates how the Horizon library concept can be used in practice.

One idea is to make example projects more visible by linking from the source repository/distribution README.md.

It would also be preferable if binary distributions included example projects. But that is up to the package maintainers I guess.

The x-band-tx is a nice example project and already linked from readthedocs. (I noted now that its cache has some out-of-date items in its cache.)

[carrotIndustries]

Closing since we now have https://github.com/horizon-eda/horizon/releases/tag/v1.0.0

One idea is to make example projects more visible by linking from the source repository/distribution README.md.

I don't expect regular users to read that one, so better create a section "Made with Horizon EDA" in the docs