MAINTAINERS tree branches [xen tip as an example]

MAINTAINERS tree branches [xen tip as an example]

[Luis R. Rodriguez]

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

As per linux-next Next/Trees [0], and a recent January MAINTAINERS patch [1]
from David one of the xen development kernel git trees to track is
xen/git.git [2], this tree however gives has undefined references when doing a
fresh clone [shown below], but as expected does work well when only cloning
the linux-next branch [also below]. While I'm sure this is fine for
folks who can do the guess work do we really want to live with trees like
these on MAINTAINERS ? The MAINTAINERS file doesn't let us specify branches
required, so perhaps it should -- if we want to live with these ? Curious, how
many other git are there with a similar situation ?

The xen project web site actually lists [3] Konrad's xen git tree [4] for
development as the primary development tree, that probably should be
updated now, and likely with instructions to clone only the linux-next
branch ?

[0] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees#n176
[1] http://lists.xen.org/archives/html/xen-devel/2014-01/msg01504.html
[2] git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
[3] http://wiki.xenproject.org/wiki/Xen_Repositories#Primary_Xen_Repository
[4] git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

mcgrof@bubbles ~ $ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git --reference linux/.git
Cloning into 'tip'...
remote: Counting objects: 2806, done.
remote: Compressing objects: 100% (334/334), done.
remote: Total 1797 (delta 1511), reused 1646 (delta 1462)
Receiving objects: 100% (1797/1797), 711.01 KiB | 640.00 KiB/s, done.
Resolving deltas: 100% (1511/1511), completed with 306 local objects.
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

mcgrof@work ~ $ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git -b linux-next --reference linux/.git
Cloning into 'tip'...
remote: Counting objects: 2806, done.
remote: Compressing objects: 100% (377/377), done.
remote: Total 1797 (delta 1545), reused 1607 (delta 1419)
Receiving objects: 100% (1797/1797), 485.23 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1545/1545), completed with 327 local objects.
Checking connectivity... done.
Checking out files: 100% (44979/44979), done.

  Luis

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

Re: MAINTAINERS tree branches [xen tip as an example]

[Konrad Rzeszutek Wilk]

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
>As per linux-next Next/Trees [0], and a recent January MAINTAINERS
>patch [1]
>from David one of the xen development kernel git trees to track is
>xen/git.git [2], this tree however gives has undefined references when
>doing a
>fresh clone [shown below], but as expected does work well when only
>cloning
>the linux-next branch [also below]. While I'm sure this is fine for
>folks who can do the guess work do we really want to live with trees
>like
>these on MAINTAINERS ? The MAINTAINERS file doesn't let us specify
>branches
>required, so perhaps it should -- if we want to live with these ?

The master branch can be linked to the #linux-next or stable/for-linus.

That would solve the problem I think.
>Curious, how
>many other git are there with a similar situation ?
>
>The xen project web site actually lists [3] Konrad's xen git tree [4]
>for
>development as the primary development tree, that probably should be
>updated now, and likely with instructions to clone only the linux-next
>branch ?

Thank you for reporting. Will fix it next week if nobody else beats me to it.
>
>[0]
>https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees#n176
>[1] http://lists.xen.org/archives/html/xen-devel/2014-01/msg01504.html
>[2] git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
>[3]
>http://wiki.xenproject.org/wiki/Xen_Repositories#Primary_Xen_Repository
>[4] git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>
>mcgrof@bubbles ~ $ git clone
>git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git --reference
>linux/.git
>Cloning into 'tip'...
>remote: Counting objects: 2806, done.
>remote: Compressing objects: 100% (334/334), done.
>remote: Total 1797 (delta 1511), reused 1646 (delta 1462)
>Receiving objects: 100% (1797/1797), 711.01 KiB | 640.00 KiB/s, done.
>Resolving deltas: 100% (1511/1511), completed with 306 local objects.
>Checking connectivity... done.
>warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
>mcgrof@work ~ $ git clone
>git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git -b linux-next
>--reference linux/.git
>Cloning into 'tip'...
>remote: Counting objects: 2806, done.
>remote: Compressing objects: 100% (377/377), done.
>remote: Total 1797 (delta 1545), reused 1607 (delta 1419)
>Receiving objects: 100% (1797/1797), 485.23 KiB | 0 bytes/s, done.
>Resolving deltas: 100% (1545/1545), completed with 327 local objects.
>Checking connectivity... done.
>Checking out files: 100% (44979/44979), done.
>
>  Luis

Re: MAINTAINERS tree branches [xen tip as an example]

[David Vrabel]

On 17/01/14 23:02, Luis R. Rodriguez wrote:
> As per linux-next Next/Trees [0], and a recent January MAINTAINERS patch [1]
> from David one of the xen development kernel git trees to track is
> xen/git.git [2], this tree however gives has undefined references when doing a
> fresh clone [shown below], but as expected does work well when only cloning
> the linux-next branch [also below]. While I'm sure this is fine for
> folks who can do the guess work do we really want to live with trees like
> these on MAINTAINERS ? The MAINTAINERS file doesn't let us specify branches
> required, so perhaps it should -- if we want to live with these ? Curious, how
> many other git are there with a similar situation ?

We don't recommend doing development work for the Xen subsystem based on
xen/tip.git so I think it's fine to have to checkout the specific branch
you are interested in.

> The xen project web site actually lists [3] Konrad's xen git tree [4] for
> development as the primary development tree, that probably should be
> updated now, and likely with instructions to clone only the linux-next
> branch ?

I've updated the wiki to read:

    For development the recommended branch is:

        The mainline Linus linux.git tree.

    To see what's queued for the next release, the next merge window,
    and other work in progress:

        The Xen subsystem maintainers' tip.git tree.

David

Re: MAINTAINERS tree branches [xen tip as an example]

[Luis R. Rodriguez]

On Mon, Jan 20, 2014 at 2:38 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 17/01/14 23:02, Luis R. Rodriguez wrote:
>> As per linux-next Next/Trees [0], and a recent January MAINTAINERS patch [1]
>> from David one of the xen development kernel git trees to track is
>> xen/git.git [2], this tree however gives has undefined references when doing a
>> fresh clone [shown below], but as expected does work well when only cloning
>> the linux-next branch [also below]. While I'm sure this is fine for
>> folks who can do the guess work do we really want to live with trees like
>> these on MAINTAINERS ? The MAINTAINERS file doesn't let us specify branches
>> required, so perhaps it should -- if we want to live with these ? Curious, how
>> many other git are there with a similar situation ?
>
> We don't recommend doing development work for the Xen subsystem based on
> xen/tip.git so I think it's fine to have to checkout the specific branch
> you are interested in.

OK thanks.

>> The xen project web site actually lists [3] Konrad's xen git tree [4] for
>> development as the primary development tree, that probably should be
>> updated now, and likely with instructions to clone only the linux-next
>> branch ?
>
> I've updated the wiki to read:
>
>     For development the recommended branch is:
>
>         The mainline Linus linux.git tree.

Is the delta of what is queued for the next release typically small?
Otherwise someone doing development based on linux.git alone should
have conflicts with anything on the queue, no?

>     To see what's queued for the next release, the next merge window,
>     and other work in progress:
>
>         The Xen subsystem maintainers' tip.git tree.

That's the thing, you can't clone the tip.git tree today well, there
are undefined references and git gives up, asking for the linux-next
branch however did work.

  Luis

Re: MAINTAINERS tree branches [xen tip as an example]

[Konrad Rzeszutek Wilk]

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
>On Mon, Jan 20, 2014 at 2:38 AM, David Vrabel <david.vrabel@citrix.com>
>wrote:
>> On 17/01/14 23:02, Luis R. Rodriguez wrote:
>>> As per linux-next Next/Trees [0], and a recent January MAINTAINERS
>patch [1]
>>> from David one of the xen development kernel git trees to track is
>>> xen/git.git [2], this tree however gives has undefined references
>when doing a
>>> fresh clone [shown below], but as expected does work well when only
>cloning
>>> the linux-next branch [also below]. While I'm sure this is fine for
>>> folks who can do the guess work do we really want to live with trees
>like
>>> these on MAINTAINERS ? The MAINTAINERS file doesn't let us specify
>branches
>>> required, so perhaps it should -- if we want to live with these ?
>Curious, how
>>> many other git are there with a similar situation ?
>>
>> We don't recommend doing development work for the Xen subsystem based
>on
>> xen/tip.git so I think it's fine to have to checkout the specific
>branch
>> you are interested in.
>
>OK thanks.
>
>>> The xen project web site actually lists [3] Konrad's xen git tree
>[4] for
>>> development as the primary development tree, that probably should be
>>> updated now, and likely with instructions to clone only the
>linux-next
>>> branch ?
>>
>> I've updated the wiki to read:
>>
>>     For development the recommended branch is:
>>
>>         The mainline Linus linux.git tree.
>
>Is the delta of what is queued for the next release typically small?

Depends
>Otherwise someone doing development based on linux.git alone should
>have conflicts with anything on the queue, no?

Potentially. Usually the maintainer will spot where there are potential conflicts and give you a branch to base on.

>
>>     To see what's queued for the next release, the next merge window,
>>     and other work in progress:
>>
>>         The Xen subsystem maintainers' tip.git tree.
>
>That's the thing, you can't clone the tip.git tree today well, there
>are undefined references and git gives up, asking for the linux-next
>branch however did work.

It should work now. I made master point to 3.13.
>
>  Luis

Re: MAINTAINERS tree branches [xen tip as an example]

[David Vrabel]

On 20/01/14 18:33, Luis R. Rodriguez wrote:
> On Mon, Jan 20, 2014 at 2:38 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 17/01/14 23:02, Luis R. Rodriguez wrote:
>>> As per linux-next Next/Trees [0], and a recent January MAINTAINERS patch [1]
>>> from David one of the xen development kernel git trees to track is
>>> xen/git.git [2], this tree however gives has undefined references when doing a
>>> fresh clone [shown below], but as expected does work well when only cloning
>>> the linux-next branch [also below]. While I'm sure this is fine for
>>> folks who can do the guess work do we really want to live with trees like
>>> these on MAINTAINERS ? The MAINTAINERS file doesn't let us specify branches
>>> required, so perhaps it should -- if we want to live with these ? Curious, how
>>> many other git are there with a similar situation ?
>>
>> We don't recommend doing development work for the Xen subsystem based on
>> xen/tip.git so I think it's fine to have to checkout the specific branch
>> you are interested in.
> 
> OK thanks.
> 
>>> The xen project web site actually lists [3] Konrad's xen git tree [4] for
>>> development as the primary development tree, that probably should be
>>> updated now, and likely with instructions to clone only the linux-next
>>> branch ?
>>
>> I've updated the wiki to read:
>>
>>     For development the recommended branch is:
>>
>>         The mainline Linus linux.git tree.
> 
> Is the delta of what is queued for the next release typically small?
> Otherwise someone doing development based on linux.git alone should
> have conflicts with anything on the queue, no?

We've not had any issues so far.

>>     To see what's queued for the next release, the next merge window,
>>     and other work in progress:
>>
>>         The Xen subsystem maintainers' tip.git tree.
> 
> That's the thing, you can't clone the tip.git tree today well, there
> are undefined references and git gives up, asking for the linux-next
> branch however did work.

I think it did work, you just needed to checkout a branch manually.

But it looks like Konrad has pushed a master branch recently, as well.

David

Re: MAINTAINERS tree branches [xen tip as an example]

[Luis R. Rodriguez]

On Mon, Jan 20, 2014 at 11:02 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 20/01/14 18:33, Luis R. Rodriguez wrote:
>> Is the delta of what is queued for the next release typically small?
>> Otherwise someone doing development based on linux.git alone should
>> have conflicts with anything on the queue, no?
>
> We've not had any issues so far.

Will give that a shot.

>>>     To see what's queued for the next release, the next merge window,
>>>     and other work in progress:
>>>
>>>         The Xen subsystem maintainers' tip.git tree.
>>
>> That's the thing, you can't clone the tip.git tree today well, there
>> are undefined references and git gives up, asking for the linux-next
>> branch however did work.
>
> I think it did work, you just needed to checkout a branch manually.

Indeed, I just didn't expect random developer to know how to fix this,
and if other git trees will exist in the same form I figured its best
to extend MAINTAINERS to specify the preference for a branch. In this
case, since the branch is not recommended for development, I suppose
the recommendation no longer applies for this tree.

> But it looks like Konrad has pushed a master branch recently, as well.

That gives me a warm fuzzy, thanks.

 Luis