-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Loeser wrote: > Here is the newest revision of my proposal. Not much has changed, but I > added and changed some small things. Constructive feedback is > appreciated. I'd like to get this voted on by the council at the next > meeting. > > * The QA team's purpose is to provide cross-team assistance in keeping > the tree in a good state. This is done primarily by finding and pointing > out issues to maintainers and, where necessary, taking direct action.
describe what makes it necessary and what actions will be taken or if the paragraphs below are meant to do that, you can save that line in that paragraph > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem. The QA > team does not want to override the maintainer's wishes by default, but only > wish to do so when the team finds it is in the best interest of users > and fellow developers to have the issue addressed as soon as possible. define emergency, define as soon as possible (some bugs might be quite tricky to track and might be put on back burner and what little time is available used on things not taking up equal times), how do you know ia dev is not cooperating or if i he/she is just prioritizing > * The QA team may also offer to fix obvious typos and similar minor > issues, and silence from the package maintainers can be taken as agreement > in such situations. Coding style issues fall under this category, and > while they are not severe, they can make automated checks of the tree more > difficult. thanks for the offer, sounds good > * There will be cases when our tools are incapable of handling a certain > situation and policy must be broken in order to get something working > completely. This will hopefully not occur very often but each time it > does occur, the QA team and the maintainer will come to some agreement > on an interim solution and it is expected that a bug will be opened with > the appropriate team to work towards a correct solution. sounds reasonable > * In the case of disagreement on policy among QA members, the majority > of established QA members must agree with the action. you shouldn't disagree about this policy, or you might as well not have this document, write disagree on the solution maybe? > * In the event that a developer still insists that a package does not > break QA standards, an appeal can be made at the next council meeting. The > package should be dealt with per QA's request until such a time that a > decision is made by the council. The default could be that the ebuild not be touched unless it is a issue that breaks the tree or is security related where time is of the essence. word it in that direction? > * Just because a particular QA violation has yet to cause an issue does > not change the fact that it is still a QA violation. Then you must be talking about coding style here? remove the point and add it above to coding style, as an example why you will deal with the coding style maybe? no other violation should be left to such vagueness > * If a particular developer persistently causes breakage, the QA team > may request that devrel re-evaluates that developer's commit rights. > Evidence of past breakages will be presented with this request to > devrel. define persistently, how do you presistently cause breakage? maybe this is one of those non native english speaker moments, but doesn't that mean like every commit is botched? > * The QA team will maintain a list of current "QA Standards" with > explanations as to why they are problems, and how to fix the problem. > The list is not meant by any means to be a comprehensive document, but > rather a dynamic document that will be updated as new problems are > discovered. The QA team will also do their best to ensure all developer > tools are in line with the current QA standards. as said in the other two posts, maybe write it is a comprehensive list, just that it is not finite? that might clear this point up. > * In order to join the QA team, you must be a developer for at least 4 > months and must ask the current lead for approval. that shouldn't be too hard > * The QA team will work with Recruiters to keep related documentation > and quizzes up to date, so that up and coming developers will have access > to all of the necessary information to avoid past problems. sounds good > * QA will take an active role in cleaning up unmaintained and broken > packages from the tree. It is also encouraged of members of the QA team to > assist in mentoring new developers that wish to take over unmaintained > packages/herds. > > i am not sure how to read this one, it could mean broken packages that are unmaintained, but how it is written it could also mean unmaintained || broken, not only unmaintained && broken, i really wish you would at least consider not killing off unmaintained and not broken packages, and word it in some way that this comes out clear in that paragraph finally had some time to read this in more detail hope the feedback helps Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETFkI/aM9DdBw91cRAgQWAKDBuxieQZTwcGw+VC2IGGNaGUnO8gCcDPTJ H296TQyH7S1dA3NfbscYj5Q= =ypTj -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
