Repository navigation
Submodule transition #226
Description
Activity
hi, just updated the repo, renamed and transferred to you (on albertlauncher org I didnt have the access rights to create public repo). Let me know if everything went well, I did miss something or I should try again transferring to albertlauncher org instread. It is the first time I transfer a repo in github :)
Hi! I am not against the repo transfer. It will help keep all shipped plugins in one place. But instead of me keeping a fork, can I have collaborator access to my repo(s)? Actually, I would like to somehow keep my ownership on the plugins I make. I am not familiar with how repo transfers work on GitHub 😅, (and also not with open source licenses).
Ownership is difficult to define in open source licensed code. What exactly do you mean?
The one thing I want to make sure is that repos in the source tree are not able to vanish suddenly and that no code shall pass without review.
Maybe @HarshNarayanJha means just he would like to be be seen as maintainer of his plugin and contributor of this organisation in order to keep the plugin up to date and continue contributing. I specify, I'm not familiar with this too, so I actually don't know if this is exactly what you (@ManuelSchneid3r ) are trying to do
Oh hell please yes. Long term plan is to have packages with pyproject.tomls and dedicated maintainers. I am exhausted to say the least. I am not keen on maintaining code that I did not even write.
Exactly @LorenzoMorelli, thanks! Then I will transfer the repo over to this org!
@ManuelSchneid3r I don't have create repo perm on alberlauncher org, so I will transfer over to you.
@tomsquest this discussion may be interesting for you.
Yesterday I realized that if we allow direct repository access to outside contributors pushes could easily be abused to run unreviewed potentially malicious code on Albert developers machines. (Alice pushes malicious code on upstream repo. Dev updates all submodules including harmful code and runs Albert) For this reason I'd like to have the reviewing before the code gets into upstream repos. As such we have to use forks and pull requests.
I see that you may not like this flow @HarshNarayanJha but it is necessary for security reasons. Not to be offensive but you are all random internet strangers and I (we) can't just trust each other. The only security mechanism we have is peer reviewing. I hope you can understand this decision @HarshNarayanJha but remember that you benefit as well. You are still the owner of the code according to the copyright laws. We just need to have a single protected upstream where we merge only peer reviewed code.
If you don't like this structure let me know if I should transfer the repo back to you. Otherwise please work on a fork and send pull requests for peer reviewed upstream changes.
Ofc I am open to other code flow designs I am currently not aware of.
I completely understand the security perspective! At first, I thought it would be ok for core plugin devs to push changes, but now I see it could be harmful (remember the xz-utils attack?). Thanks!
I have no problem at all with this flow (I was just a little bit confused about how repo transfers worked).
Sure thing, I will work on a fork and send PRs.
On a secondary note @ManuelSchneid3r, I would ask you to look into how Zed manages extensions on their official extension registry. https://github.com/zed-industries/extensions/
As far as my understanding goes, it seems like they maintain commit pinned submodules in their
extensionsrepo and devs update the submodules via PRs.
But this would go completely opposite of what you have done so far (separating plugins into repos) 😅.I am good with me having a fork and doing PRs. I hope others are too!
Actually it is more or less the same but upstream is an outside repo.
The reason I think it is better to have upstream in a dedicated repo is that
- Checked out source tree does not contain unreviewed code if you perform a pull in one of the submodules (which I usually do if I start to work on a plugin) and
- Github reviews using the web UI is quite convenient if you work on the actual code instead of a commit hash. (but maybe I am not aware of a github feature that supports commenting/reviewing the commit that the submodule hash commit actually points to)
- Generelly it's easier to grasp imho if we can simply assume that the org repo is safe and what is actually distributed
- Git status on an updated (pulled main branches) is clean and does not show up dirty dirs due to ongoing development. (mental load reduced for releases)
Reacted by Harsh Narayan JhaGoing to archive this repo.
For any other plugins please see https://albertlauncher.github.io/gettingstarted/contributing/#code.
I changed the structure of the repo. Plugins are now submodules. I am still thinking about the most reasonable way to integrate outside collaborations.
We have two options.
There are two points were we could have the reviewing.
I'd prefer the latter because Github offers a nice UI for reviews and code comments and we have all officially shipped plugins in one place.
If you don't have any objections please transfer the repo to albertlauncher organization.
Let me know what you think.