Summary: | council changed the waiting period in "eclass removal policy" | ||
---|---|---|---|
Product: | Documentation | Reporter: | Torsten Veller (RETIRED) <tove> |
Component: | Devmanual | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | council |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.gentoo.org/proj/en/council/meeting-logs/20100726-summary.txt | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
patch for eclass removal
updated patch |
Description
Torsten Veller (RETIRED)
2010-10-21 07:04:37 UTC
Point 6 actually mentions the 2 year deadline. However we miss the deadline issue Fixed http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commitdiff;h=784e3f9fe82 That's not what they wanted. - removing the 2 year policy - replaced by 30+ days minimum lastrite period for eclass removals (That is: eclasses are handled as ebuilds) I hope I did it correctly this time (In reply to comment #4) > I hope I did it correctly this time http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commitdiff;h=2396e4 No. - QA team doesn't need to be involved in the eclass removal process. - what's an entry in package.mask supposed to do? AND WTF does the council not care at all about their decisions? (In reply to comment #5) > (In reply to comment #4) > > I hope I did it correctly this time > > http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commitdiff;h=2396e4 > > No. > > - QA team doesn't need to be involved in the eclass removal process. Who will do it?Anyone? > - what's an entry in package.mask supposed to do? > Where does this 30+ lastrite period should be placed? gentoo-dev-announce maybe? But people will forget about that > > AND WTF does the council not care at all about their decisions? > Created attachment 254813 [details, diff]
patch for eclass removal
I guess it is time we stepped in.
Markos, I think the summary states it clearly, 30+ minimum lastrite (aka email @ -dev-announce). It doesn't have to be done by QA.
I've attached a patch.
note that this tackles the eclass removal case, not eclass deprecation.
another section should be added above this one, detailing how to
deprecate an eclass that is currently in use - either because it has a
replacement, or because its functionality is not useful anymore.
Created attachment 254817 [details, diff]
updated patch
hmf, i somehow managed to delete the first < in the file, patch updated.
(In reply to comment #8) > Created an attachment (id=254817) [details] > updated patch > > hmf, i somehow managed to delete the first < in the file, patch updated. > Done. Thank you Should I leave this bug open because as the latest patch says we miss a section for eclass deprecation Torsten, I think this bug is fixed long time ago and should be closed. What do you think? Torsten ping? I will close this bug in 48 hours unless there are any objections |