spotty availability for the next day or so
Posted by mcummings
I have a big project about to go into production on Friday, so my gentoo-land activity will be a little spotty the next day or so. I'll continue hacking away at the outdated list (updated nightly if your curious - and a direct result of ian's new code for up2date), maybe a little bug squashing, but I can't guarantee anything. Shoot, how's that different from normal one might ask...
7 years, no itching :)
Posted by mcummings
Just had to share - 7 years ago this afternoon my wife said something like "Sure" before a minister and a slew of family, coworkers, and friends (we even still talk to some of them) and we've been married ever since. When you catch up to this blog post babe, and I know you read 'em all, even the boring gentoo ones, I love you, happy anniversary!!
up2date-ng and g-cpan
Posted by mcummings
Ended up not working on g-cpan this weekend, but I did fiddle a lot with ian's code for up2date-ng (hope he didn't take offense, I *think* my improvements were valid...). Working on that code, though, I saw a lot of things that could be borrowed to improve g-cpan considerably, which has me considering something drastically weird, like rewriting portions of g-cpan from scratch based on up2date-ng code. For instance, with a few function changes I think we can streamline the entire ebuild build process, plus have better accuracy on module/ebuild names as we go. Maybe I can hack up a quick flow chart/proof of concept this afternoon (that's unresponsible, time is abundantly flowing mcummings, who hasn't been introduced to reality in a while).
Cool week :)
Posted by mcummings
OK, so my real life work may be a bit overbearing right now (I had to fill out a customer survey for a vendor today...and mark myself as Management...ouch...) but in gentoo-land this week has kinda rocked 
Sure, I'm still hacking away at g-cpan in private lest anyone see the mess I'm making, but in other news I had someone log into my blog and answer one of the questions from my laundry list post the other day (wow! wasn't meant as a challenge, but it saved me a bunch of time and will be going at the very least into g-cpan, maybe even perl-module.eclass (re:autoinstall)). Then ian pokes his head up, and I'm all in the delegation-mode at the office and ask if he can take a look at up2date to speed it up/improve it, and he turns around and tonight alone rewrote it all from scratch and yowza! It's fast, smooth, sleek even, and where my job ran for a long time on the sparc before, it now finishes in seconds. (AND generates guide-xml compliant pages). Holy crow what a nice week in the off hours
laundry list
Posted by mcummings
I'm sitting here, distracting myself from g-cpan by getting perl-critic into portage, watching modules build and pass tests. A couple of things are striking me as I watch this merge output scroll by over and over again...
- Since we've added the disclaimer that man pages aren't being generated on purpose any more, maybe we should go the extra step and actually remove them when they do get created by accident...?
- Why do we put CHANGES, or more importantly, MANIFESTs, into /usr/share/doc? MANIFESTS are pointless after the install is done - that's something you want to verify and check during the build process (which happens automatically when you run perl Makefile.PL these days btw). This should probably get canned, even though the file system savings for space will probably measure up to a whole kilobyte for the average user (woohoo).
- What's up with the gentoo-pods crap? Legacy as all get out, not sure what the point is, as near as I can tell if we are willing to disable man3 pages when the user can simply perldoc (and more reliably get info), why do we create the pod pages?
- resplitting dev-perl. I know, I have a bug open on this, but after my temporary departure I lost the oomph on this. That and people voiced concerns (legit) about how this affected packages (built via portage) and so I stopped pushing it. But as I look at adding perl-critic, which has to be the coolest add-on tool I've seen in a while for perl ide work (also check out the newly updated perl-support plugin for vim, which can use perl-critic as soon as I get it all in the tree), I realize again that that tree is way beyond manageable. We could easily have a perl-test category, perl-xml, together clearing out a good 60-100 ebuilds from a bloated @600 package tree.
- I need to research ExtUtils::AutoInstall and see if we can override it. Very annoying, especially with g-cpan ebuilds, because it flumoxes the whole process with nasty interactive content.
- Need to fix/rewrite the up2date scripts that generate email to gentoo-perl@lists.g.o. The script is functional, minus a caveat or two, but its a long shot from a clean implementation, and I think its runtime could be cut down from hours on the sparc to minutes (granted, its an old sparc folks, so minutes would be like seconds on a flashy new box).
- Need to finish my edits to g-cpan and get that in testing. Actually pretty close to this, just working out some re-writes for the new dep handling. Fingers crossed that it will be done this weekend at the latest.
- Need to track down and check every package that perl herd shows up as maintainer for. I came across XML-XSH this moring, which is over in app-editors, and completely neglected. It isn't intentional, but we focus so much on what up2date tells us that I know I at least tend to forget about the stuff that isn't hosted on cpan.
- Need to do the 'stupid' fixes for perl-cleaner. Nothing dramatic, but portage syntax has changed since the last update so some of the stuff it does is now considered deprecated.
- bugs. bugs. bugs. squash 'em, stomp 'em, eat 'em up yum, but with work the way it is this week, and me adjusting to the new schedule, there hasn't been enough of that going on.
OK, I think that's just barely enough for now. At least for a starter list