Now that you have a valid package and metadata you can open a Merge Request on the metadata repository. Just keep following the steps in the readme of that repo. If you are not very familiar with git and some steps are unclear then you can just use the gitlab UI to make the merge request and we will help you with the rest.
Important thing is that you put your metadata.json and icon.png files under packages/com.github.tormyvancool.NuovaElettronica in that repo.
I have to understand the documentation in the process about the push.
What i do normally (when I collaborated for few things in other projects) is to create a branch, make the modification to my branch then commit the mods.
It’s not clear (in this moment) if I have to do so. I wouldn’t want to make somebody mad with me
In simple terms, yes, you update your metadata to have new version (you can keep the old one alongside the new one or remove it, up to you), update your branch and open new merge request with the changes.
But there are a few things hiding behind “update your branch” here and depending on how familiar you are with git this can get a bit tricky. To be more specific you have to
Get your checkout’s main branch up to date with upstream
Create new branch from current tip of main
Make your changes there, commit, push to fork
Create merge request from fork’s branch to upstream repo
If you don’t know how to do some of the above I can provide specific git commands. If you don’t want to use git command line you can do all of the above from gitlab ui too.
No need to redo the merge request, just make changes suggested by reviewer, create new commit with the updated metadata and push that to gitlab. Merge request will automatically pick up the new changes.
On your fork simply edit metadata.json of your package and commit the changes. They will be reflected in the merge request automatically.
I see that in this instance you have changes on main (default) branch so you will not have to change branches before editing. But normally you should create a separate branch and make your changes there. It will make it easier to keep main up to date. But this is only relevant for future updates or other packages you add.
Ok I updated the metadata.json and committed it right now.
About the “main branch”.
Well I tell you what I also normally do, but as I said, i never worked on big projects, just small ones where we had to work 2 or 3 max.
The vast majority of the time I’m alone … so I work on local directories then I just commit and push. hence on several things I have not familiarity with.
so what I did here in GItLab is:
I created a Fork
I created into that fork my folder into the /packages, after have seen what the other ones have done and how (my reference was the Elektuur since it inspired me for my Library. Personal note: I was reader of both: Nuova Elettronica and Elektuur/Elektor )
With the use of the web interface, I uploaded the 2 files: metadata.json and icon.png
Then committed with a title
Then opened a Merge Request
But from what I understand form your talking, there should be a kind of intermediate step I’m not familiar with, but I want to learn it.
At that point the web interface asks you the target branch. It is common practice to create a separate branch for each merge request you make. Since you didn’t specify new branch it used the default “main” for you.
Everything else is correct.
For next update, since you already have a fork, instead of creating new fork you should update your main branch of the fork. From the web ui you can simply click “Update fork” button on the main page of your fork. It will only show up if your fork is behind upstream.
After the update proceed with edit->commit to new branch->create merge request, as usual.
Once you already have a merge request and want to make changes to it (because reviewer requested them or you need to fix something) then do following:
In your fork home page switch from “main” branch to the branch you created for the merge request.
Make the edits, commit to the same branch
That’s it, merge request will be updated.
The importance of having each merge request to be on separate branch only comes into play with large teams making simultaneous changes to the repo. If you don’t do that then earlier or later you will run into a situation where you can’t easily update your fork because of merge conflicts and gitlab web UI is not good enough yet to provide means to deal with them. You will either have to get busy with git cli, which can be daunting for someone unfamiliar with how git works, or abandon your fork and create a new one.
From that moment on, that template is available from my GitHub.
My question now is: is it possible to have it merged in KiCAD itself so it’s automatically available for anyone that needs for this template?
It’s very used in Pro-Audio systems.
At the moment project templates are not distributed with plugin manager but you should be able to contribute your template here KiCad / KiCad Libraries / KiCad Templates · GitLab and it will be available in next kicad release.