Mart Raudsepp - Latest comments on How to speed up maintenance and other Gentoo work?

In response to: How to speed up maintenance and other Gentoo work?

Elite Digital Review [Visitor] — Fri, 24 Jul 2009 15:00:08 +0000

there's no way I want to go through all those packages and customize them.. it'll take way more time than fixing the issues I came up against.

In response to: How to speed up maintenance and other Gentoo work?

Shawn [Visitor] — Fri, 06 Mar 2009 01:59:13 +0000

I found it a bit twilight-zone-ish that you wrote this.. I have been thinking about this over the past few days. Lemme explain why.. I am a long time gentoo fan.. but decided I might be tired of piecing my system together. (long compile times to realize I missed a USE flag and starting over)

So for the past few months, I've been working with Ubuntu and Fedora installations, throwing away my Gentoo install. (It was the only way to be entirely subjective about the others)

I honestly liked ubuntu.. it lasted the longest, until, I tried to upgrade Mono. What a disaster. I think the problem's mainly stemmed from the fact that mono itself, on unbuntu, was built into many pieces and I didn't have the patience to re-create the package using the same pieces. I wanted the whole Enchilada, but all the other provided packages required the pieces.. in the end I decided I wanted my Gentoo system back.

But.. I've been gone for a while and coming back was not as pleasant of an experience I used to have. There are known cylic dependency problems that haven't been resolved for months to start off. (avahi and cup, networkmanager and something else.. i cant remember) Not a big deal.. just disable the use flags, get everything installed and then recompile everything afterwards with the use flags enabled again.. long, but I don't have to babysit it, so ok.

Now everything is installed and I should be able to fire up gnome. X doesn't work. Sigh.. I've used the same config forever. Get past that.

Now X starts and I'm sitting at GDM. Keyboard and mouse don't work. Find out that I should add two new sections to my conf file to tell it where my event (using evdev driver) device are.. or was it the two .fdi files I added.. no idea. but it works..

Now i'm logged in.. try to start up compiz and no window decorations.. eventually, my entire system freezes and I have to hit reset. But, while my system is being brought to a crawl, I notice control-c doesn't work. (or else compiz-manager would've died and I wouldn't have been reduced to hitting reset)

so lets look at the control-c issue.. 'stty -a' intr is ^C.. huh? 24 hours later looking for that solution I decide to install ksh just to see if it's bash.. after emerging ksh93 I 'exec /bin/ksh'.. no luck.. but I log out and log back in.. and control-c starts working in bash.. What? (yes.. I assume it's somewhere in the profile chain.. but it's working. who cares)

anyway.. I digress.. the entire time I'm thinking to myself.. I need to build myself a custom distro where I have no-one to blame, but myself. But I look at all the ebuilds (490 just to emerge gnome) and I'm thinking.. geez.. there's no way I want to go through all those packages and customize them.. it'll take way more time than fixing the issues I came up against.

But that gets me thinking.. why on earth isn't that automated?!? why can't the developers of the application provide enough metadata about their own application that package maintainers can then use.. and hopefully script the creation of new packages. instead of burdening a handful of package managers with coming up with the data for 500+ packages, make 500+ application developers do it once and manage the changes? Shouldn't burden them too much.

another thing I've been thinking about is /etc.. I think this needs a drastic overhaul.. 90% of whats out there is key-value pair, with 1000 different syntax flavors.. (probably grossly exaggerating here.. perhaps 90% of the ones I ever edit) Now.. I'm a DBA by trade and I'm looking at the key-values.. and then I'm looking at fuse.. and I'm thinking.. That's interesting. Why not a database driver configuration system tied into fuse for backward compatibility?? Stop the nonsense of checking diffs against new and old.. but I've added comments so they don't patch cleanly. (change foo = new_value if foo is still the default, regardless of what the rest of the file looks like) this certainly doesn't have to be a sqlite backend either.. perhaps XML is better suited for the non-key/value types?? (oh..and I'm not sure scripts of any sort should be under etc.. that just seems weird.. I've been doing this long enough that it's expected)

Anyway.. this is probably way to long.. sorry for the noise, but I felt compelled to answer 8D

In response to: How to speed up maintenance and other Gentoo work?

Craig [Visitor] — Wed, 04 Mar 2009 20:09:25 +0000

(Their not There... ugghh / oh and amusingly your comment form won't take my legitimate email address, just some fake info I typed in)

In response to: How to speed up maintenance and other Gentoo work?

Craig [Visitor] — Wed, 04 Mar 2009 20:07:32 +0000

I'm not a maintainer but I was curious if this approach will yield the expected result? You could produce some tools but how will you know if it was a valuable exercise.

At the risk of sounding like a corporate drone - good goals are SMART (specific, measurable, attainable, realistic, timed). Off the top, I'm not sure how you will measure your results. You are looking for ideas of something to create, but how will you decide if the ideas are worth digging into, or have delivered the expected results.

Would a brief survey to your existing maintainers, to find out what they spend there time on, how much time, and what they are not getting to, not help establish some metrics to move forward with.

Then you can have specific areas to tackle, a basis for more specific questions (is it the tools or other external uncontrollable factors such as their time available) and be able to measure it... even if just with another formal survey.

It's a little more work (although the survey shouldn't feel like more work to the maintainers) and will give your team something to build on year after year.

In response to: How to speed up maintenance and other Gentoo work?

Scott Shawcroft [Visitor] — Wed, 04 Mar 2009 06:38:20 +0000

I'm working on researching the migration from upstream to downstream. It won't help with bug hunting per se but at least will find version bumps. It tracks versions of packages in different distributions. The website is not finished yet but will give a glimpse of what info I've got.

In response to: How to speed up maintenance and other Gentoo work?

Jeremy Olexa [Visitor] — Wed, 04 Mar 2009 05:44:42 +0000

Steve,
There is already two bugzie auto-assign projects in the works. They just are a) waiting for bugzilla-3 or b) waiting to be accepted. For this you want to contact robbat2, rbu, or nelchael. All of whom have working prototypes.

In response to: How to speed up maintenance and other Gentoo work?

Steve Dibb [Visitor] — Wed, 04 Mar 2009 04:28:05 +0000

One idea I have that I've been kicking around in my head, is a sort of a bug-wrangling helper tool, for those who would like to wrangle bugs.

Basically it would query the open, unassigned bugs, search the subject for keywords that are in ebuilds, and assist them in who it should be assigned to.