[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

britney



Hi,

Joerg asked on IRC what britney needs exactly from ftp-* side. We both
agreed that we should take the chance to clean up borders between ftp-*
and release team.

So, basically, what britney does:

It generates Packages-files, it runs some magic (mostly in python) on
it, it produces a list in heidi/control-suite-format, and runs
dak control-suite -s testing on that list.

The only thing currently requiring ftp-master/dak-permissions is the
actual setting of the testing suite. Anything else can be run by anybody
who has access to the machine ftp-master.d.o. (It also helps being able
to access read-only some cache files for apt-ftparchive, but as my user
account can do the same, that's probably a non-issue.)

(Also some files are copied around to the web pages etc, but that are
details and can be replaced with the release.d.o-webpages now that we
have that page on the same host.)



So, what I would propose would be to either allow the release user to
run dak control-suite -s testing, and/or to allow some people (including
the release user) to change bin_associations and src_associations as far
as it concerns testing. With that, running britney could be migrated to
the release user.

Some smaller questions include:
- whether we want some logfile of all changes to testing, and trigger
  that from within dak suite-control (or a clone thereof), together with
  reasonings
- in case some people get limited database access, if the same should
  happen for t-p-u as well (I mostly don't mind, but might be helpful
  for auto-cleanup stuff happening there)



Another interface that we don't need as often includes some way for
ftp-* to signal to not run and/or commit - which could be a special file
at the usual ftp*-places (and perhaps automatically take "running
dinstall" as such), and/or scripts ... - actually, I don't mind what we
do (or if we do that as all) as long as the ftp*-people are happy with
it. On our side, it's just a question of writing that into code once.




Within the release team, the above changes means that we need to agree
on some sort of "quality guide" as to how to push migration to britney
2, how to make changes to britney (or: who is allowed to), ... - but
that's something for another thread.



Probably there are more details yet, but that's the larger direction I
would like to take for the ftp-*/release-interface.



Cheers,
Andi


Reply to: