DanielSilverstone

Differences between revisions 1 and 3 (spanning 2 versions)
⇤ ← Revision 1 as of 2005-05-28 20:52:16 →
Size: 309
Editor: adsl-213-190-44-43
Comment: imported from the old wiki
← Revision 3 as of 2005-08-04 15:39:40 → ⇥
Size: 1188
Editor: henrik
Comment: manual page merge in preparation for UDU/Ubuntu wiki merger
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= DanielSilverstone =

I am a Canonical employee and have my own wiki on http://wiki.digital-scurf.org/ and a blog on http://blog.digital-scurf.org/		 I am a Canonical employee and a Launchpad team member. I have my own wiki on http://wiki.digital-scurf.org/ and a blog on http://blog.digital-scurf.org/
Line 6: Line 4:

I work on the build and publishing infrastructure of Launchpad.

Some notes which aren't coherent enough to be put on a BOF page yet:

 * Security pocket published internally on embargo aware server
 * chroot by DR/pocket tuple
 * builder gains security tag
 * access to embargoed archive by IP and user/pass

Should we change publishing workflow to:
{{{
Embargoed -> PendingPublication -> Published -> Superseded -> PendingRemoval -> Removed
                                    | ^
                                    v |
                                ComponentChange
}}}
Or instead should we create a new SPPH in PendingPublication with the new component, and move the other package straight to PendingRemoval tagging the SPPH record superseded by the one with the new component?

----
Related pages:
[[FullSearch()]]
----
CategoryHomepage

I am a Canonical employee and a Launchpad team member. I have my own wiki on http://wiki.digital-scurf.org/ and a blog on http://blog.digital-scurf.org/

I wrote the toshiba acpi patch for hoary to put the hotkeys through the acpi event layer and am working on a fix to fnfxd to support this behaviour model

I work on the build and publishing infrastructure of Launchpad.

Some notes which aren't coherent enough to be put on a BOF page yet:

  • Security pocket published internally on embargo aware server
  • chroot by DR/pocket tuple
  • builder gains security tag
  • access to embargoed archive by IP and user/pass

Should we change publishing workflow to: 

Embargoed -> PendingPublication -> Published -> Superseded -> PendingRemoval -> Removed
                                    |     ^
                                    v     |
                                ComponentChange

Or instead should we create a new SPPH in PendingPublication with the new component, and move the other package straight to PendingRemoval tagging the SPPH record superseded by the one with the new component?

Related pages: FullSearch()

CategoryHomepage

DanielSilverstone (last edited 2008-08-06 16:15:40 by localhost)