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.
So now, if I correctly understood, once the branch of the Theme is pushed into Master, it wil be deleted. And all what I have to do before to do anything else as contribution, is to refresh my Fork. Correct?
Now, suppose that everything is ok and they merge it.
Will it be available from 8.0.2 or from 9.0?
I mean: are these contributions available in minor or major releases?
Common etiquette is to give it a few days and if you don’t hear from the team you can mention one of these people (probably cpresser or Jon or Seth as they are more active) in the comments in your MR and they will get a notification.
Please do not ping individuals for review of library merge requests (unless someone has already started a review conversation with you). The librarians go through the backlog regularly, and singling out individual people is considered rude.
@tormyvancool please expect that library contributions (including templates) will take much longer to review than PCM contributions. While the team is working towards the review time being shorter, it may take weeks for anyone to get to yours, and this is currently normal.
)
