pushes at v4l-utils tree
Hi Hans,
As we've agreed that the idea is to allow multiple people to commit at v4l-utils, today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is .gitignore stuff). One of the reasons were to test the viability for such commits.
I've temporarily enabled the same script that we use for upstream patches to generate patches against linuxtv-commits ML.
Quoted 1 line
From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same tree.
The reason is simple: it won't preserve the same group as the previous commits. So, the next committer will have troubles if we allow multiple committers;
2) people need to pull/rebase before pushing, if we fix the group permission
issue above. I've enabled a hook that is meant to avoid rebase upstream, to prevent troubles if people push something with -f. I hope it works fine.
3) the mailbomb script uses the from: as the email author. However, the
linuxtv-commits is limited to posts from a few specific authors. So, I need to add more emails there or change the policy, if we decide to use such script. I'll keep the script disabled for now, until I have some time to check it.
In summary, for now, I think that the better is to post all patches to v4l-utils at ML and ask Hans to merge them.
Signature · 2 lines
Cheers, Mauro
Hi,
Quoted 6 lines · Mauro Carvalho Chehab
Hi Hans,
As we've agreed that the idea is to allow multiple people to commit at v4l-utils, today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is .gitignore stuff). One of the reasons were to test the viability for such commits.
Quoted 8 lines
I've temporarily enabled the same script that we use for upstream patches to generate patches against linuxtv-commits ML.
From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same tree.
The reason is simple: it won't preserve the same group as the previous commits. So, the next committer will have troubles if we allow multiple committers;
I assume you are talking about some issues with permissions on the server side here ?
Quoted 4 lines
2) people need to pull/rebase before pushing, if we fix the group permission
issue above. I've enabled a hook that is meant to avoid rebase upstream, to prevent troubles if people push something with -f. I hope it works fine.
Ack, actually I just did that (rebase my local tree before pushing) as you pushed some changes before I did.
Quoted 3 lines
In summary, for now, I think that the better is to post all patches to v4l-utils at ML and ask Hans to merge them.
Yes and no, if you've a few patches, sure. If you are doing regular development you should get commit access. In my experience in various projects multiple people pushing to the same git tree will work fine.
Regards,
Hans
Quoted 23 lines · Hans de Goede
Hi,
Quoted 12 lines · Mauro Carvalho Chehab
Hi Hans,
As we've agreed that the idea is to allow multiple people to commit at v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is .gitignore
stuff). One of the reasons were to test the viability for such commits.I've temporarily enabled the same script that we use for upstream patches to
generate patches against linuxtv-commits ML.Quoted 7 lines
From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same
tree.
The reason is simple: it won't preserve the same group as the previous commits. So,
the next committer will have troubles if we allow multiple committers;
Quoted 2 lines
I assume you are talking about some issues with permissions on the server side here ?
Yes. The new objects and the touched files got a different group ownership after git push. I had to manually fix them at the server.
Quoted 10 lines
Quoted 4 lines
In summary, for now, I think that the better is to post all patches to v4l-utils at ML
and ask Hans to merge them.Yes and no, if you've a few patches, sure. If you are doing regular development you should
get commit access. In my experience in various projects multiple people pushing to the
same git tree will work fine.
We need to see how they're fixing the permissions. I suspect that they have some post-update script that redo the proper file permissions. Do you know what they use?
Signature · 2 lines
Cheers, Mauro
Quoted 24 lines · On Fri, 12 Mar 2010 16:29:46 -0300 Mauro Carvalho Chehab <[email protected]>…
Quoted 23 lines · Hans de Goede
Hi,
Quoted 19 lines · Mauro Carvalho Chehab
Hi Hans,
As we've agreed that the idea is to allow multiple people to commit at v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is .gitignore
stuff). One of the reasons were to test the viability for such commits.I've temporarily enabled the same script that we use for upstream patches to
generate patches against linuxtv-commits ML.From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same
tree.
The reason is simple: it won't preserve the same group as the previous commits. So,
the next committer will have troubles if we allow multiple committers;
Quoted 6 lines
Quoted 2 lines
I assume you are talking about some issues with permissions on the server side here ?
Yes. The new objects and the touched files got a different group ownership after git push. I had to manually fix them at the server.
The following might be inappropriate, as I didn't follow the discussion about the linuxtv git infrastructure.
Using gitosis[1,2] these permission issues shouldn't occur, because only one user (usually "git") actually writes to the filesystem while commit rights are still handled with ssh pubkeys, and this doesn't even require creating users on the server.
As I said I don't know if you are using gitosis already, if so then sorry for the noise.
Regards,
Antonio
[1] http://eagain.net/gitweb/?p=gitosis.git
[2] http://ao2.it/wiki/How_to_setup_a_GIT_server_with_gitosis_and_gitweb
Signature · 10 lines
Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Quoted 23 lines · Mauro Carvalho Chehab
Quoted 22 lines · Hans de Goede
Hi,
Quoted 19 lines · Mauro Carvalho Chehab
Hi Hans,
As we've agreed that the idea is to allow multiple people to commit at v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is .gitignore
stuff). One of the reasons were to test the viability for such commits.I've temporarily enabled the same script that we use for upstream patches to
generate patches against linuxtv-commits ML.From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same
tree.
The reason is simple: it won't preserve the same group as the previous commits. So,
the next committer will have troubles if we allow multiple committers;
Quoted 5 lines
Quoted 2 lines
I assume you are talking about some issues with permissions on the server side here ?
Yes. The new objects and the touched files got a different group ownership after git push. I had to manually fix them at the server.
I added a hook that will likely fix it. As I have a few more changes to ir-keytable, I'll be sending it directly and see if the permissions are properly fixed.
Please, don't upgrade the version yet just due to keytable, as I'm still working on more keytable patches, to handle the new uevent attributes (to match the IR core patches I posted earlier today).
Signature · 2 lines
Cheers, Mauro
Quoted 8 lines · Mauro Carvalho Chehab
Quoted 4 lines · Mauro Carvalho Chehab
Hans de Goede wrote:
Yes. The new objects and the touched files got a different group ownership after git push. I had to manually fix them at the server.
I added a hook that will likely fix it. As I have a few more changes to ir-keytable, I'll be sending it directly and see if the permissions are properly fixed.
After some work, it is now working properly. So, it is safe for the others to update on it without breaking the permissions.
Quoted 3 lines
Please, don't upgrade the version yet just due to keytable, as I'm still working on more keytable patches, to handle the new uevent attributes (to match the IR core patches I posted earlier today).
Added what I have for now. The ir-keytable is now doing a nice job reading the new sysfs stuff from /sys/class/irrcv, with the new IR patches I posted. I'll add tomorrow the ir-core patches at v4l-dvb tree, if no comments received.
The next item on keytable TODO list is to add ir-keytable at Makefile install target and to put it to work together with udev. After those changes, it will be possible to replace an IR table when a device is detected by udev.
I'll probably write an example script to do a very basic udev setup,but a more sophisticated userspace tool would be needed to allow someone to do it via some gui.
Signature · 2 lines
Cheers, Mauro
Hi,
Quoted 4 lines · Mauro Carvalho Chehab
Please, don't upgrade the version yet just due to keytable, as I'm still working on more keytable patches, to handle the new uevent attributes (to match the IR core patches I posted earlier today).
Ok,
Note the main reason for the 0.7.91 release was a small libv4l fix which I wanted to get out there.
Regards,
Hans
Quoted 10 lines · Hans de Goede
Hi,
Quoted 6 lines · Mauro Carvalho Chehab
Please, don't upgrade the version yet just due to keytable, as I'm still working on
more keytable patches, to handle the new uevent attributes (to match the IR core patches
I posted earlier today).
Quoted 4 lines
Ok,
Note the main reason for the 0.7.91 release was a small libv4l fix which I wanted to get out there.
No problem. Feel free to increase release version when you change libv4l again. There's no hush to rise the version due to keytable, as it needs the new ir-core patches for the new features to work.
Signature · 2 lines
Cheers, Mauro
Hi,
Quoted 24 lines · Mauro Carvalho Chehab
Quoted 23 lines · Hans de Goede
Hi,
Quoted 19 lines · Mauro Carvalho Chehab
Hi Hans,
As we've agreed that the idea is to allow multiple people to commit at v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is .gitignore
stuff). One of the reasons were to test the viability for such commits.I've temporarily enabled the same script that we use for upstream patches to
generate patches against linuxtv-commits ML.From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same
tree.
The reason is simple: it won't preserve the same group as the previous commits. So,
the next committer will have troubles if we allow multiple committers;
Quoted 6 lines
Quoted 2 lines
I assume you are talking about some issues with permissions on the server side here ?
Yes. The new objects and the touched files got a different group ownership after git push. I had to manually fix them at the server.
I'll get you in touch with one of the Fedora infrastructure admins.
Regards,
Hans