[newdak/master] More features.
Add some more features. :)
Signed-off-by: Joerg Jaspert <joerg@debian.org>
---
feature.txt | 46 +++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/feature.txt b/feature.txt
index 83fd326..20d14c7 100644
--- a/feature.txt
+++ b/feature.txt
@@ -27,23 +27,27 @@ Global
be enough to drop one file into a directory and have it. Same goes for
supported compression algorithms. Or whatever else.
+
* OO / Coding Style. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
Use the Object Oriented foo Python offers as far as possible.
Also, consistent coding style. Spaces for indents, readable *and*
self-explaining variable names, ...
(Mhy: extend)
+
* Client/Server style. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
There should be one "dakd" running, thats doing everything. FTPMaster
(and cron), everything uses client-scripts talking to dakd, asking it
to do whatever one wants to do.
This needs a proper protocol description.
+
+ Multi-Archive aware. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
As we are going to have a server speak via TCP (or unix sockets, both
possible), new DAK should be multi-archive aware, possibly
(setup-depending) communicating in both ways.
+
- Integration of snapshot.debian.org. [mhy] Sat Aug 30 16:13:40 BST 2008
As it's proposed to have snapshot.debian.org start to exist, it would
be nice if dakd could push and track the relevant changes over to the
@@ -60,6 +64,7 @@ DAK server AKA dakd
We have to have unix sockets, but we want to be network open, so some
high port...
+
* Protocol. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
We need a protocol where clients can talk to dakd. We might either go
and develop an own one or use some xmlrpc or soap or whatever
@@ -69,6 +74,14 @@ DAK server AKA dakd
"rm blapkg"
"list package foo suite bar"
+ For multi-archive support this additionally needs away to talk to the
+ next archive. Like telling it there are new versions of a package,
+ new overrides, removed stuff, etc.
+
+ Even better if it keeps track itself where it is and can replay when
+ the next archive comes back. (Think of outages/network trouble).
+
+
* Proper SSL Implementation. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
The server has to have a proper ssl implementation. We want to be
able to go multi-archive and/or allow remote queries of it, this
@@ -85,25 +98,34 @@ DAK server AKA dakd
client cert means anonymous mode and only readonly querying of
dak. Every archive and every ftpteam member needs own client cert.
+
+ Optional non-SSL connections. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
They are strictly limited to the most basic read
operations. Basically dak ls only. Maybe equivalent of "dak rm -nR" too.
+
* Proper rights management. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
The whole rights management has to be within dakd. The whole
database, all directories, everything, should only be modified by
dakd. No more unix access rights on files or different groups within
postgres to limit actions taken.
+ This, ideally, would also enable us to *eg.* let the release team directly
+ run the dak command to set testing. Or even modify just small parts
+ (like one package). Instead of current "prepare a file, do a ssh
+ push".
+
* Rights management for embargoed issues. [mhy] Sat Aug 30 16:26:29 BST 2008
dakd needs to be able to keep issues embargoed (for security updates)
on both the filesystem and database levels. This may mean that most of
- the time, views are necessary to only show those without ftpmaster/security-team
- membership non-embargoed issues.
+ the time, views are necessary to only show those with ftpmaster/security-team
+ membership embargoed issues.
+
+ Everything in the archive is managed by dakd. [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
This includes every byhand file. Nothing that ends up in the public
- viewable mirror space should *ever* be copied in by hand from an FTPMaster.
+ viewable mirror space should *ever* be copied in by hand from an
+ FTPMaster or a script. Yes, that includes override files, indices, etc.
General Archive Issues
@@ -123,6 +145,7 @@ General Archive Issues
files/e9/45/e7/e945e7d156d770ec26d742499cb119e52fe3de963f0bc3bdc42132d29c2fcbe8
and then hardlinked over to ftp/README.
+
* "NIv2". [Ganneff] Sat, 30 Aug 2008 15:55:12 +0200
No longer have a queue/accepted where everything gets first, and then
moved over on dinstall time.
@@ -130,3 +153,20 @@ General Archive Issues
right in the database(s). "Dinstall" then merely updates packages
files and triggers the main w-b run.
+
+ * Throw away apt-ftparchive. [Ganneff] Thu, 04 Sep 2008 21:13:53 +0200
+ Generate all the files from knowledge within "projectb".
+
+
+ - An own "ftpd". [Ganneff] Thu, 04 Sep 2008 21:13:53 +0200
+ Getting rid of using whatever ftpd is out there and in the same time
+ getting rid of debianqueued by having an own python-"ftpd", which is
+ aware of Debian packages and can as such already do checks at upload
+ time - some even before the transfer starts.
+
+
+ * Proper "multiple type" support. [Ganneff] Thu, 04 Sep 2008 21:13:53 +0200
+ Ie - easy support for udeb, tdeb and possible other "different" types
+ of Debian packages. We shouldn't need a code exception per extra type
+ of binary. Maybe it should be handled similar to Formats - using a
+ modular structure (if possible at all).
--
1.5.6.3
Reply to: