Import repository

[tali]

How to start? Before we start using this organisation, I'd like to discuss the first steps.

Base repository?

We have some good candidates to import:

• from @dbambus: master branch or master_V2.6.0
• from @tali: master branch

Branch(es)

I propose to create a single main branch for development. Stable branches can be created later if necessary. Changes would only be allowed by tested (Github Action "it compiles") and reviewed pull requests.

Keep old releases?

I suggest removing the bin/ directory which was used to store binary releases. Instead use Github releases to store them. This helps to keep the development repository clean and small.

I propose to not just remove them in a new commit but to purge them from the history and only include source files. This means the history of the Git repository has to be rewritten and everybody who already has commits based on an old repository has to rebase them. Luckily, this isn't too difficult using Git.

We could also import old binary releases (using Github Releases). Is this worthwhile or should we just make a fresh start? How do we want to version our releases?

Move build instructions and files to own repository?

We could create an own repository for the hardware part of the word clock. These are mostly independent from the software source code.

[dbambus]

Hey @tali,

those are good proposes and necessary ones.

To start with I would push the 2.5.1 Release to the Git Releases, so there would be a base for all interested people to get a fully working Release for their projects. I'm still not sure if we should start with the my whole master branch or just start with the 2.6.0 (Beta) either of our branches.

A single main branch and the removal of the /bin folder sounds good to me :-).

Personally I would feel better with keeping the hardware Instructions in the Repo. For everyone who is interested in could just take a look at how the design is build up, especially the LED Layout varies throughout all, what I ve seen so far on Github.

But how do we keep track of the changes ?

Is it still reasonable to keep the changeling in the readme ?

[Flo455]

Hello,

I've been taking a break for the last few years and now I have to finish my circuit board. Therefore I don't know the current software status very well.

But I think dbambus suggestion that we use 2.5.1 as the base release (I think that was the last working one?) is quite good. And then take the latest version from you. If I have seen correctly, this is the master_V2.6.0 from dambus? Or is V2.6.0 stable anyway?

If I have understood correctly, the way via pull requests is that we have our own forgs and from which the pull request is then started with the condition that it must be stable and testet?

I would be for it the hardware being outsourced. Then, with a local repos on the PC, you would only have the required code.

[tali]

Regarding the changelog: I would remove it from the README, it doesn't belong there. When we still want it in-tree, then we should move it to a separate file. Release notes can also be attached to the releases directly, so a separate file is not really necessary. However, it's probably convenient to be able to view the changelog directly within a checkout.

[tali]

If I have understood correctly, the way via pull requests is that we have our own forgs and from which the pull request is then started with the condition that it must be stable and testet?

Yes, that is the idea. I'd like the repository here to always contain a stable and working version. Then everyone working on additional features can do so in their own repository and stabilise this feature there. You can even rebase in your own repository as all others base their work on the central version. This way, we can already discuss new features while they are in development but still wait for them to be stable and working before they land here.

[dbambus]

Hey,

so sounds good for me :-). To get rid of the ChangeLog in the Readme.md.

After thinking I trough I m fine with the solution to split the hardware and the software into two repos.

So how do we setup V2.5.1 as a Final release and presumably my master_V2.6.0 as a development main branch. I guess it is the latest version of the software which is both stable and runs both git actions, correct me if I m wrong here?

I would also add @ATho95 to this topic, as he got some cool enhancements for the software in his fork.

[tali]

I'm currently testing a stripped down version of the repository: https://github.com/ESPWortuhr/Wortuhr/tree/test-do-not-use. For this test I removed bin/, docs/, libs/, pics/, svg/, as well as all *.bin and *.zip files. This results in a repository size of about 1MB instead of 70MB. When keeping pics/ and svg/ it uses 25MB. Where do we want to draw the line? And: is it worth the hassle to remove old files from the history?

[tali]

As seen above, we might have to rewrite commit message to reference the correct issues/PRs in other repositories. So maybe we have to rewrite the history anyway. Or would Github ignore these references when importing commits from another repository without any changes?

[dbambus]

Hey,

i m not sure how Git is handling the Refs in Commit messages while forking. I would just continue as planed.

I m fine with just releasing the Code in the new Repo. All the Docs and Pics could either be moved to a separate and necessary wiki or to a dedicated Hardware Repo.

Cheers David

[tali]

One possibility I did not yet consider is to transfer an existing repo. @dbambus already has quite a number of issues and PRs and we could preserve them by transferring that repository to the organisation. The more I think about my proposal of pruning old history, the more I think it is not worth the hassle. Yes, the history contains a lot of dead files which just occupy space, but they only have to be downloaded once. And when we try to not bloat it any more by not committing any more binary files, then I think that's ok. What do you think? How important is the history of issues, PRs, commits? Did you experiment with rebasing commits to the test branch? Was it flawless?

[tali]

@dbambus what do you think? New start with the trimmed-down repo or transferring your existing one? With the new start, everyone has to create new forks and rebase their work. With the transferred repo, forks should be updated automatically to refer to the new one; you would only have to create a new fork for your own development.

[dbambus]

hey,

I would love to transfer my Repo to ESPWortuhr. But at first I've to solve some Issues in my Development Branch.

[tali]

The repository is transferred. New developments should be submitted as PR against Wortuhr:main.