Author identification

[jbonnet]

Could we use an email address for identifying a package author? Or, when we consider users, we could use the user name...? If we use GitHub users, we could reuse those...

What do you think?

[mbredel]

By package author you mean the package maintainer (package_maintainer)?

In Debian packages, the maintainer is given in a form similar to "Name Surname email@address.com" which, however, might be hard to check. In the schema, we would need a RegEx that checks for that. Checking for email addresses is easy though.

However, I am not so sure, if we want to limit the maintainer string anyway, as a maintainer might be a company.

[jbonnet]

Right...
But the Gatekeeper has to connect this package_maintainer to licensing (I guess that not all developers will be allowed to publish packages, and stuff like that), so things like you mention ("Name Surname email@address.com") will be harder to map...

[mbredel]

Ah - now it gets clearer. You want to (re-) use the package_maintainer to check permissions?

I am in favor of decoupling that completely form the package descriptor. Uploading is done via the Gatekeeper. Thus, you have to login (or provide credentials - in case of using an API and no GUI) to the Gatekeeper in order to upload packages.

Same is true for licensing - which is not completely solved by the current package descriptor yet. But I have to think more about it - and postponed that to phase 2 :-)

[jbonnet]

Ok, no problem in decoupling...
But there's something I don't agree: uploading is not done through a GUI, it should be done through the API. Therefore the need to identify the user. Credentials yes, should be gathered when registering, and then sent in the upload request. So, a request should be something like (correct me):

{
"credentials":"XXXX",
"package":<.son file here>
}

What do you think?

Yes, let's postpone licensing until phase 2

[mbredel]

Totally agree :-) Although I think, uploading can be done using a GUI at least optionally (I also think, the API way might be the dominant one) but your proposal does not prevent that.