How to speed up maintenance and other Gentoo work?

I’m collecting ideas from the wider development and contributing community on how to help maintainers and contributors get work done quicker, or rephrased – how to get more done in the limited time we have.

This basically means ideas for tools, scripts, or functionality in some hypothetical centralized maintainer helper website or GUI/CLI program that would help save time in taking care of some of the gruntwork that gets done by maintainers right now manually or by scripts that don’t get shared and re-used and generalized as much as they could.

Then afterwards I can sort through the suggestions/ideas, try to make a summary and arrange some of them to actually happen.

If things get done quicker, there is theoretically more available time, which hopefully would translate into being able to bring us back to the bleeding edge in one hand, and high quality in another.

I have intentionally left out my own ideas at start to keep everyone’s mind open to various approaches to this.

Please share your thoughts and ideas as a comment here, on my matching e-mail thread to gentoo-dev mailing list or via private e-mail!

(I think with this post I prevented my blogging pause to not reach over a year by about 20 minutes :)))

5 thoughts on “How to speed up maintenance and other Gentoo work?”

  1. 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.

  2. 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.

  3. 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.

  4. 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 their 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.

  5. 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

Leave a Reply

Your email address will not be published. Required fields are marked *