On Mon, Nov 5, 2012 at 7:48 PM, Brian Harring <ferri...@gmail.com> wrote: > On Mon, Nov 05, 2012 at 06:54:45PM -0500, Mike Gilbert wrote: >> On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring <ferri...@gmail.com> wrote: >> > This isn't quite what I'm asking for. I want y'all to literally >> > document thus: >> > >> > 1) What your finished solution is going to look like. Users control >> > which implementations are enabled via PYTHON_TARGETS, how y'all will >> > handle if no targets are currently specified (user hasn't made a >> > choice), etc. >> > >> > 2) How you're planning on getting there- literally, how things are >> > going to transition to your proposed replacement for python.eclass, >> > how the use deps will be structured, the potential gaps dependencye >> > wise as you go forward, etc. >> > >> > As I indicated in my email, all folks see are changes coming in, no >> > sign of the actual end form you're intending, nor how you plan on >> > getting there. >> > >> > I realize y'all may get pissed at being asked to layout your actual >> > plans... fact is, python.eclass got into this mess since people >> > couldn't track where it was going ultimately leading to the source >> > being spaghetti. >> > >> > Lay out where y'all are going w/ this, and *how*, so people can >> > actually comment/contribute/avoid recreating another python.eclass >> > where no one understands it. :) >> > >> >> I will admit right now that I don't have a "master plan" in mind, and >> we are sort of making it up as we go along. I am not a software >> engineer; I just like to read/hack on code. I would love for some >> master architect to come along and document where we are headed, but >> that hasn't happened. And I'm not the person to do it -- it just >> doesn't interest me. >> >> mgorny has been writing lots of code and is looking for someone to >> review it. I'm very good at answering specific questions and offering >> an informed opinion, so I'm attempting to do so. > > Just zeroing in on this since my other questions aren't really getting > addressed in the fashion I want- this however is the core point. > > Bluntly, there needs to be a plan- and it needs to be shared w/ folk. > > I wasn't kidding when I stated "review requires making sure your > reviewer understands your change and the intent"; as is, all that's > realistically occurring here is mgorny gets at best a comment or two > bash wise, and that's it- nothing more since no one particularly knows > where this is going and we just see random patchsets w/out much > explanation as to how this all plugs together. > > I'm not demanding a point by point plan here; I'm frankly asking that > the steps/end results be shared so that we don't wind up with another > python.eclass, just this time w/ mgorny being the one who's got it all > in his head. > > It's easy enough to write up a doc (glep if you want) laying out the > intent and the roadmap. This should be done- if it has been already, > link it in somewhere or start referencing it so the rest of us know > wtf the plan is. > > Simple example, I'd ask "why was PYTHON_TARGETS added when USE_PYTHON > could've been fixed/coopted into the same thing?". I ask that now, > I'll get flak/bitchyness frankly since it's already deployed/in use. > > Either way, I'm honestly not trying to piss folks off here nor stop > the efforts to dig us out of the python.eclass mess. That said, *this > time around* that eclass should actually have a plan so that we don't > wind up in the same cluster fuck scenario as prior. > > It's a simple enough request; document your roadmap. Asking for > reviews w/out that, frankly, is pointless (and sooner or later some > asswipe like me is going to start -1'ing things till that's > addressed). >
If anyone wants to help in drafting a GLEP, I would appreciate it. I'll try to start that this week. There will definitely be some holes, since I really don't have an all encompassing plan in my head. But it will be good to fill those in.
