From Fedora Project Wiki

(Add explanation of using git on packages.)
(Even more description of what I'm expecting in patches.)
Line 57: Line 57:
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.
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 subject on the first line, then a blank line, and then a more complete description of what you've done and why.  I'm unlikely to take your patch unless you do this, and include a link to whatever bugzilla you're fixing. So be good and write a reasonable changelog :)
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 ==
== Stuff in the future ==

Revision as of 22:00, 18 September 2012

Peter Jones

Contact

  • Email: pjones at redhat dot com
  • IRC: pjones on freenode
  • Fedora Account: pjones
  • Time Zone: EST5EDT
  • Location: Cambridge, MA

About Me

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 youraddress@fedoraproject.org
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

Stuff in the past

Retrieved from "https://fedoraproject.org/w/index.php?title=User:Pjones&oldid=302326"