I’ve been noticing a drop in feedback since I started writing about the tinderbox and the work going on there. I can, from some points of view at least, understand it, since it really does not say much that is useful for end users to know. Indeed it’s often technicalities, or ebuild guidelines, or QA information, all stuff that the average user of any kind of software likely don’t care about.
So why should Gentoo users read my blog? Why should developers for what matters? Well I’m not sure I can properly answer these question, after all even I don’t know why I do it so how can I explain, to someone else, why what I do is important?
Well, I don’t know why I do what I do, but I know what I do. Okay this is a very intricate phrase, but the bottom line is that I know that the topics I write about are important and should really be properly considered. When I speak about the problems I face with the tinderbox, I speak about problems with real ebuilds, with ebuilds that, one way or another, got into the tree. By talking about the problems with them, I’m trying to explain what the new ebuilds should look like not to rot too easily.
Especially with the widespread usage of sunrise, and the lowered bar for ebuilds to be picked up from there, powerusers wanting to write their own ebuilds should try to learn from the mistakes of the developers that came before: live ebuilds for static revisions, gems for Ruby packages, and stuff like that are all things that should be avoided like the plague by the new ebuilds. Unfortunately it doesn’t seem to happen.
There are new ebuilds added with bundled libs, abused blockers, broken autotools, and so on so forth. While I know that some of what I wrote about should just be added to the official documentation, I’m afraid I don’t have the time. My blog, that I used to use as a reference documentation, starts to be too big, too chunky, too complex to maintain for that use; that I know, and that’s why I started working on my autotools guide (and I’m tempted to transpose For A Parallel World as an Appendix of that guide). But integrating the QA notes into the official documentation, that’s a task I cannot embark in right now.
So please, even though I know my titles don’t look tremendously appealing in general, try to give them a read, I’ll try my best to make them more exciting… maybe somebody can suggest me an ebuild to review or some package that needs --as-needed or parallel make fixes to write a case study about.