Re: QA releases RFC

Hello Arnaud, From Sunday, September 11, 2005, 7:46:24 PM, you wrote: AL> You will find a draft ([1] and [2]) for an upcoming RFC about QA AL> releases process. AL> Any feedback is appreciated. Great scheme, esp. picture, but some clearifications required: 1. Where issues are reported? Maintainers already receive notifications on new bugs in their packages. But note about QA pulled release and link with details is welcomed. 2. If maintainer opted-out - do not contact him, since he already received a note and aware of issue. Better provide a way to him to respond his status/willingness/time to resolve in a note above. 3. "Put a notice..." - in a special QA DIV. 4. Notice on a page only if a bug is definitely serious and it is impossible to pull older release, because of other bugs. 5. Not just "Fix and roll", but send maintainer patch and testcase for review. Provide a ways to avoid similar bugs in the future. 7. Mention CVS modifications in QA branch. BTW, CVS modifications on software packages can be filtered and remailed to all their maintainers. * blocks can be numbered =) > Those fields would be QA-core restricted access for privacy concerns. Not necessary. > * status field, maintainers can indicate if they are on vacation, > unvailable, unable/uninterested to work on their packages anymore. Useless, because you can simply forgot to check/uncheck these and if people would like to abandon their packages - they can easily say so or let bug list grow. Better provide a way to vote or rate items (like on PHP.NET) >* IM field, maintainers can give their IM contact information for fast >turnaround. If it will be field with "QA only" checkbox why not. You better define how to opt-out package - should the package be out-opted or maintainer himself? If opt-out option on a package is changed - a notice should be sent to all it's maintainers. There this issues and reports will be stored? t --