pushes at v4l-utils tree

pushes at v4l-utils tree

[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;

	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.

-- 

Cheers,
Mauro

Re: pushes at v4l-utils tree

[Hans de Goede]

Hi,

On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
> 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;
>

I assume you are talking about some issues with permissions on the server side here ?

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

> 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

Re: pushes at v4l-utils tree

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
>> 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;
>>
> 
> 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.

>> 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?

-- 

Cheers,
Mauro

Re: pushes at v4l-utils tree

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

On Fri, 12 Mar 2010 16:29:46 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:

> Hans de Goede wrote:
> > Hi,
> > 
> > On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
> >> 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;
> >>
> > 
> > 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

-- 
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?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: pushes at v4l-utils tree

[Mauro Carvalho Chehab]

Mauro Carvalho Chehab wrote:
> Hans de Goede wrote:
>> Hi,
>>
>> On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
>>> 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;
>>>
>> 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).

-- 

Cheers,
Mauro

Re: pushes at v4l-utils tree

[Mauro Carvalho Chehab]

Mauro Carvalho Chehab wrote:
> Mauro Carvalho Chehab wrote:
>> 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.

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

-- 

Cheers,
Mauro

Re: pushes at v4l-utils tree

[Hans de Goede]

Hi,

On 03/13/2010 02:24 AM, Mauro Carvalho Chehab wrote:
> 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

Re: pushes at v4l-utils tree

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 03/13/2010 02:24 AM, Mauro Carvalho Chehab wrote:
>> 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.

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.

-- 

Cheers,
Mauro

Re: pushes at v4l-utils tree

[Hans de Goede]

Hi,

On 03/12/2010 08:29 PM, Mauro Carvalho Chehab wrote:
> Hans de Goede wrote:
>> Hi,
>>
>> On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
>>> 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;
>>>
>>
>> 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