merge or implement some more features first?

[Ansgar Burchardt <ansgar@debian.org>]

Hi,

I am wondering if I should prepare for merging my branch or if some
missing (less important) features should be implemented first.

I could upgrade dak on flotow and dinstall works mostly.  There were
some minor problems, but those were caused by projectb/filesystem not
being in sync for some files or ssh triggers not being available.

Here is a list of missing features taken from my TODO file in the
pu/multiarchive-2 branch:

* SEC-ONLY [0/2] [0%]
** TODO component mappings (for sec-master only?)
   -> queue.py: per_suite_file_checks

** TODO embargo/unembargo
* LESS IMPORTANT [4/14] [28%]
** TODO Package-List support in process-new
** DONE fix queue-report
** DONE fix show-new
** DONE new command to extract a package from a queue? like process-new does somewhere.
** TODO per-archive StayOfExecution
   We can remove files from queues sooner.
** TODO upload blocks
** TODO transitions
** TODO check timestamps
** DONE check syntax of Build-Depends-Arch
** TODO process-{new,policy}: rejections should indicate who rejected the package
   ie. set From to person rejecting the package
   Workaround: do so manually
** TODO utils.py (gpg_get_key_addresses): prefer @d.o addresses
** TODO non-free -> contrib moves.
   We probably need to use the component from the upload instead of having to
   hope there is only one override.

   But how do we know the right component for source packages? I don't want to
   duplicate the logic for guessing components (which is not so great anyway).

   -> https://lists.debian.org/debian-dak/2012/06/msg00017.html

   Can probably be delayed.

   Workaround: remove old override first.
** TODO override mismatch
** TODO dak admin suite: skip queues when adding new suite
   When adding a new suite and there is no archive=... option, it
   should just ignore all special-purpose archives (new, queues,
   build-queues) and only give an error if then still multiple
   archives are left.
** TODO enable bug closing per-archive or per-suite
   We don't want to close bugs for uploads to PPAs or backports.d.o

In my opinion we could live without them for a while provided we can
delay upgrading security-master for a while.  So my current plan would
be to prepare merging my changes (that is cleanup the commits a bit) and
only continue working on the missing features once those are merged.

Does this look like a reasonable way to proceed? Or do you think we
really cannot do without some of those features?

Ansgar