| When worlds collide |
[Sep. 16th, 2009|09:51 pm] |
Every once in a great while, the worlds of parenthood and geekdom collide in somewhat amusing ways. As I previously posted, I had ordered some cables and they arrived today. I decided to go ahead and run the 100' ethernet cable from my upstairs office to the utility room in the basement. The intention is to move some of my more loud and hot-running machines down to the basement. More on that in another post.
When my two year old son heard I was going to run cable, he got really excited and asked if he could help. Of course he could. I never hesitate to do things with my kids that have even a small semblance of educational value. So I asked the 4 year old as well, but he was really more interested in building various forms of Lego space ships. He opted to just watch (occasionally).
I proceed to try and figure out how I'm actually going to get the cable through the floor and into the basement. This took a bit, but my son dutifully followed me up and down the stairs as I scratched my head a lot and generally tried to not let the frustration get the better of me (which is a lot harder than it might sound). Long story short, I changed the junction box in the office that I was going to start from to the one on the other wall and this made things immensely easier. No drilling required.
As I'm wrapping up, my son is beginning to get a paniced look on his face and keeps saying he wants to run cable. I let him pull some of the cable through the wall and this placates him for a bit. When I announce we're all done, he promptly bursts into tears and keeps saying "I run cable, I run cable". More frustration and head scratching ensues.
Eventually we figure out that he thought we were literally going to physically run around with a cable. So I grabbed the shortest patch cable I had handy, and we went outside and each held and end and ran around the yard. I'm sure this looked entirely bizarre, but 30 seconds of it was enough to satisfy him. Yet another geek-parent crisis averted! |
|
|
| Frustration |
[Sep. 12th, 2009|07:58 am] |
Buy new 1.5 TB hard drive, check.
Open computer and find the Dell has a really nice screwless drive bay setup, check.
Put in computer, check.
Figure out there is no SATA cable to hook it up with. @&@^!&@&@
Go to Wal-Mart with the ridiculous hope they'll sell SATA cables. Fail.
Order new cable newegg and wait another 5 days. Sigh
I hate it when that happens.
One might wonder why I didn't just go to Best Buy or Frys or something like that. I live in the middle of nowhere, so driving to a store that would likely have a cable would be about a 40 min drive. Being a hermit does have disadvantages sometimes.
On the bright side, I also got a 100' ethernet cable, so now I can hopefully move some of my machines to the basement. Some of those will include builders for a local koji instance I'm hoping to put up. We'll see how things go. |
|
|
| Mmmm.... storage |
[Sep. 5th, 2009|08:01 am] |
For the first time in several years, I actually purchased an additional hard drive. Usually every few years I get a new machine with a sufficiently larger hard drive that suits my needs, so I have no use for extra drives. However, I keep running out of disk space on various machines and it's annoying enough to warrant the purchase. I also have something I'd like to start running that will likely consume a lot of disk anyway, and you can never have too many KVM guests which can carry a bit disk footprint.
I bought a Western Digital Caviar 1.5TB SATA drive. It will sit in my Dell Linux box which is already acting as my storage for the most part. There is the ever debatable filesystem choice to make, however I'll probably go with ext4. While btrfs seems like it's going to be the defacto FS in not too horribly long, I don't think it's stable enough for me to rely on very heavily.
Partitioning is another problem. Arguably partitioning the drive would allow me to use some partitions for KVM guest drives instead of loopback files. It would also help with some encapsulation of tasks. However I'm not really sure if it is worth partitioning at all. I'm considering just leaving it as one big partition. What do you think lazyweb?
Oh, speaking of storage, I also purchased a dedicated music player. No, I did not buy an iPod/iPhone. While those are shiny, I don't really have a need for something like that since I have an n800 and the iPhone would be a waste of money since I live in the middle of farm fields and we don't get cell reception at all outside of our house. Instead, I got a San Disk Sansa Clip 2GB player. Yes, laugh if you'd like, but it was $30, plays mp3, flac, and ogg (and wma but who uses that?) and is very small. The built in clip was important because I play on using it during my running/exercising sessions and the n800 is too bulky to do that with.
New toys are always exciting. Now if they would only show up already... |
|
|
| What's next? |
[Aug. 11th, 2009|09:09 pm] |
I'm in a software rut. Or maybe, software itself is in a rut. Either way, I can't say I find the differences from one release to the next to be mind blowing anymore. I thought about the last 4 applications that had some kind of impact on my daily computing usage. They are:
virt-manager/kvm (virt in general)
firefox 3.x
mutt (with SMTP support)
vim 7.x
There are some that are obviously missing, like openoffice, the major Gnome/KDE releases, major gcc updates, etc. But none of these have fundamentally changed how I actually do things on a daily basis. This is not to say that they aren't improving from release to release. I think they are. However, I don't get excited about them when I install the new release.
So I've been on the lookout for something that seems like it would be cool and a bit game changing to me. There's been a lot of press about Gnome 3 and the Gnome Shell. I took a look at gnome-shell a bit today and I'll be doing the Fedora package review for it tomorrow. Unfortunately, it doesn't work in a KVM guest due to needing 3d accel. I'm a little torn on that, but I can see why it's heading in that direction. So I think I'll scrounge up a machine and really give it a go.
Will it change how I work? I have no idea. Maybe I'm just a computing old man that likes his worn-in armchair. But I'd at least like to find _something_ to get pumped about again. |
|
|
| Fedora updates pushing: Behind the scenes |
[Jul. 24th, 2009|03:56 pm] |
Just before F11 release, we enabled deltarpms for updates. There were some bumps in the first few days, but we got through it and the people rejoiced. Everyone was happy and the Fedora updates world had a victory in terms of end user gains.
Then time went by. Updates kept getting submitted by maintainers, and they noticed they were pushed to users less and less frequently. Some asked on the list, and rel-eng (mostly me) blamed deltarpms. This was not an untruth. Generating deltarpms is a pretty intensive task, and the larger the RPMs in question, the longer it takes to actually generate them. So our illustrious Infrastructure team took note and increase the DRAM and number of CPUs the releng box had. This has proved to be most helpful, and our box no longer gets kernel OOMs if the rawhide and updates mashes happen to be going at the same time. However I still didn't think something was right.
It was taking 2-3 days _per_ push. What does a push entail? Bodhi moves koji tags on the submitted updates, then it mashes f10-updates, f10-updates-testing (no drpms), f11-updates, and f11-updates testing, and when all that is done it performs the repomd.xml, bugzilla update, and announce email steps. Now, that's a lot to do, but 2-3 days seemed really excessive.
The first thing we noticed was that it was taking 6-10 hours to mash just f10-updates. Over time, the updates repo grows and it takes longer to mash than a fresh release. However, 6-10 hours was longer than f9-updates ever took. It seemed about 2x longer than it should take, and there were no deltarpms to take into consideration. So we poked. We pondered. We noticed that all the mtimes on the updates were from the day of the mash, and not from the time the package was created. What did that mean? Well we found out that the releng box had an odd mount situation that prevented the normal hardlinks that occur. That doesn't sound like a huge issue, but it has pretty bad impacts.
First, it means mash has to copy all the relevant RPMs to a different location on the same NFS mounted filesystem. SLOW. Then when the updates push wound up completing, the mirrors would basically be slammed trying to update every single RPM in the push due to the mtimes changing. Couple that with the fact that the master mirrors were having major issues at the same time, and this meant that even our top tier mirrors were continually out of date. Ew.
We fixed that ASAP and noticed an immediate improvement in f10-updates-testing and f10-updates mash times. Right back to the normal 2.5-3 hours for f10-updates. Awesome! Everything was cake and gravy and we were all happy again, right?
No.
It fixed the f10 release updates, and significantly helped the mirror situation, but mashing the f11-updates and f11-updates-testing repos still took forever. The overall push times were now 1-2 days (depending on various factors), which was a good improvement, but it still seemed off to me. So we dug into it more. And sure enough, we found another issue. I noticed that during the f11-updates mash, we were creating drpms for package combinations that already had drpms present. When you take into account that this included huge things like wesnoth-data and openjdk and other large RPMs, it was very easy to see why it was taking so long to mash the repos.
This was a bit baffling to me, because it is obviously stupid to simply not reuse the existing drpms. I looked in the mash code (and confirmed with the author) and it did seem that mash was set up to copy any pre-existing drpms that were still valid so we could avoid regenerating them. But this code wasn't working. We slapped some debug stuff together and figured out that there was a bad assumption in the drpm handling code in mash from day 1. Namely, drpms have their own type of signature in the drpm header and this is what was being compared to the RPM sig. They never matched, so the existing drpms were never used even though they would produce a fully and properly signed RPM at update time. So we worked around that for now.
The next day, updates pushes went from 1-2 days (which was already decreased from 2-3 days), to 8-9 hours. HOURS! We can theoretically do more than one updates push in a 24 hour period now if we have to. This makes it possible for us to be more responsive to items which may need to be pushed out rapidly (security updates for example). It also has the pleasant side effect of not making me want to cry every time I start an updates push or read the LWN.net daily security updates article.
Is everything cool beans now? Well, no. I think there is a lot more we can do to make the back-end of the updates system better. But it's certainly great to see us get back to a state I consider usable.
If you're enjoying the goodness that is deltarpms, and have noticed the improved turnaround time, give some kudos to all those that helped fix things up: Mike McGrath, Ricky Zhou, Seth Vidal and Bill Nottingham (I am probably missing a few people, and if so I apologize. It was a long few weeks.) |
|
|
| virt-manager and guest serial console |
[Jul. 2nd, 2009|02:55 pm] |
So maybe this is already well known, but I always have a heck of a time getting a serial console to one of my KVM guests managed by virt-manager. I don't know why this is, but I do. The UI doesn't seem to present an interface for it, and the hardware wizard doesn't present an option for adding a serial port to the guest hardware. So I sat down and figured out how to get it working today, at least with F11.
Most of my guests have a serial port configured in the guest.xml file already. Whether I added this long ago, or virt-install creates it, I can't tell. If your guests don't have this, the syntax seems to be:
<serial type='pty'>
<target port='0'/>
</serial>
I opened up the guest details GUI in virt-manager, went to the serial port entry and saw that Serial 0 was directed to /dev/pts/10. I started the guest up, edited the kernel command line boot parameters to include 'console=ttyS0', and booted.
Then I did what I would do normally for any real machine hooked up to a serial port and fired up the tried and true 'minicom' like this: sudo minicom -p /dev/pts/10
Amazingly enough, there was the serial output. A few quick configuration changes later, and I could even login to the guest via that.
This may be really really simple. Some of you may even be laughing that I bothered to write this up. I don't care. My googling skills either suck, or this isn't very widely known. If nothing else, I wrote it up so I could remind my tiny brain how I did it before. Maybe someone else will find it helpful too. |
|
|
| Random Fedora Observation of the Day |
[Jun. 26th, 2009|11:00 pm] |
The PackageKit applet. Leaving ugly red zits on my panel since Fedora 10.
Seriously. It is the most excited and overzealous software I have seen in a long time. It continues to signify updates available, regardless of whether or not there are. Even when I click on it and it then reports none available.
I would care or rant or file a bug, but it's persistence is so astounding that I can't help but find it cute. Perhaps it knows that I'm doing updates pushes as fast as I can, so it doesn't bother turning itself off.
So I applaud you PackageKit applet. Even in your utter failure to function properly, you still seem to get it right anyway. |
|
|
| Updated Fedora 11 PPC iso |
[Jun. 24th, 2009|03:04 pm] |
Due to a bug found really late in the F11 cycle (as in 3-4 days before release), the GA boot.iso and CD/DVD iso images that came with Fedora 11 are broken on ppc64 machines. The bug wound up being in yaboot, and thus was not easy enough to fix for the release since the compose and media use yaboot to boot things. Sad day.
But wait!
I bugged Jesse Keating about possibly spinning an updated boot.iso with the yaboot from F11-updates. To which he replied, "That's just a pungi compose with updates enabled. Can't you do that?" And behold, he was right. So I did that. And then I had a couple of awesome people test it. And it worked.
You can find the updated boot.iso here:
http://jwboyer.fedorapeople.org/boot.iso
There is no warranty, it is not guaranteed to work, and if it makes your system catch on fire it is not my fault. But hopefully people find it useful and we get a massive explosion of ppc64 systems installed with F11 because of it.
Moral of today's story: Ask not what Fedora can do for you, but how you can use Fedora to scratch your own itch! |
|
|
| Fedora Updates Status |
[Jun. 23rd, 2009|04:21 pm] |
I hate microblogging. I don't understand it, it seems like a big waste of time, and I'm busy enough as it is. However, I get asked often enough about 'When is the next updates push going to happen' or 'Where is the push at?' that I have decided to do something about it.
I created an identi.ca account for myself. I'll post updates push information on there, and that's pretty much all I'll use it for. So if you're interested in know what is going on with the updates and updates pushes, follow 'jwboyer' on identi.ca. THIS IS NOT FOOL-PROOF AND NOT DEFINITIVE, but I will try and update it regularly.
That is all. I now return you to your regularly scheduled fu. |
|
|
| Fedora PPC |
[Jun. 19th, 2009|09:30 am] |
I realized that I haven't blogged about the change in store for PowerPC when Fedora 13 comes about. Contrary to some beliefs, it's not because I am bitter or busy sobbing into a beer. Mostly, I've just been very busy lately.
I understand the reasoning behind the Board and FESCo decisions. I do believe that having a non-x86 architecture as a primary arch is a benefit to not only Fedora, but also to the upstream projects we consume. It helps keep code bases robust and portable and exposes maintainers to something a little different. However, given the statistics we have I can't really fault the committees for voting the change.
Instead I'll take a second to point out that if we want Fedora to continue to work well on PowerPC, we'll need people to step up and help out. While the change doesn't switch over until Fedora 13, I would almost like to get things in place and ramped up starting _now_. That way when the primary koji instance switches off, it should be fairly seamless.
So what do we really need in place? Well, we need to flesh out a SIG for starters. And behold, we already have a SIG wiki page. Though I will note it is very out of date and probably needs redoing completely. Aside from that we need:
- Koji builders. The Board has a request in to reuse the existing Fedora ppc builders. This will require some coordination, given that the builders will still need to be used for F10, F11, and F12 as primary builders and they can only talk to one koji hub (I think). So assuming the Board approves, we'll likely split a small number out for F13 and add more as other releases expire. Long term though, we'll need to come up with replacement hardware.
- A Koji hub. This would be the hub the builders talk to for the ppc secondary arch. It will also need a larger amount of storage to store all the packages being built.
- People. We so need people. People to fix bugs, people to run the hubs, people to TEST. People to TEST. Oh, and people to TEST.
Things we can work towards after we get some of the above in place:
- Releases. If we're at the point we can build the package set fairly regularly and test it out, then we can focus on some rel-eng type issues like composing releases.
- Updates. We'll need a bodhi instance running somewhere to manage this, and we'll probably have to sit down and think about how it's really going to work.
Sound like a challenge? You bet. But if it also sounds like fun and you want to help out, then let me know. Sign up for the fedora-ppc list. Subscribe to the SIG wiki page. Hopefully we can take our users (and yes, we do have users) and make them contributors. I know I'm at least going to try. |
|
|
| FAD Day 2 |
[Jun. 9th, 2009|08:51 pm] |
We picked up today where we left off. Starting off the day with a wonderful literal video translation of the horrible Bonnie Tyler 'Turn Around' music video was a bit odd, but hilarious nonetheless.
We brainstormed a bit more on the topic we had intentionally avoided yesterday, which is how we manage freezes, why they suck, etc. It's been fairly well known that freezes are painful, and the final freeze impacts both our developers and release engineering team pretty hard. This is arguably one of the reasons we had the FAD to begin with, so it was great to get the issues out in the open.
After a break, we moved from brainstorming about the problems to thinking about some of the actual solutions that we could reasonably implement. After we had been working in the issues for a while, it was starting to become apparent which were fairly easy, which were really hard, and which we should spend the effort on. I was pleased when we were able to identify a few key issues that if we really fixed them, they would make yet a wider set of issues much more simple.
The next steps for tomorrow, are to sit down with the ideas and start drafting up some proposals to present to the community for discussion. I do want to stress that we're drafting PROPOSALS, and not policies. Unfortunately, I won't be able to attend tomorrow's session.
Towards the end of the day, Jesse asked whether we thought the overall FAD was worthwhile. To me, it was a two fold answer. I think it was a huge success in that the concentrated, uninterrupted all-day sessions allowed us to accomplish in 2 days what would have taken at least 3 weeks on the various rel-eng and QA lists. Working on lists and IRC is how we do business, but at times there is no replacement for face-to-face communication.
The second, and arguably most important, part of my answer depends on you, the contributors. The return on investment really comes from the submission, discussion, and hopefully positive feedback and approval of the proposals that are being worked on. I have high hopes that we'll submit some pretty good proposals with good background and information about what, how, and why the changes are being proposed. If we get a number of these approved, then I really think we can help our contributors and make the Fedora project that much better of a project to work on.
I am pretty excited about this and hoping the outcome is positive.
Unrelated: The Red Wings better win tonight, or my face-to-face taunting of Greg will be slightly wasted. There is no substitute for face-to-face taunting when you have won a bet. GO WINGS |
|
|
| FAD Day 1 |
[Jun. 8th, 2009|10:33 pm] |
As I'm sure you've seen by now, today was Day 1 of the development cycle Fedora Activity Day. Overall, I think this was a really productive day.
We started off by doing something called 'Design Thinking'. This was new to me, and sounds pretty buzzwordy, but the general premise is to identify the problems you are facing without focusing on the negative aspects of this or devolving the discussion into details about stuff that generally doesn't matter. To be honest, it sounded a bit too Zen for me at first, but I think it worked rather well. The irony of staying positive while identifying all the fail was no lost on me though.
We had two whiteboards full of various topics that were deemed to be problems in one form or another. Many of them were sort of inter-related, but a surprising number didn't overlap. We took these, did a BarCamp style voting on them, and came up with a set of items to start discussing.
We cherry-picked from the list and identified a number that just seemed outside the scope of the FAD, which helped focus things a bit. Then we started to delve into the remaining items and flesh out some of the details of the problems. We got through a good number of them, but the harder ones are remaining for tomorrow.
I was quiet pleased with the level of participation in the discussions, both in the room and in the IRC channel and VoIP session. We also had an active gobby session going to log our notes to place into the Wiki as we work. I'm sure tomorrow will bring even better results. |
|
|
| The Elections are actual races now! |
[Jun. 1st, 2009|09:35 am] |
I was a bit surprised to see that the FESCo election nomination page had an explosion of candidates over the weekend. There are 5 seats open at the moment, and 12 candidates. Out of those 12, there are 7 people who have never served on FESCo before, 1 coming back to the fold, and 4 FESCo members that have their seats up for election. I think this will make for a great race, and we'll get some new blood into the engineering leadership as well.
The Board election is also a race between 5 candidates for 3 seats.
Looking forward to some of the town-hall meetings and such coming up. Remember, if you have questions for any candidate in the FESCo or Board election, feel free to ask them. Or you can add your question to the Election Questionnaire. |
|
|
| Victory! |
[May. 27th, 2009|01:09 pm] |
By all kinds of random math I can think of, I seem to have won the Fedora Hockey Challenge. I've yet to figure out how I'm going to collect all my prizes, but I look forward to a fine sampling from all of the LOSERS!
I'm so hoping my team completes the challenge and wins the Stanley Cup. Go Wings! |
|
|
| Names |
[May. 19th, 2009|08:09 pm] |
Do you like the Name game for Fedora releases? Do you think you have an awesome name for F12? Great! Want to make sure it actually has a chance of being a candidate? I thought so. So here is how to do that:
1) Read the full instructions on the wiki page http://fedoraproject.org/wiki/Name_suggestions_for_Fedora_12 This is important for a number of reasons. Primarily, if you don't follow the rules then your name has no chance at all of being a candidate. Secondly, if you put down a name "because it's cool" or "sounds awesome" you are just wasting the time of the people trying to actually get the name selection done. This is more than just me, this is also the Board, Red Hat's legal department, and everyone else that has to read through the name list to avoid duplicates
2) Try to be creative, and also give a way to get to something after F12. This is why we do this whole name game to begin with. It is supposed to be a fun semi-brain teaser type of exercise. The more creative the link, the more possibilities you open up. Just make sure the link fits the rules.
3) For bonus points, think of things that fit 1 and 2, and then think 'is this art themeable?' The only reason we now do the name selection so early is so the art team actually has time to try and come up with a theme for the artwork that matches the name. There is no rule that says the artwork has to match the name, but the art team does a really great job at trying their best to match it. So reciprocate a bit, and help them out too.
If everyone tries their best and stick to the rules, the name game can be actually fun. |
|
|
| Translators rock |
[May. 13th, 2009|08:29 pm] |
In the free software world, people often think of 'translators' as those that have the sometimes tedious job of taking the typically horrible error messages, dialog boxes, and other interactive messages that we code in our apps and translating them to other languages. And that is certainly true. It's a thankless job, and the Fedora community has an awesome translation SIG. They have even created Transifex which should help upstreams and other distros with their translation tasks. I find this simply amazing.
I can't help but notice though, that when I read Planet Fedora there are other types of translations that are also valuable that don't get much mention. Recently I blogged about the return of deltarpms to F11. LWN picked this up, which helps our PR a bit after somewhat of a small black eye about them not being in place a while ago. But there is a whole class of users that don't speak English and needed to know. Over the past few days, I have seen a number of blog posts in other languages that are talking about my post and yum-presto. I think the simple act of doing that is really helping distribute news to our global community and I just wanted to say Thanks! to those of you that are doing this.
Full disclosure: I have no idea if those blog posts are actually reporting the correct information, since my non-English skills primarily consist of some very rudimentary Spanish, enough German to be polite but not really say anything, and Japanese swear words. For all I know, they could be saying "Josh Boyer is an idiot for talking about DeltaRPMs and yum-presto." But I trust they aren't and even if they are maybe this post will encourage others to step in and help here too. |
|
|
| Super Saiyan Jack |
[May. 12th, 2009|08:14 pm] |
Is my son a Super Saiyan? The world will never know.
note: That is his real hair. There is no gel or mousse or hairspray in it. It's naturally curly and just happened to look like that today. He was kind enough to indulge Dad with a 'grumpy' face for the picture though. He thought it was hilarious when I showed him the 'glowing guys'.
Edit: Removed the hotlink to the goten picture. Sorry about that. |
|
|
| Fedora 11 Deltarpms: The Doom That Wasn't |
[May. 9th, 2009|08:56 am] |
Recently, Paul blogged about the awesomeness that is yum-presto and Deltarpms. I clarified that we weren't quite ready for F11 updates to have deltarpms enabled, but that we were working on it but wasn't sure if we would have the work completed. LWN picked this up, and apparently so did many other blogs and community members.
So today I would like to draw your attention to:
http://download.fedora.redhat.com/pub/fedora/linux/updates/11/i386/drpms/
Oh, yeah. That's right. What you see there is indeed deltarpms for the first Fedora 11 updates push. So Paul, you can un-edit your blog post now because we should be ready to go for Fedora 11 GA. We'll probably still have a few hiccups here and there, but the infrastructure is now in place.
I'd like to highlight that Seth Vidal, Luke Macken, and Bill Nottingham were the primary factors to getting this complete. They did the createrepo, bodhi, and mash changes needed. I'm always pleasantly surprised when people care enough to start digging in and fixing an issue they care about.
Fedora 11 is now made of that much more awesomeness. |
|
|
| The updates conundrum |
[Apr. 21st, 2009|09:15 pm] |
I have been the primary update pushed for Fedora for about 2 months now. Having done this every week day for that long has led me to some completely subjective opinions on updates, release lifecycles, and the health of our update system (from an admin point of view).
Overall, we have a lot of updates. The metrics page shows a decreasing trend the longer the release has been available. This is generally good, but there are still a very large number of updates that make me scratch my head when I see them, either because the update lacks any useful information at all, or because the update itself seems to make little sense in a stable releaes. Jesse Keating tried to highlight some of these questionable updates but it seems he was either ignored or berated for being "heavy handed".
When I see a package update submitted that just takes a package to the latest upstream release, I always question it in my head (and sometimes in the update). I realize that upstream releases often fix bugs that effect users, however the update should say that at a minimum and it generally doesn't. Many times there is an update like this that seems to just be 'because it's the newest!' Which leads me to my next annoyance.
Fedora doesn't have a rolling release. We have a large number of contributors that work rather hard at keeping with the various package freezes, mass rebuilds, and other administrative work that goes along with creating a release from rawhide. Yet after that release has GAed, we seem to sort of throw that out and just submit updates for updating's sake. It is not uncommon for a package to have identical versions in the three active releases. It is not uncommon to have a brand new package submitted to all active releases at the same time. While I'm quite aware of some of the reasoning behind this, I still question the practice of doing that. And it boils down to this: What value does that add?
Honestly, I have found myself running yum update not because I have problems. Not because I need some new package, but just because 'yum update' is habit (security updates aside).
So... why do I care? Because it adds churn that doesn't seem to be needed. It adds churn to the mirrors. It takes longer and longer to mash the updates repos. It requires more time to sign all the updates. And honestly, it causes churn for our users.
The one benefit (and I say that in a sort of silver lining way) that has come from this is that it has helped me understand some of the weak points we have in the updates process, both in the bodhi backend code and just the actual process. Things like
1) We need more people that understand the bodhi code from front to back. Luke Macken is amazing at fixing things, but I think he would agree that it sucks when I ping him on IRC because bodhi failed a push. I'm getting better about this, but it's an example of a 'single point of fixing'.
2) We need to make the bodhi code a bit more resilient and/or verbose in error messages. Things like revoked updates during certain stages of an updates push can cause hassles and delays.
3) We need less updates. Oh, I already said that.
Well, I see a pile of updates to go sign. Guess I should stop ranting and get back to being part of the problem ;) |
|
|
| Not so posty |
[Apr. 20th, 2009|08:32 am] |
I haven't posted much lately. Neither here, nor on many of the mailing lists I subscribe to. There are a number of reasons. The first is that work is incredibly busy right now. I won't go into more detail there, but it's been sucking up pretty much all of my time.
However, there is a not so mundane reason too. These days, I'm finding that there are very few discussions that are actually worth joining. Now, I still read almost all of them. I still follow things, and I still look for pain points in communities that could actually be larger problems. But these are getting harder and harder to find amongst all the random complaints, mini-flames, sardonic replies, and general abundance of whining.
Too often these days I see posts that start out well intentioned enough, only to devolve into petty bickering and endless example/counter-example. Questioning a change, or making a proposition for a change are usually how it begins. There might be a few emails generated to get a better understanding of why something changed, or what goals someone has. Maybe a few more explaining 'the foo default changed, but you can do X,Y, and Z to set it back'. All of that is generally fine. It seems inevitable though that after the basics of the issues are hammered out, people continue to rant against whatever change happened or was proposed. It can actually be quite draining.
So, I just avoid adding to the noise and refrain from posting at all. In the odd case where something is explicitly addressed to me (or to FESCo, etc), I will certainly comment. I try to do so without being overly sarcastic or inflammatory, which sometimes works and sometimes doesn't. Thankfully, situations like that seem pretty rare. (It is nearly impossible to do all posts without sarcasm. It seems to be the single common trait among all of us.)
Btw, I don't think any of this is actually new. It is perhaps just hitting with greater frequency than in the past. Possibly due to overall community growth, better participation from existing users; I dunno. Maybe the rants will ebb a bit in the future and make the various lists a bit more constructive place to participate in again. At least I hope so.
(And NO. I do not think Fedora needs a Code of Conduct. In fact, I think that would actually make it worse.) |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
jwboyer's journal