Folks, During the (quite successful) FITS cleanup this weekend, I did some poking around in the permission structure of FITS.
As part of that, afranke, tforsman, pscott and I did our best to grok the Package Request workflow, as it has proved somewhat vexing to the uninitiated (i.e. not obviously self-documenting). Subsequently, afranke proposed that we disambiguate its nomenclature which he and I fleshed out. This new nomeclature and a small tweak to avoid the annoying 'Status: Closed, Resolution: unresolved' issues has now been put into effect via a newer workflow scheme, which is backwards compatible with the one used previously. What this means is that, should some of you object to the tweaks implemented, it is straightforward to move back to the previous workflow scheme via the administration interface. If you want to check out the new scheme, I have created two test issues for people to fiddle with: #FL-2326 and #FL-2327 - https://issues.foresightlinux.org/browse/FL-2326 To recap, it looks as if the idea behind the original workflow scheme was something like the following: 1) Someone requests a package via the Package Request.workflow 2) A packager (member/developer or not) decides to take on the Package Request and chooses the 'Accepts Package Request' workflow transition, which is visibile if the packager is a member of the contest200804 permission group. The packager needs to have the 'Assignable User' permission to assign the issue to himself. 3) When the packager is satisfied with the package -- i.e. it builds in rMake and runs when installed from his personal label -- he hands the package off to the FL QA team by choosing the 'Package Ready for QA' workflow transision. He only sees this workflow transition if he has the 'Assignable User' permission. 4) The FL QA team (member of the 'qa-team' permission group) checks that the package does indeed satisfy the requirements to be included in the official FL repository and then picks the appropriate workflow transition: * QA: Package Validated - ready for inclusion * Reject Package Request (and supply a good reason why) * Request more information from developer * Request more information from packager After step 4 is completed, the package is ready for a developer to include it. There is no reason why the developer could not also be part of the QA team -- given the current state of affairs, this would be the most obvious way to do it IMHO. I seem to recall that pcutler and kenvandine maintained a spreedsheet on Google Docs, which they updated as part of the packaging contest when 4) was completed. I'm currently tracking this on #IT-29 but I am considering converting it into an umbrella issue and create seperate subtasks. /ermo _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
