-----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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]'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 > [email protected] > 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----- _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
