[Secure-testing-team] A first shot at flow modeling

[Micah Anderson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

Great diagram, thanks for getting started on this, some feedback, which
I hope is useful:

Because I dont have the slightest idea what the UML conventions are for
things, I find this diagram confusing in terms of flow on first look. It
may just be concepts of UML that I am ignorant of but when I first
looked at it I didn't know where to begin. After some looking at it for
a while I think that it became obvious that you start at the black dot
on the left, although I intuitively thought things would start at the
top left or top center so I had to read a bunch of boxes out of order
before I found where the order should proceed from.

Once I start at the black dot, the first thing that happens is "receive
new issue"... I think that there should be more information about how
new issues are received as there are many sources that could dump into
here (bug is tagged +security in the BTS; message is sent to
team at security.debian.org... how else are issues brought to the attention
of the team?). This is where issues are received from, but there is also
the consideration of where the issues are received to. Are they always
ending up in the team at security's email box?

Ok, now that an issue has been received, the next thing that happens is
a fix is prepared. What is the process for "claiming" an issue so that
only one person is preparing a fix? Are there workflow issues here?

At the "prepare a fix" center of the diagram, we first go up to the
diamond "issue is unfixed" on every issue. This is probably some UML
decision point or something. So if an issue is public then we go to
"cooperate on fix" box. This box probably should be "fleshed out" more
as my guess is that this is where a lot of time is spent, this is where
communication can break down, this is where there needs to be some sort
of detailed trackable workflow. Somewhere between this box and the
return to "prepare fix" is the review process that has been discussed on
IRC that takes most of the time. Additionally there are some other steps
in here, such as determining if a CVE has been assigned, requesting or
assigning a CVE for an issue.

The "migrate to queue/accepted" after upload probably has one or two
workflow steps (how is this done? what choices are made to accept? what
if it is rejected?), DSA preparation also probably involves more
detailed workflow, as does the publish to archive steps (how it is done,
etc.)

Overall, its a great general overview of how things are done!

micah

martin f krafft wrote:
> Wow, UML is really a bitch on Linux. Anyway, with the help of
> Poseidon (non-free, yeah, I know...), I managed to draft how
> I currently see the stable/oldstable security process. Comments
> welcome.
> 
>   http://madduck.net/~madduck/scratch/current_stable-oldstable.png
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Secure-testing-team mailing list
> Secure-testing-team at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/iGJ9n4qXRzy1ioRAou+AKCTaiFv4CCic0/NnN8TSdDgBx8DRwCeJD/T
cvH5m2HNRUf6KM1mgKotTFo=
=F7yi
-----END PGP SIGNATURE-----