[Xcb] xinput:QueryDeviceState: git-repo with patches of this thread

[Christian Linhart]

Hi Ran,

On 09/05/14 15:10, Ran Benita wrote: 
> I have some more "procedural" requests (for the future), sorry :)
Thank you for your procedural requests which will make working together more efficient.
I'll try to incorporate them in my work system...

> You have a few repos there with dates, it's a bit hard to follow. May I
> suggest using just a single repo, one for proto and one for xcb, and use
> appropriately-named feature branches for different sets of patches? Then
> it is easier to see the latest versions of the patches, what depends on
> what and in what order we should review (and if you put the repo url +
> branch name in a patchset's cover letter that would be great). The
> libxcb/proto split makes it a bit more difficult but you can give
> matching branches the same name.
> 
> (Although if you make changes maybe it's better to create a
> <branch-name>-v2 branch, see here:
> http://git-scm.com/book/ch3-6.html#The-Perils-of-Rebasing)
Actually I didn't rebase but recreated the repos with scripts that
read the posts, automatically chooses the highest version of each patch
and apply them to a new clone of the official repo.
This way, further versions of patches can be conveniently handled.
( I have attached these scripts. Maybe they are useful for you, too.
If they are useful please tell me. In that case I'll set up a 
public repo or sourceforge project for them. )

***

But I see that this recreation of repos 
is not optimal because there is no
unique ID for each commit and the many repos 
will become confusing.

I'll try to adapt a scheme which will match your requests.

Maybe I'll try to adapt my scripts to do branching in an existing repo,
without rebasing or recreating commits for the same patch.
Shouldn't be too difficult.
(Or I change my work procedures.)

Whenever there is a new V2 or V3 of one or multiple patches, a new branch 
will be generated, merging all the subsequent commits so that
there'll be no duplication of them.

But we may end up with a lot of branches...
Maybe I should make an empty commit with subject 
"This branch is superceded by branch XYZ" 
at the head of obsoleted branches?

> 
> Also, if you create a pull request or V2 for a set of patches, consider
> amending them with the R-b tags you got (unless there were substantial
> changes which require re-reviewing). This again helps with further
> review and saves the committer some work.
Yes I can do that.
Maybe I can automate that as well which will enhance reliability.
I am good at automation but bad at manually following such procedures. :-)

Adding Revieved-By tags will create a new branch and will create a new
SHA id for all reviewed posts, so the advantages of having a unique id
for each patch will be gone. (Maybe the unique id is not so important?)

> 
> Finally, since you make significant contributions you should probably
> add a Signed-off-by tag to your patches. See towards the end here for
> what this means:
> http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches/
Ah, that makes sense, so that everything is legally ok. 
Yes, I'll do that. You can assume Signed-off-by for all of my previous patches, too.

In fact, I do all of this work in my own business and I am not employed by any other company,
so nobody else can interfere, and therefore we are safe from a legal perspective.

> If all of this is confusing let us know :)
> 
> And thanks for your continued work! With an MIT license people sometimes
> choose to keep such work hidden...
You are welcome. And thank you for appreciating my work!

It doesn't make sense for me to keep that hidden.
The same applies to any fixes or incremental improvements of open source software...
( maybe it makes sense to keep it hidden temporarily to meet some internal deadline
and do the publishing work later. As I do with my XCB-XKeyboard fixes.)

The MIT license also has some advantages because 
more people are likely to use the code, and that
may increase contributions.
Actually this applies in my case. :-)

Chris



-------------- next part --------------
A non-text attachment was scrubbed...
Name: ApplyMbox.sh
Type: application/x-shellscript
Size: 772 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20140905/3432ae5f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FilterOldAndAddReviewedBy.pl
Type: application/x-perl
Size: 7924 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20140905/3432ae5f/attachment-0001.bin>