On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel <m...@gentoo.org> wrote: > I'm a couple weeks late with this, but here goes: > from my failed attempts at reviving GLEP33 grow a discussion with > ferringb on IRC about how to get what I wanted anyway :)
I've placed my immediate feedback in CVS: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?r1=1.1&r2=1.2 I will split the remaining commentary up into two sections: General Idea Feedback (call these non-editor related) and editorial feedback (generally segments you should add to the GLEP for editorial reasons.) > > We agreed that having eclasses specific to a package located someplace > near the actual ebuilds was beneficial and should be supported by PMs > somehow. Someplace and somehow are specified along some other details in > the attached proposed GLEP. Feedback: I believe the biggest reason to have per-package eclasses is the following: 1) It limits how users can use an eclass. a) This makes mis-using eclasses harder to do; Interfaces that are hard to use incorrectly are good. b) It means changing an eclass affects fewer packages. It is currently difficult to control eclass consumers in the current model. (anyone can use any eclass.) c) It means eclass changes are easier to test. I think the GLEP attempts to over-blow the actual impact that its proposed changes may have. For instance I do not think per-package eclasses will drastically reduce the number of eclasses in the global eclass directory. It will not make overlays easier to use (possibly harder..actually.) Plus the number of eclasses that will move to per-package is likely few (the GLEP itself only notes three.) > > I'm posting this for review by the wider community, at the same time > asking the GLEP editors (antarus? pva?) for guidance on the formalities. > I gather the GLEP should get a number and be uploaded in CVS somewhere, > as well as appear on the GLEP project page. Editorial: The proposal is vaguely similar to GLEP 33. There is also an existing implementation of per-package eclasses called eblits (used in glibc, possibly in other places.) The GLEP should refer to these (link to GLEP 33, if there is a page describing eblits; link to that as well.) The GLEP should also discuss why GLEP 33 and eblits are not the best implementation of this idea. If the GLEP makes claims such as 'The implementation will improve X or reduce Y by Z%' the GLEP should cite sources, data, or make some kind of argument as to why that is the case. For instance the GLEP refers to 'distributing ebuilds in overlays will be easier' but fails to discuss how it is easier in this new system. When thinking about these types of things; try to break them down into something measurable. For instance: "With the old system there were 5 individual steps, the new system only has 3." The GLEP makes claims about how the per-package eclasses *could* be made part of the Manifest format. The GLEP should not focus on could. Either the per-package eclasses are part of the manifest code (per this GLEP) or they are not. If the GLEP dictates they are to be included in manifests the GLEP should discuss how exactly that will work (what types, checksums, etc..) If the eclasses are not required to be manifested then the GLEP should not tout that as an advantage over the status quo. > > So, yeah, what do you think? Is it worth it? Can the draft be improved? > I'm specifically interested in the amount of work involved in supporting > something like the thing laid out in the GLEP in our current PMs. > Any dev can check stuff into other dev's individual CVS space. Feel free to edit the eclass in my devspace if you wish. I think there is some automation on the actual GLEP webspace now (that htmlifies GLEPS) so I am avoiding that space cause I forgot how exactly the automation works ;))
