Submodule transition

[ManuelSchneid3r]

I changed the structure of the repo. Plugins are now submodules. I am still thinking about the most reasonable way to integrate outside collaborations.

1. I need write access to script any api changes.
2. We need reviewing.

We have two options.

1. Transfer the repository into the Albertlauncher org and you fork it
2. You could also keep the repo an give me write access.

There are two points were we could have the reviewing.

1. The commit of the submodule hash.
2. The commit of the changes into the upstream repo. And everything that makes it into the upstream repo will be accepted as shippable. Meaning no reviewing in step 1.

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.

[LorenzoMorelli]

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 :)

[HarshNarayanJha]

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).

[ManuelSchneid3r]

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.

[LorenzoMorelli]

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

[ManuelSchneid3r]

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.

[HarshNarayanJha]

Exactly @LorenzoMorelli, thanks! Then I will transfer the repo over to this org!

[HarshNarayanJha]

@ManuelSchneid3r I don't have create repo perm on alberlauncher org, so I will transfer over to you.

[ManuelSchneid3r]

@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.