[arch-dev-public] Junior developers and [staging]
Hello, My (somewhat overzealous) work for the python2 rebuild has raised the question of opening access for Junior developers to update the [staging] repository. What do you think about this? -- Rémy.
Am 04.09.2010 11:53, schrieb Rémy Oudompheng:
Hello,
My (somewhat overzealous) work for the python2 rebuild has raised the question of opening access for Junior developers to update the [staging] repository. What do you think about this?
My idea, good idea. Limiting access to productive repositories for the time being might be reasonable, but [staging] access is okay, almost[1] no harm can be done there. [1] staging packages are in pool/, so if you commit a package to staging with the same filename as an extra package, the extra package will disappear and have a wrong md5sum in the extra db.
On Sat, 04 Sep 2010 13:20:15 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
[1] staging packages are in pool/, so if you commit a package to staging with the same filename as an extra package, the extra package will disappear and have a wrong md5sum in the extra db.
No, dbscripts will disallow you to do this (at least if the old package was already in a pool) If it's not in a pool you'll have the same pacakge in different repos; but the extra one shouldn't be removed. But yes, maybe this is a use cas that I should take care of. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 05.09.2010 10:00, schrieb Pierre Schmitz:
On Sat, 04 Sep 2010 13:20:15 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
[1] staging packages are in pool/, so if you commit a package to staging with the same filename as an extra package, the extra package will disappear and have a wrong md5sum in the extra db.
No, dbscripts will disallow you to do this (at least if the old package was already in a pool) If it's not in a pool you'll have the same pacakge in different repos; but the extra one shouldn't be removed.
The presence of the file in the pool is not good enough. An evil developer could delete the file from the pool, then commit his own package. dbscripts should probably check whether a package with the same pkgname-pkgver-pkgrel triple is already in any other repository and then allow/deny adding it.
On Sun, 05 Sep 2010 10:53:59 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
The presence of the file in the pool is not good enough. An evil developer could delete the file from the pool, then commit his own package.
If you are evil you could still mess up with the repo by bypassing dbscripts. There is no point in assuming that there are evil developers.
dbscripts should probably check whether a package with the same pkgname-pkgver-pkgrel triple is already in any other repository and then allow/deny adding it.
That is a plan. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sun, 05 Sep 2010 12:36:08 +0200, Pierre Schmitz <pierre@archlinux.de> wrote:
On Sun, 05 Sep 2010 10:53:59 +0200, Thomas Bächler
dbscripts should probably check whether a package with the same pkgname-pkgver-pkgrel triple is already in any other repository and then allow/deny adding it.
That is a plan.
This is now implemented in commit 6f29ee2f02c2a8e2991599ce1d76a59b58a7ee67. Of course you could still submit a package into community that is also in core and vise versa because those repos are on separate servers. But this shouldn't be a big deal. -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (3)
-
Pierre Schmitz
-
Rémy Oudompheng
-
Thomas Bächler