(Even more description of what I'm expecting in patches.)
(→Stuff in the future)
|Line 81:||Line 81:|
== Stuff in the past ==
== Stuff in the past ==
Revision as of 15:33, 9 October 2012
- Email: pjones at redhat dot com
- IRC: pjones on freenode
- Fedora Account: pjones
- Time Zone: EST5EDT
- Location: Cambridge, MA
I work in the installer group at Red Hat, which is part of the Base OS group.
Most of the work I do has to do with anaconda, dracut/mkinitrd, and bootloaders. I'm also one of the upstream kernel maintainers for iBFT parsing code and the EFI framebuffer driver.
I'm a member of the Fedora Engineering Steering Committee.
I do stuff.
Do not say "ping" or ask if I'm around. Ask the question you're planning on asking or don't.
Submitting patches for my packages
If you're going to submit bugs for packages I maintain, such as grub2, there are some things you should know. Generally my packages use git to apply their patches. This has a couple of advantages, like relatively strict requirements on what you've got to include. In general, if you're working on a bug in one of my packages, you can (and should) use a work flow that looks like this:
eddie:~/devel/fedora$ fedpkg clone grub2 Cloning into 'grub2'... remote: Counting objects: 861, done. remote: Compressing objects: 100% (758/758), done. remote: Total 861 (delta 489), reused 181 (delta 84) Receiving objects: 100% (861/861), 191.37 KiB, done. Resolving deltas: 100% (489/489), done. eddie:~/devel/fedora$ cd grub2 eddie:~/devel/fedora/grub2$ git checkout f18 Branch f18 set up to track remote branch f18 from origin. Switched to a new branch 'f18' eddie:~/devel/fedora/grub2$ fedpkg prep Downloading grub-2.00.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5016k 100 5016k 0 0 995k 0 0:00:05 0:00:05 --:--:-- 1097k Downloading theme.tar.bz2 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 11784 100 11784 0 0 24031 0 --:--:-- --:--:-- --:--:-- 99025 Downloading unifont-5.1.20080820.pcf.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1347k 100 1347k 0 0 607k 0 0:00:02 0:00:02 --:--:-- 730k Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.kCQV5r <-- you'll see a lot of crap here --> eddie:~/devel/fedora/grub2$ cd grub-2.00 eddie:~/devel/fedora/grub2/grub-2.00$ git config user.email email@example.com eddie:~/devel/fedora/grub2/grub-2.00$ git config user.name 'Your Name'
At this point you should make whatever changes you need to make - either directly or by applying some patch you've written and making sure it's all there. Commit your changes just like you would with any git repository - "git add" and "git commit" will work here as anywhere. When you're ready to send the patch, use "git format-patch -1", and send the result.
When you commit your changes, git will fire up an editor for you to write a changelog is to put a brief description (think "email subject") on the first line, then a blank line, and then a more complete description of what you've done and why, including the bugzilla bug number for the problem.
If you don't use "git format-patch" to generate your patch, I'm unlikely to take your patch, since "git am" won't apply the patch later and that will mean extra work for me.
If you don't write a good changelog, I'm unlikely to take your patch. At some point I will have to remember why we needed the patch, and if I don't have a description and don't know the bugzilla it was for, that will mean a lot more work for me.
If your patch has the wrong name or email, I'm unlikely to take your patch. At some point I'll have to rectify it against what has been or needs to be sent upstream, and that would make it harder, and that will mean extra work for me.
By default my email address is used, because this is the process I use. You are not me, so I would need to fix your patch to say it's from you instead of me, and that will mean extra work for me. Also often people send in patches that they themselves did not write - this includes patches they found on somebody's blog, patches you delegated the writing of to an underling, and other reasons. If you're sending somebody else's patch to me, one of you will have to make sure the author's name is on it, because if I do it, I'll as likely as not be wrong, and in the end that means extra work for me.
I don't like extra work. I'm happy to do just the right amount of work, but that's really it.
Stuff in the future
- GRUB2 "completed boot" support
- shutdown --firmware
- sbsetup - basically all of it, also --enroll-rom
- efi rom hash dumper
- modelist EDID dumping
- tiano trap handlers / tracebacks
- uefi standalone mode switching app
Stuff in the past
- Booting from devices with 4kB sector size
- A simple guide to setting up a network-boot server