Re: Git dies of lack of interest?

[Richard S. Hall]

> On Dec 1, 2015, at 19:14, Benson Margulies  wrote:
> 
> On Dec 1, 2015 6:43 PM, "Richard S. Hall"  wrote:
>> 
>> 
>>> On Dec 1, 2015, at 17:50, Benson Margulies 
> wrote:
>>> 
>>> 
> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
>>> 
>>> ?
>> 
>> Seems like a good start, although is that editable by others?
> 
> I don't know. Try? I don't have perms to make a page on the Felix wiki , if
> I get some I will move it.

Well, I sort of did try, which is why I was asking. Perhaps I didn’t see the 
“edit” button.

Regardless, I’m the wrong person to try to lead this debate anyway, since I 
don’t enjoy SCM if the first place… :-)

-> richard

> 
>> 
>> It seems like other technical issues were raised about the approaches, so
> it would be nice to see those added in there by people who have experience.
>> 
>> I admit, for me, SCM is a necessary evil and not something I get too
> exited about. I haven’t seen anything to prefer git over svn or vice versa.
> They’re just different hammers for the same nail.
>> 
>> Still, thinking about the options, it seems like multiple repos creates a
> maintenance headache to some degree. For example, line-ending handling is
> fairly difficult to get configured correctly in git. By having multiple
> repositories, then every repository would have to have this configured
> individually, since stuff like that is good to have configured uniformly.
> Any changes to how we want things uniformly handled would require manual
> propagation of configuration. Of course, this seems like it would be an
> issue in any proliferation of repositories (svn or git).
>> 
>> Or perhaps there is a better way to handle such issues?
>> 
>> -> richard
>> 
>>> 
>>> 
>>> On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall 
> wrote:
 On 12/1/15 13:40 , Carsten Ziegeler wrote:
> 
> Richard S. Hall wrote
>> 
>> Well, the argument to the contrary is perhaps that is makes it more
>> difficult for us as a community to have oversight into releases. It
>> almost assures us that some/many community members will never
> checkout
>> subprojects that aren't in the repository they normally work.
> Granted,
>> there is no guarantee of this now, since I can just check out what I
>> want anyway...but at least it is fairly easy for me to do so now and
> it
>> becomes more difficult if everyone spreads to their own repos.
>> 
>> So, in that regard, I'm more aligned with Marcel...all or nothing
> makes
>> more sense.
> 
> Hmm, ok fair point - however, the *all* is the problematic part where
> we
> couldn't agree on last time (one git repo vs many git repos).
 
 
 But isn't it then incumbent on those wanting such changes to convince
> us one
 way or the other?
 
 Personally, I'd rather just have one big git repo if we are going to
> switch,
 if for no other reason than it seems like less overhead. However, I
> admit to
 not really knowing the advantages/disadvantages.
 
 Regardless, at a minimum, perhaps someone should create a documented
 pros/cons list for the approaches. This would at least give us a way
> to call
 a vote where we can feel somewhat informed about the choices (i.e.,
> stay
 with svn, move to one git repo, move to many git repos).
 
 Better than saying, "there is no consensus, so let's just go our
> separate
 ways"...
 
 -> richard
 
 
> 
> We could still provide a script in the root of svn which checks out
> the
> moved projects from git and gives the same experience :)
> 
> Carsten
 
 
>> 

Re: Git dies of lack of interest?

[Richard S. Hall]

> On Dec 1, 2015, at 17:50, Benson Margulies  wrote:
> 
> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
> 
> ?

Seems like a good start, although is that editable by others?

It seems like other technical issues were raised about the approaches, so it 
would be nice to see those added in there by people who have experience.

I admit, for me, SCM is a necessary evil and not something I get too exited 
about. I haven’t seen anything to prefer git over svn or vice versa. They’re 
just different hammers for the same nail.

Still, thinking about the options, it seems like multiple repos creates a 
maintenance headache to some degree. For example, line-ending handling is 
fairly difficult to get configured correctly in git. By having multiple 
repositories, then every repository would have to have this configured 
individually, since stuff like that is good to have configured uniformly. Any 
changes to how we want things uniformly handled would require manual 
propagation of configuration. Of course, this seems like it would be an issue 
in any proliferation of repositories (svn or git).

Or perhaps there is a better way to handle such issues?

-> richard

> 
> 
> On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall  wrote:
>> On 12/1/15 13:40 , Carsten Ziegeler wrote:
>>> 
>>> Richard S. Hall wrote
 
 Well, the argument to the contrary is perhaps that is makes it more
 difficult for us as a community to have oversight into releases. It
 almost assures us that some/many community members will never checkout
 subprojects that aren't in the repository they normally work. Granted,
 there is no guarantee of this now, since I can just check out what I
 want anyway...but at least it is fairly easy for me to do so now and it
 becomes more difficult if everyone spreads to their own repos.
 
 So, in that regard, I'm more aligned with Marcel...all or nothing makes
 more sense.
>>> 
>>> Hmm, ok fair point - however, the *all* is the problematic part where we
>>> couldn't agree on last time (one git repo vs many git repos).
>> 
>> 
>> But isn't it then incumbent on those wanting such changes to convince us one
>> way or the other?
>> 
>> Personally, I'd rather just have one big git repo if we are going to switch,
>> if for no other reason than it seems like less overhead. However, I admit to
>> not really knowing the advantages/disadvantages.
>> 
>> Regardless, at a minimum, perhaps someone should create a documented
>> pros/cons list for the approaches. This would at least give us a way to call
>> a vote where we can feel somewhat informed about the choices (i.e., stay
>> with svn, move to one git repo, move to many git repos).
>> 
>> Better than saying, "there is no consensus, so let's just go our separate
>> ways"...
>> 
>> -> richard
>> 
>> 
>>> 
>>> We could still provide a script in the root of svn which checks out the
>>> moved projects from git and gives the same experience :)
>>> 
>>> Carsten
>> 
>> 

Re: Git dies of lack of interest?

[Benson Margulies]

On Dec 1, 2015 6:43 PM, "Richard S. Hall"  wrote:
>
>
> > On Dec 1, 2015, at 17:50, Benson Margulies 
wrote:
> >
> >
https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
> >
> > ?
>
> Seems like a good start, although is that editable by others?

I don't know. Try? I don't have perms to make a page on the Felix wiki , if
I get some I will move it.

>
> It seems like other technical issues were raised about the approaches, so
it would be nice to see those added in there by people who have experience.
>
> I admit, for me, SCM is a necessary evil and not something I get too
exited about. I haven’t seen anything to prefer git over svn or vice versa.
They’re just different hammers for the same nail.
>
> Still, thinking about the options, it seems like multiple repos creates a
maintenance headache to some degree. For example, line-ending handling is
fairly difficult to get configured correctly in git. By having multiple
repositories, then every repository would have to have this configured
individually, since stuff like that is good to have configured uniformly.
Any changes to how we want things uniformly handled would require manual
propagation of configuration. Of course, this seems like it would be an
issue in any proliferation of repositories (svn or git).
>
> Or perhaps there is a better way to handle such issues?
>
> -> richard
>
> >
> >
> > On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall 
wrote:
> >> On 12/1/15 13:40 , Carsten Ziegeler wrote:
> >>>
> >>> Richard S. Hall wrote
> 
>  Well, the argument to the contrary is perhaps that is makes it more
>  difficult for us as a community to have oversight into releases. It
>  almost assures us that some/many community members will never
checkout
>  subprojects that aren't in the repository they normally work.
Granted,
>  there is no guarantee of this now, since I can just check out what I
>  want anyway...but at least it is fairly easy for me to do so now and
it
>  becomes more difficult if everyone spreads to their own repos.
> 
>  So, in that regard, I'm more aligned with Marcel...all or nothing
makes
>  more sense.
> >>>
> >>> Hmm, ok fair point - however, the *all* is the problematic part where
we
> >>> couldn't agree on last time (one git repo vs many git repos).
> >>
> >>
> >> But isn't it then incumbent on those wanting such changes to convince
us one
> >> way or the other?
> >>
> >> Personally, I'd rather just have one big git repo if we are going to
switch,
> >> if for no other reason than it seems like less overhead. However, I
admit to
> >> not really knowing the advantages/disadvantages.
> >>
> >> Regardless, at a minimum, perhaps someone should create a documented
> >> pros/cons list for the approaches. This would at least give us a way
to call
> >> a vote where we can feel somewhat informed about the choices (i.e.,
stay
> >> with svn, move to one git repo, move to many git repos).
> >>
> >> Better than saying, "there is no consensus, so let's just go our
separate
> >> ways"...
> >>
> >> -> richard
> >>
> >>
> >>>
> >>> We could still provide a script in the root of svn which checks out
the
> >>> moved projects from git and gives the same experience :)
> >>>
> >>> Carsten
> >>
> >>
>

Re: Git dies of lack of interest?

[Benson Margulies]

https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git

?


On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall  wrote:
> On 12/1/15 13:40 , Carsten Ziegeler wrote:
>>
>> Richard S. Hall wrote
>>>
>>> Well, the argument to the contrary is perhaps that is makes it more
>>> difficult for us as a community to have oversight into releases. It
>>> almost assures us that some/many community members will never checkout
>>> subprojects that aren't in the repository they normally work. Granted,
>>> there is no guarantee of this now, since I can just check out what I
>>> want anyway...but at least it is fairly easy for me to do so now and it
>>> becomes more difficult if everyone spreads to their own repos.
>>>
>>> So, in that regard, I'm more aligned with Marcel...all or nothing makes
>>> more sense.
>>
>> Hmm, ok fair point - however, the *all* is the problematic part where we
>> couldn't agree on last time (one git repo vs many git repos).
>
>
> But isn't it then incumbent on those wanting such changes to convince us one
> way or the other?
>
> Personally, I'd rather just have one big git repo if we are going to switch,
> if for no other reason than it seems like less overhead. However, I admit to
> not really knowing the advantages/disadvantages.
>
> Regardless, at a minimum, perhaps someone should create a documented
> pros/cons list for the approaches. This would at least give us a way to call
> a vote where we can feel somewhat informed about the choices (i.e., stay
> with svn, move to one git repo, move to many git repos).
>
> Better than saying, "there is no consensus, so let's just go our separate
> ways"...
>
> -> richard
>
>
>>
>> We could still provide a script in the root of svn which checks out the
>> moved projects from git and gives the same experience :)
>>
>> Carsten
>
>

Re: Git dies of lack of interest?

[Benson Margulies]

On Tue, Dec 1, 2015 at 7:50 PM, David Jencks  wrote:
> I also see no way to edit your page, and I have no idea who might be a 
> confluence space administrator who could change permissions.
>
> I was going to add to the pro-single-git-repo the point that you can check 
> out exactly the parts you want using git sparse-checkout.
>
> I don’t think the decision to move to git can be made independent of choice 
> of a git workflow.  I’m strongly in favor of triangular workflow.

Presumably, when it's morning in Europe, someone will turn up who
knows how to admin bimargul...@gmail.com into the Felix space. If not,
I'll open an Infra ticket.

meanwhile, can't you all at least put things into comments on the bottom?

(I can't see a way to give other people edit permission to my 'personal space').



>
> thanks
> david jencks
>
>> On Dec 1, 2015, at 4:14 PM, Benson Margulies  wrote:
>>
>> On Dec 1, 2015 6:43 PM, "Richard S. Hall"  wrote:
>>>
>>>
 On Dec 1, 2015, at 17:50, Benson Margulies 
>> wrote:


>> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git

 ?
>>>
>>> Seems like a good start, although is that editable by others?
>>
>> I don't know. Try? I don't have perms to make a page on the Felix wiki , if
>> I get some I will move it.
>>
>>>
>>> It seems like other technical issues were raised about the approaches, so
>> it would be nice to see those added in there by people who have experience.
>>>
>>> I admit, for me, SCM is a necessary evil and not something I get too
>> exited about. I haven’t seen anything to prefer git over svn or vice versa.
>> They’re just different hammers for the same nail.
>>>
>>> Still, thinking about the options, it seems like multiple repos creates a
>> maintenance headache to some degree. For example, line-ending handling is
>> fairly difficult to get configured correctly in git. By having multiple
>> repositories, then every repository would have to have this configured
>> individually, since stuff like that is good to have configured uniformly.
>> Any changes to how we want things uniformly handled would require manual
>> propagation of configuration. Of course, this seems like it would be an
>> issue in any proliferation of repositories (svn or git).
>>>
>>> Or perhaps there is a better way to handle such issues?
>>>
>>> -> richard
>>>


 On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall 
>> wrote:
> On 12/1/15 13:40 , Carsten Ziegeler wrote:
>>
>> Richard S. Hall wrote
>>>
>>> Well, the argument to the contrary is perhaps that is makes it more
>>> difficult for us as a community to have oversight into releases. It
>>> almost assures us that some/many community members will never
>> checkout
>>> subprojects that aren't in the repository they normally work.
>> Granted,
>>> there is no guarantee of this now, since I can just check out what I
>>> want anyway...but at least it is fairly easy for me to do so now and
>> it
>>> becomes more difficult if everyone spreads to their own repos.
>>>
>>> So, in that regard, I'm more aligned with Marcel...all or nothing
>> makes
>>> more sense.
>>
>> Hmm, ok fair point - however, the *all* is the problematic part where
>> we
>> couldn't agree on last time (one git repo vs many git repos).
>
>
> But isn't it then incumbent on those wanting such changes to convince
>> us one
> way or the other?
>
> Personally, I'd rather just have one big git repo if we are going to
>> switch,
> if for no other reason than it seems like less overhead. However, I
>> admit to
> not really knowing the advantages/disadvantages.
>
> Regardless, at a minimum, perhaps someone should create a documented
> pros/cons list for the approaches. This would at least give us a way
>> to call
> a vote where we can feel somewhat informed about the choices (i.e.,
>> stay
> with svn, move to one git repo, move to many git repos).
>
> Better than saying, "there is no consensus, so let's just go our
>> separate
> ways"...
>
> -> richard
>
>
>>
>> We could still provide a script in the root of svn which checks out
>> the
>> moved projects from git and gives the same experience :)
>>
>> Carsten
>
>
>>>
>

Re: Git dies of lack of interest?

[David Jencks]

I also see no way to edit your page, and I have no idea who might be a 
confluence space administrator who could change permissions.

I was going to add to the pro-single-git-repo the point that you can check out 
exactly the parts you want using git sparse-checkout.

I don’t think the decision to move to git can be made independent of choice of 
a git workflow.  I’m strongly in favor of triangular workflow.

thanks
david jencks

> On Dec 1, 2015, at 4:14 PM, Benson Margulies  wrote:
> 
> On Dec 1, 2015 6:43 PM, "Richard S. Hall"  wrote:
>> 
>> 
>>> On Dec 1, 2015, at 17:50, Benson Margulies 
> wrote:
>>> 
>>> 
> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
>>> 
>>> ?
>> 
>> Seems like a good start, although is that editable by others?
> 
> I don't know. Try? I don't have perms to make a page on the Felix wiki , if
> I get some I will move it.
> 
>> 
>> It seems like other technical issues were raised about the approaches, so
> it would be nice to see those added in there by people who have experience.
>> 
>> I admit, for me, SCM is a necessary evil and not something I get too
> exited about. I haven’t seen anything to prefer git over svn or vice versa.
> They’re just different hammers for the same nail.
>> 
>> Still, thinking about the options, it seems like multiple repos creates a
> maintenance headache to some degree. For example, line-ending handling is
> fairly difficult to get configured correctly in git. By having multiple
> repositories, then every repository would have to have this configured
> individually, since stuff like that is good to have configured uniformly.
> Any changes to how we want things uniformly handled would require manual
> propagation of configuration. Of course, this seems like it would be an
> issue in any proliferation of repositories (svn or git).
>> 
>> Or perhaps there is a better way to handle such issues?
>> 
>> -> richard
>> 
>>> 
>>> 
>>> On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall 
> wrote:
 On 12/1/15 13:40 , Carsten Ziegeler wrote:
> 
> Richard S. Hall wrote
>> 
>> Well, the argument to the contrary is perhaps that is makes it more
>> difficult for us as a community to have oversight into releases. It
>> almost assures us that some/many community members will never
> checkout
>> subprojects that aren't in the repository they normally work.
> Granted,
>> there is no guarantee of this now, since I can just check out what I
>> want anyway...but at least it is fairly easy for me to do so now and
> it
>> becomes more difficult if everyone spreads to their own repos.
>> 
>> So, in that regard, I'm more aligned with Marcel...all or nothing
> makes
>> more sense.
> 
> Hmm, ok fair point - however, the *all* is the problematic part where
> we
> couldn't agree on last time (one git repo vs many git repos).
 
 
 But isn't it then incumbent on those wanting such changes to convince
> us one
 way or the other?
 
 Personally, I'd rather just have one big git repo if we are going to
> switch,
 if for no other reason than it seems like less overhead. However, I
> admit to
 not really knowing the advantages/disadvantages.
 
 Regardless, at a minimum, perhaps someone should create a documented
 pros/cons list for the approaches. This would at least give us a way
> to call
 a vote where we can feel somewhat informed about the choices (i.e.,
> stay
 with svn, move to one git repo, move to many git repos).
 
 Better than saying, "there is no consensus, so let's just go our
> separate
 ways"...
 
 -> richard
 
 
> 
> We could still provide a script in the root of svn which checks out
> the
> moved projects from git and gives the same experience :)
> 
> Carsten
 
 
>> 

Re: Git dies of lack of interest?

[Benson Margulies]

I believe that everyone in the felix-users confluence group now has
access to edit pages in my 'personal space'.

On Tue, Dec 1, 2015 at 9:49 PM, Benson Margulies  wrote:
> On Tue, Dec 1, 2015 at 7:50 PM, David Jencks  wrote:
>> I also see no way to edit your page, and I have no idea who might be a 
>> confluence space administrator who could change permissions.
>>
>> I was going to add to the pro-single-git-repo the point that you can check 
>> out exactly the parts you want using git sparse-checkout.
>>
>> I don’t think the decision to move to git can be made independent of choice 
>> of a git workflow.  I’m strongly in favor of triangular workflow.
>
> Presumably, when it's morning in Europe, someone will turn up who
> knows how to admin bimargul...@gmail.com into the Felix space. If not,
> I'll open an Infra ticket.
>
> meanwhile, can't you all at least put things into comments on the bottom?
>
> (I can't see a way to give other people edit permission to my 'personal 
> space').
>
>
>
>>
>> thanks
>> david jencks
>>
>>> On Dec 1, 2015, at 4:14 PM, Benson Margulies  wrote:
>>>
>>> On Dec 1, 2015 6:43 PM, "Richard S. Hall"  wrote:


> On Dec 1, 2015, at 17:50, Benson Margulies 
>>> wrote:
>
>
>>> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
>
> ?

 Seems like a good start, although is that editable by others?
>>>
>>> I don't know. Try? I don't have perms to make a page on the Felix wiki , if
>>> I get some I will move it.
>>>

 It seems like other technical issues were raised about the approaches, so
>>> it would be nice to see those added in there by people who have experience.

 I admit, for me, SCM is a necessary evil and not something I get too
>>> exited about. I haven’t seen anything to prefer git over svn or vice versa.
>>> They’re just different hammers for the same nail.

 Still, thinking about the options, it seems like multiple repos creates a
>>> maintenance headache to some degree. For example, line-ending handling is
>>> fairly difficult to get configured correctly in git. By having multiple
>>> repositories, then every repository would have to have this configured
>>> individually, since stuff like that is good to have configured uniformly.
>>> Any changes to how we want things uniformly handled would require manual
>>> propagation of configuration. Of course, this seems like it would be an
>>> issue in any proliferation of repositories (svn or git).

 Or perhaps there is a better way to handle such issues?

 -> richard

>
>
> On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall 
>>> wrote:
>> On 12/1/15 13:40 , Carsten Ziegeler wrote:
>>>
>>> Richard S. Hall wrote

 Well, the argument to the contrary is perhaps that is makes it more
 difficult for us as a community to have oversight into releases. It
 almost assures us that some/many community members will never
>>> checkout
 subprojects that aren't in the repository they normally work.
>>> Granted,
 there is no guarantee of this now, since I can just check out what I
 want anyway...but at least it is fairly easy for me to do so now and
>>> it
 becomes more difficult if everyone spreads to their own repos.

 So, in that regard, I'm more aligned with Marcel...all or nothing
>>> makes
 more sense.
>>>
>>> Hmm, ok fair point - however, the *all* is the problematic part where
>>> we
>>> couldn't agree on last time (one git repo vs many git repos).
>>
>>
>> But isn't it then incumbent on those wanting such changes to convince
>>> us one
>> way or the other?
>>
>> Personally, I'd rather just have one big git repo if we are going to
>>> switch,
>> if for no other reason than it seems like less overhead. However, I
>>> admit to
>> not really knowing the advantages/disadvantages.
>>
>> Regardless, at a minimum, perhaps someone should create a documented
>> pros/cons list for the approaches. This would at least give us a way
>>> to call
>> a vote where we can feel somewhat informed about the choices (i.e.,
>>> stay
>> with svn, move to one git repo, move to many git repos).
>>
>> Better than saying, "there is no consensus, so let's just go our
>>> separate
>> ways"...
>>
>> -> richard
>>
>>
>>>
>>> We could still provide a script in the root of svn which checks out
>>> the
>>> moved projects from git and gives the same experience :)
>>>
>>> Carsten
>>
>>

>>

Re: Git dies of lack of interest?

[Nick Baker]

We at Pentaho made the migration to Git and GitHub from Subversion and
Perforce a few years ago now. At the time we decided to go with multiple
repositories (we're at around 100 right now). In retrospect this was a
large mistake.

Development often spans multiple repositories creating dependent changes
and corresponding pull-requests -a lot of churn on our CI systems.
Branching, tagging, version updates, reformatting are all made more
complicated. Our build teams have scripts to help with this, but it puts a
lot of these tasks out of the range of our single contributors.

We've tried to group together related Projects into the same repository,
but relationships often change between projects. We explored Submodules to
try to provide a unified repository "view", but this was an imperfect
solution.

And there's the confusion from the community and partners about what to
clone, what order to build it in, etc.

Go with a single large repo IMO. It's very easy to view changes affecting
only a particular subdirectory, cutting-down on the history noise.
Similarly the CI SCM plugins are all able to detect which jobs a new commit
affects so a single commit doesn't trigger all jobs to build.

Regards,
-Nick Baker

On Tue, Dec 1, 2015 at 6:41 PM, Richard S. Hall 
wrote:

>
> > On Dec 1, 2015, at 17:50, Benson Margulies 
> wrote:
> >
> >
> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git
> >
> > ?
>
> Seems like a good start, although is that editable by others?
>
> It seems like other technical issues were raised about the approaches, so
> it would be nice to see those added in there by people who have experience.
>
> I admit, for me, SCM is a necessary evil and not something I get too
> exited about. I haven’t seen anything to prefer git over svn or vice versa.
> They’re just different hammers for the same nail.
>
> Still, thinking about the options, it seems like multiple repos creates a
> maintenance headache to some degree. For example, line-ending handling is
> fairly difficult to get configured correctly in git. By having multiple
> repositories, then every repository would have to have this configured
> individually, since stuff like that is good to have configured uniformly.
> Any changes to how we want things uniformly handled would require manual
> propagation of configuration. Of course, this seems like it would be an
> issue in any proliferation of repositories (svn or git).
>
> Or perhaps there is a better way to handle such issues?
>
> -> richard
>
> >
> >
> > On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall 
> wrote:
> >> On 12/1/15 13:40 , Carsten Ziegeler wrote:
> >>>
> >>> Richard S. Hall wrote
> 
>  Well, the argument to the contrary is perhaps that is makes it more
>  difficult for us as a community to have oversight into releases. It
>  almost assures us that some/many community members will never checkout
>  subprojects that aren't in the repository they normally work. Granted,
>  there is no guarantee of this now, since I can just check out what I
>  want anyway...but at least it is fairly easy for me to do so now and
> it
>  becomes more difficult if everyone spreads to their own repos.
> 
>  So, in that regard, I'm more aligned with Marcel...all or nothing
> makes
>  more sense.
> >>>
> >>> Hmm, ok fair point - however, the *all* is the problematic part where
> we
> >>> couldn't agree on last time (one git repo vs many git repos).
> >>
> >>
> >> But isn't it then incumbent on those wanting such changes to convince
> us one
> >> way or the other?
> >>
> >> Personally, I'd rather just have one big git repo if we are going to
> switch,
> >> if for no other reason than it seems like less overhead. However, I
> admit to
> >> not really knowing the advantages/disadvantages.
> >>
> >> Regardless, at a minimum, perhaps someone should create a documented
> >> pros/cons list for the approaches. This would at least give us a way to
> call
> >> a vote where we can feel somewhat informed about the choices (i.e., stay
> >> with svn, move to one git repo, move to many git repos).
> >>
> >> Better than saying, "there is no consensus, so let's just go our
> separate
> >> ways"...
> >>
> >> -> richard
> >>
> >>
> >>>
> >>> We could still provide a script in the root of svn which checks out the
> >>> moved projects from git and gives the same experience :)
> >>>
> >>> Carsten
> >>
> >>
>
>

Re: Git dies of lack of interest?

[Marcel Offermans]

Hello Benson,

There is, at least, substantial apathy about git on the part of the 
sub-communities that work on some of the sub-projects. In my view, 
this apathy, including perhaps a bit of antipathy, sunk the discussion 
of just converting as one big repo. As I see it, Felix is a bit of a 
loose confederation, and Ray's suggestion is consistent with letting 
each of the tribes make up its own mind. 
I am not sure if the apathy is related to converting as one big repository.

Let me speak for myself here, I don’t see compelling arguments for moving to 
Git. What problem are we solving here? Why is moving to Git the right solution? 
That’s where my lack of enthusiasm comes from. Nobody has yet explained that to 
me. And splitting the project so each subproject ends up in a different 
repository sounds even less appealing to me (which I am afraid will happen if 
we just start moving one, or a few, subprojects). I would be in favour of a 
plan where we either move every subproject, or none at all. And before we start 
the move, please come up with a plan that outlines the steps that need to be 
taken. Maybe even physically do the migration and demonstrate that things like 
our release processes are still working. And yes, that is a lot of work, and 
enough people need to step up and offer their help.

Greetings, Marcel

Fwd: Git dies of lack of interest?

[Benson Margulies]

On Tue, Dec 1, 2015 at 11:43 AM, Marcel Offermans
 wrote:
> Hello Benson,
>
> There is, at least, substantial apathy about git on the part of the
> sub-communities that work on some of the sub-projects. In my view,
> this apathy, including perhaps a bit of antipathy, sunk the discussion
> of just converting as one big repo. As I see it, Felix is a bit of a
> loose confederation, and Ray's suggestion is consistent with letting
> each of the tribes make up its own mind.
>
> I am not sure if the apathy is related to converting as one big repository.

That's not what I was trying to express. There are some people who,
like you, are not enthusiasts. (I'm not interested in trying to
convince anyone else that git is 'better'. I will only write that git
is becoming very popular, and, as a result, it can facilitate
community growth to use it.)

Thus, if you ask the question, 'should we move the whole Felix tree to
git?', it could be that there are enough non-enthusiasts to block
consensus. That is my proposed explanation for the death of the
previous thread. And maybe it should just stay dead. If the community
has no consensus to move to git, it stays in svn.

Ray's proposal looks at another perspective, which is that Felix is
composed of a set of rather loosely-coupled pieces. If the predominant
contributors to some of those pieces want them in git, why not? (I
appreciate that Marcel's view is an answer to the question 'why not!')
I offer as an analogy, 'some things build with Maven, some with
Gradle.' Since we don't release the entire tree at once, I don't why
the choice of VCS needs to be any more uniform than the choice of
build tool.

However, I didn't reopen this question today to fill everyone's
mailbox. I'd like to maintain the bundle plugin in git. But I'm not
going to stomp off in a huff if doesn't happen.

I'd be happy to see a vote to move just the bundle plugin, and I'll
live with the outcome either way. Same for a vote to proceed with the
whole project.

But if the right thing to do is ... nothing ... then nothing it is.





>
> Let me speak for myself here, I don’t see compelling arguments for moving to
> Git. What problem are we solving here? Why is moving to Git the right
> solution? That’s where my lack of enthusiasm comes from. Nobody has yet
> explained that to me. And splitting the project so each subproject ends up
> in a different repository sounds even less appealing to me (which I am
> afraid will happen if we just start moving one, or a few, subprojects). I
> would be in favour of a plan where we either move every subproject, or none
> at all. And before we start the move, please come up with a plan that
> outlines the steps that need to be taken. Maybe even physically do the
> migration and demonstrate that things like our release processes are still
> working. And yes, that is a lot of work, and enough people need to step up
> and offer their help.
>
> Greetings, Marcel
>
>

Re: Git dies of lack of interest?

[Carsten Ziegeler]

Marcel Offermans wrote

> 
> Let me speak for myself here, I don’t see compelling arguments for moving to 
> Git. What problem are we solving here? Why is moving to Git the right 
> solution? 
> That’s where my lack of enthusiasm comes from. Nobody has yet explained that 
> to me. And splitting the project so each subproject ends up in a different 
> repository 
> sounds even less appealing to me (which I am afraid will happen if we
just start moving one, or a few, subprojects). I would be in favour of a
plan where we
> either move every subproject, or none at all. And before we start the
move, please come up with a plan that outlines the steps that need to be
taken.
> Maybe even physically do the migration and demonstrate that things
like our release processes are still working. And yes, that is a lot of
work,
> and enough people need to step up and offer their help.
>
I don't see compelling arguments to move to git either, however it seems
that some here prefer it. Therefore I put it in the same category as
other tools, some of us prefer or use Maven others bndtools - and we
support/allow both. And yes, this is already a problem for our users as
they have to know different tools to build different projects from
source - might not sound like a big issue, but still. Using different
SCMs for different sub projects will not make it easier for our users.
But maybe not really harder either. We have lots of reports were people
checkout the whole Felix source tree and try to build all projects from
the root, just because they are interested in a single project.
Splitting up will at least help here :)

Or to make the long story short, if some people their sub project
benefits from moving to git, I don't see a good enough argument to
prevent them from doing so. Otherwise we would need to agree on all
tools - which would be a fun exercise :)

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Git dies of lack of interest?

[Richard S. Hall]

On 12/1/15 12:57 , Carsten Ziegeler wrote:

Marcel Offermans wrote


Let me speak for myself here, I don’t see compelling arguments for moving to 
Git. What problem are we solving here? Why is moving to Git the right solution?
That’s where my lack of enthusiasm comes from. Nobody has yet explained that to 
me. And splitting the project so each subproject ends up in a different 
repository
sounds even less appealing to me (which I am afraid will happen if we

just start moving one, or a few, subprojects). I would be in favour of a
plan where we

either move every subproject, or none at all. And before we start the

move, please come up with a plan that outlines the steps that need to be
taken.

Maybe even physically do the migration and demonstrate that things

like our release processes are still working. And yes, that is a lot of
work,

and enough people need to step up and offer their help.


I don't see compelling arguments to move to git either, however it seems
that some here prefer it. Therefore I put it in the same category as
other tools, some of us prefer or use Maven others bndtools - and we
support/allow both. And yes, this is already a problem for our users as
they have to know different tools to build different projects from
source - might not sound like a big issue, but still. Using different
SCMs for different sub projects will not make it easier for our users.
But maybe not really harder either. We have lots of reports were people
checkout the whole Felix source tree and try to build all projects from
the root, just because they are interested in a single project.
Splitting up will at least help here :)

Or to make the long story short, if some people their sub project
benefits from moving to git, I don't see a good enough argument to
prevent them from doing so.


Well, the argument to the contrary is perhaps that is makes it more 
difficult for us as a community to have oversight into releases. It 
almost assures us that some/many community members will never checkout 
subprojects that aren't in the repository they normally work. Granted, 
there is no guarantee of this now, since I can just check out what I 
want anyway...but at least it is fairly easy for me to do so now and it 
becomes more difficult if everyone spreads to their own repos.


So, in that regard, I'm more aligned with Marcel...all or nothing makes 
more sense.


-> richard


  Otherwise we would need to agree on all
tools - which would be a fun exercise :)

Regards
Carsten

Re: Git dies of lack of interest?

[Richard S. Hall]

On 12/1/15 13:40 , Carsten Ziegeler wrote:

Richard S. Hall wrote

Well, the argument to the contrary is perhaps that is makes it more
difficult for us as a community to have oversight into releases. It
almost assures us that some/many community members will never checkout
subprojects that aren't in the repository they normally work. Granted,
there is no guarantee of this now, since I can just check out what I
want anyway...but at least it is fairly easy for me to do so now and it
becomes more difficult if everyone spreads to their own repos.

So, in that regard, I'm more aligned with Marcel...all or nothing makes
more sense.

Hmm, ok fair point - however, the *all* is the problematic part where we
couldn't agree on last time (one git repo vs many git repos).


But isn't it then incumbent on those wanting such changes to convince us 
one way or the other?


Personally, I'd rather just have one big git repo if we are going to 
switch, if for no other reason than it seems like less overhead. 
However, I admit to not really knowing the advantages/disadvantages.


Regardless, at a minimum, perhaps someone should create a documented 
pros/cons list for the approaches. This would at least give us a way to 
call a vote where we can feel somewhat informed about the choices (i.e., 
stay with svn, move to one git repo, move to many git repos).


Better than saying, "there is no consensus, so let's just go our 
separate ways"...


-> richard



We could still provide a script in the root of svn which checks out the
moved projects from git and gives the same experience :)

Carsten

[jira] [Created] (FELIX-5125) NPE in ConfigInstaller

[Alexandre Roman (JIRA)]

Alexandre Roman created FELIX-5125:
--

 Summary: NPE in ConfigInstaller
 Key: FELIX-5125
 URL: https://issues.apache.org/jira/browse/FELIX-5125
 Project: Felix
  Issue Type: Bug
  Components: File Install
Affects Versions: fileinstall-3.5.0
Reporter: Alexandre Roman


Configuration values returned by getProperties may be null if the method update 
was not called (according to OSGi specs).

There is a NPE in ConfigInstaller line 106.
I got this error while testing my application with subsystems (after a bundle 
refresh).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5124) maven-bundle-plugin interferes with installAtEnd setting of maven-install-bundle

[Oliver Heger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved FELIX-5124.
-
Resolution: Invalid

In the mean time I did some more tests and found other plug-ins and scenarios 
which cause problems with the install plug-in. So I don't think that this is an 
issue of the bundle plug-in.

Closing as invalid, sorry for the noise.

> maven-bundle-plugin interferes with installAtEnd setting of 
> maven-install-bundle
> 
>
> Key: FELIX-5124
> URL: https://issues.apache.org/jira/browse/FELIX-5124
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Reporter: Oliver Heger
> Attachments: install_test.zip
>
>
> The maven-install-plugin supports the _installAtEnd_ setting which differs 
> the installation of artifacts in a multi-module build to the very end; the 
> installation happens only if the whole build is successful (see 
> https://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#installAtEnd).
> We wanted to use this feature in our project, but found out that even for 
> successful builds the installation never happend. After each module a message 
> was printed "Installing :: at end", but at the 
> end of the build no installation was performed.
> Investigating this problem showed a relation to the maven-bundle-plugin (in 
> its latest version 3.0.1): If the maven-bundle-plugin is declared in the 
> top-level pom, installation works as expected. However, if the declaration is 
> moved to a sub-module, the installation is skipped.
> I have created a sample maven project demonstrating the issue. The project 
> consists of the top-level pom, a modules pom and two sub-modules for the API 
> and the implementation of a dummy service. The maven-bundle-plugin 
> declaration is commented out in the top-level pom; it is also declared in the 
> modules pom. In this form, when building the project with {{mvn clean 
> install}} the project artifacts are not installed. When the comments are 
> removed to enable the declaration the installation takes place. I hope this 
> helps to reproduce and further anylize the problem.
> I was not sure whether this is the correct place to report this problem 
> because the maven-install-plugin is affected as well. However, the install 
> plugin works well in normal scenarios. The maven-deploy-plugin has a similar 
> setting (_deployAtEnd_), and it is affected by this issue, too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Git dies of lack of interest?

[Benson Margulies]

I will write a VOTE thread with a description.



On Tue, Dec 1, 2015 at 10:12 AM, Carsten Ziegeler  wrote:
> Benson Margulies wrote
>> I would like to peel the bundle plugin. Does any pmc member sympathize
>> sufficiently to start a vote to test consensus to do that?
>
> I don't want to be a PITA, but would you care about writing a more
> detailed description of what that would mean? (git repo name, how it is
> set up) I'm actually not sure what it would need as a description but
> definitely a little bit more than just saying "move to git" :)
>
> I wouldn't mind starting a vote based on that - unless someone signals
> that this is a stupid idea :)
>
> Carsten
>
>>
>> On Dec 1, 2015 9:38 AM, "Raymond Auge" > > wrote:
>>
>> U ok.. let me see if I can belatedly recapture the brilliance..
>>
>> I think it was simply the observation that if the end result was to have
>> many repos, couldn't each subproject just start pealing itself off
>> into a
>> git repo as it sees fit?
>>
>> Call it lazy migration if you will.
>>
>> The side effects are going to be limited to those sub projects as
>> they are
>> in transition. But the bulk of main project can safely continue to
>> work in
>> the meantime.
>>
>> That's the entire anti-climactic idea.
>>
>> - Ray
>> On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" > > wrote:
>>
>> > Benson Margulies wrote
>> > > It sure seems as if there are no PMC members fond enough of the git
>> > > idea to call a vote. I'm treating this as a dead topic for now.
>> > >
>> > Looks like :(
>> >
>> > I had a brief discussion two weeks ago with Ray, and he had an
>> > interesting idea. @Ray do you want to bring it up?
>> >
>> > Regards
>> > Carsten
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziege...@apache.org 
>> >
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Git dies of lack of interest?

[Carsten Ziegeler]

Benson Margulies wrote
> I would like to peel the bundle plugin. Does any pmc member sympathize
> sufficiently to start a vote to test consensus to do that?

I don't want to be a PITA, but would you care about writing a more
detailed description of what that would mean? (git repo name, how it is
set up) I'm actually not sure what it would need as a description but
definitely a little bit more than just saying "move to git" :)

I wouldn't mind starting a vote based on that - unless someone signals
that this is a stupid idea :)

Carsten

> 
> On Dec 1, 2015 9:38 AM, "Raymond Auge"  > wrote:
> 
> U ok.. let me see if I can belatedly recapture the brilliance..
> 
> I think it was simply the observation that if the end result was to have
> many repos, couldn't each subproject just start pealing itself off
> into a
> git repo as it sees fit?
> 
> Call it lazy migration if you will.
> 
> The side effects are going to be limited to those sub projects as
> they are
> in transition. But the bulk of main project can safely continue to
> work in
> the meantime.
> 
> That's the entire anti-climactic idea.
> 
> - Ray
> On Dec 1, 2015 9:02 AM, "Carsten Ziegeler"  > wrote:
> 
> > Benson Margulies wrote
> > > It sure seems as if there are no PMC members fond enough of the git
> > > idea to call a vote. I'm treating this as a dead topic for now.
> > >
> > Looks like :(
> >
> > I had a brief discussion two weeks ago with Ray, and he had an
> > interesting idea. @Ray do you want to bring it up?
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org 
> >
> 


 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Git dies of lack of interest?

[Benson Margulies]

Here's how I'd call the vote:

This is a vote to move the reference source of the maven-bundle-plugin to git.

To be specific,

- http://git.apache.org/ will list the repository as
'felix-maven-bundle-plugin.git' (because all repo names start with
their project name).
- all existing history will be migrated using svn2git.
- the 'top' of the repo will correspond to
https://svn.apache.org/repos/asf/felix/trunk/tools/maven-bundle-plugin.
- The code will be removed and replaced with a readme.txt in svn on trunk.

On Tue, Dec 1, 2015 at 10:25 AM, Benson Margulies  wrote:
> I will write a VOTE thread with a description.
>
>
>
> On Tue, Dec 1, 2015 at 10:12 AM, Carsten Ziegeler  
> wrote:
>> Benson Margulies wrote
>>> I would like to peel the bundle plugin. Does any pmc member sympathize
>>> sufficiently to start a vote to test consensus to do that?
>>
>> I don't want to be a PITA, but would you care about writing a more
>> detailed description of what that would mean? (git repo name, how it is
>> set up) I'm actually not sure what it would need as a description but
>> definitely a little bit more than just saying "move to git" :)
>>
>> I wouldn't mind starting a vote based on that - unless someone signals
>> that this is a stupid idea :)
>>
>> Carsten
>>
>>>
>>> On Dec 1, 2015 9:38 AM, "Raymond Auge" >> > wrote:
>>>
>>> U ok.. let me see if I can belatedly recapture the brilliance..
>>>
>>> I think it was simply the observation that if the end result was to have
>>> many repos, couldn't each subproject just start pealing itself off
>>> into a
>>> git repo as it sees fit?
>>>
>>> Call it lazy migration if you will.
>>>
>>> The side effects are going to be limited to those sub projects as
>>> they are
>>> in transition. But the bulk of main project can safely continue to
>>> work in
>>> the meantime.
>>>
>>> That's the entire anti-climactic idea.
>>>
>>> - Ray
>>> On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" >> > wrote:
>>>
>>> > Benson Margulies wrote
>>> > > It sure seems as if there are no PMC members fond enough of the git
>>> > > idea to call a vote. I'm treating this as a dead topic for now.
>>> > >
>>> > Looks like :(
>>> >
>>> > I had a brief discussion two weeks ago with Ray, and he had an
>>> > interesting idea. @Ray do you want to bring it up?
>>> >
>>> > Regards
>>> > Carsten
>>> > --
>>> > Carsten Ziegeler
>>> > Adobe Research Switzerland
>>> > cziege...@apache.org 
>>> >
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org

[jira] [Commented] (FELIX-5112) ClassCastException when deploying an OBR Resource already present in the runtime

[David Bosschaert (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033905#comment-15033905
 ] 

David Bosschaert commented on FELIX-5112:
-

An updated pull request has been provided here: 
https://github.com/apache/felix/pull/44

> ClassCastException when deploying an OBR Resource already present in the 
> runtime
> 
>
> Key: FELIX-5112
> URL: https://issues.apache.org/jira/browse/FELIX-5112
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: Stephen Kahmann
>Assignee: David Bosschaert
> Attachments: fix_local_resource_resolver.diff
>
>
> When using OBR to deploy a bundle that is already present in the runtime, 
> there is a ClassCastException:
> {code}
> java.lang.ClassCastException: 
> org.apache.felix.bundlerepository.impl.LazyLocalResourceImpl cannot be cast 
> to org.apache.felix.bundlerepository.impl.LocalResourceImpl
>   at 
> org.apache.felix.bundlerepository.impl.ResolverImpl.findUpdatableLocalResource(ResolverImpl.java:703)
>   at 
> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:569)
>   at 
> org.apache.karaf.obr.command.ObrCommandSupport.doDeploy(ObrCommandSupport.java:168)
>   at 
> org.apache.karaf.obr.command.StartCommand.doExecute(StartCommand.java:38)
>   at 
> org.apache.karaf.obr.command.ObrCommandSupport.execute(ObrCommandSupport.java:58)
>   at 
> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:83)
>   at 
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)
>   at 
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)
>   at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:480)
>   at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:406)
>   at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>   at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:182)
>   at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:119)
>   at 
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:94)
>   at 
> org.apache.karaf.shell.impl.console.HeadlessSessionImpl.execute(HeadlessSessionImpl.java:90)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Git dies of lack of interest?

[David Jencks]

I apologize for losing track of this whole discussion.  I don’t recall seeing a 
convincing to me reason to have, at least initially, more than one git repo.  
Wasn’t there even a new git feature that let you check out only part of a 
project?

However many repos we decide on, I’m in favor of git :-)  With my chronic 
distraction I will wait a bit to see if someone else organizes the vote (thanks 
Carsten).

david jencks

> On Dec 1, 2015, at 7:12 AM, Carsten Ziegeler  wrote:
> 
> Benson Margulies wrote
>> I would like to peel the bundle plugin. Does any pmc member sympathize
>> sufficiently to start a vote to test consensus to do that?
> 
> I don't want to be a PITA, but would you care about writing a more
> detailed description of what that would mean? (git repo name, how it is
> set up) I'm actually not sure what it would need as a description but
> definitely a little bit more than just saying "move to git" :)
> 
> I wouldn't mind starting a vote based on that - unless someone signals
> that this is a stupid idea :)
> 
> Carsten
> 
>> 
>> On Dec 1, 2015 9:38 AM, "Raymond Auge" > > wrote:
>> 
>>U ok.. let me see if I can belatedly recapture the brilliance..
>> 
>>I think it was simply the observation that if the end result was to have
>>many repos, couldn't each subproject just start pealing itself off
>>into a
>>git repo as it sees fit?
>> 
>>Call it lazy migration if you will.
>> 
>>The side effects are going to be limited to those sub projects as
>>they are
>>in transition. But the bulk of main project can safely continue to
>>work in
>>the meantime.
>> 
>>That's the entire anti-climactic idea.
>> 
>>- Ray
>>On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" >> wrote:
>> 
>>> Benson Margulies wrote
 It sure seems as if there are no PMC members fond enough of the git
 idea to call a vote. I'm treating this as a dead topic for now.
 
>>> Looks like :(
>>> 
>>> I had a brief discussion two weeks ago with Ray, and he had an
>>> interesting idea. @Ray do you want to bring it up?
>>> 
>>> Regards
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org 
>>> 
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Git dies of lack of interest?

[Benson Margulies]

It sure seems as if there are no PMC members fond enough of the git
idea to call a vote. I'm treating this as a dead topic for now.

Re: [VOTE] Release Apache Felix JAAS Support 0.0.4

[Pierre De Rop]

+1

regards
/Pierre

On Tue, Dec 1, 2015 at 7:29 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Felix Script Console Plugin 1.0.2

[Jamie G.]

+1 (non-binding)

On Tue, Dec 1, 2015 at 2:59 AM, Carsten Ziegeler  wrote:
> +1
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Git dies of lack of interest?

[Raymond Auge]

U ok.. let me see if I can belatedly recapture the brilliance..

I think it was simply the observation that if the end result was to have
many repos, couldn't each subproject just start pealing itself off into a
git repo as it sees fit?

Call it lazy migration if you will.

The side effects are going to be limited to those sub projects as they are
in transition. But the bulk of main project can safely continue to work in
the meantime.

That's the entire anti-climactic idea.

- Ray
On Dec 1, 2015 9:02 AM, "Carsten Ziegeler"  wrote:

> Benson Margulies wrote
> > It sure seems as if there are no PMC members fond enough of the git
> > idea to call a vote. I'm treating this as a dead topic for now.
> >
> Looks like :(
>
> I had a brief discussion two weeks ago with Ray, and he had an
> interesting idea. @Ray do you want to bring it up?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: Git dies of lack of interest?

[Benson Margulies]

I would like to peel the bundle plugin. Does any pmc member sympathize
sufficiently to start a vote to test consensus to do that?
On Dec 1, 2015 9:38 AM, "Raymond Auge"  wrote:

> U ok.. let me see if I can belatedly recapture the brilliance..
>
> I think it was simply the observation that if the end result was to have
> many repos, couldn't each subproject just start pealing itself off into a
> git repo as it sees fit?
>
> Call it lazy migration if you will.
>
> The side effects are going to be limited to those sub projects as they are
> in transition. But the bulk of main project can safely continue to work in
> the meantime.
>
> That's the entire anti-climactic idea.
>
> - Ray
> On Dec 1, 2015 9:02 AM, "Carsten Ziegeler"  wrote:
>
> > Benson Margulies wrote
> > > It sure seems as if there are no PMC members fond enough of the git
> > > idea to call a vote. I'm treating this as a dead topic for now.
> > >
> > Looks like :(
> >
> > I had a brief discussion two weeks ago with Ray, and he had an
> > interesting idea. @Ray do you want to bring it up?
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >
>

Re: Git dies of lack of interest?

[Carsten Ziegeler]

Benson Margulies wrote
> It sure seems as if there are no PMC members fond enough of the git
> idea to call a vote. I'm treating this as a dead topic for now.
> 
Looks like :(

I had a brief discussion two weeks ago with Ray, and he had an
interesting idea. @Ray do you want to bring it up?

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Git dies of lack of interest?

[Carsten Ziegeler]

David Jencks wrote
> I apologize for losing track of this whole discussion.  I don’t recall seeing 
> a convincing to me reason to have, at least initially, more than one git 
> repo.  Wasn’t there even a new git feature that let you check out only part 
> of a project?
> 
> However many repos we decide on, I’m in favor of git :-)  With my chronic 
> distraction I will wait a bit to see if someone else organizes the vote 
> (thanks Carsten).
> 

With the suggestion from Ray we will move stuff on demand, so if the
bundle plugin wants to move, we create a git repo for it. If later on
SCR wants to move, we create another one. Everyone else is not affected
and we don't have to go through the demotivating work of getting
everything moved on one big step.

Carsten

> david jencks
> 
>> On Dec 1, 2015, at 7:12 AM, Carsten Ziegeler  wrote:
>>
>> Benson Margulies wrote
>>> I would like to peel the bundle plugin. Does any pmc member sympathize
>>> sufficiently to start a vote to test consensus to do that?
>>
>> I don't want to be a PITA, but would you care about writing a more
>> detailed description of what that would mean? (git repo name, how it is
>> set up) I'm actually not sure what it would need as a description but
>> definitely a little bit more than just saying "move to git" :)
>>
>> I wouldn't mind starting a vote based on that - unless someone signals
>> that this is a stupid idea :)
>>
>> Carsten
>>
>>>
>>> On Dec 1, 2015 9:38 AM, "Raymond Auge" >> > wrote:
>>>
>>>U ok.. let me see if I can belatedly recapture the brilliance..
>>>
>>>I think it was simply the observation that if the end result was to have
>>>many repos, couldn't each subproject just start pealing itself off
>>>into a
>>>git repo as it sees fit?
>>>
>>>Call it lazy migration if you will.
>>>
>>>The side effects are going to be limited to those sub projects as
>>>they are
>>>in transition. But the bulk of main project can safely continue to
>>>work in
>>>the meantime.
>>>
>>>That's the entire anti-climactic idea.
>>>
>>>- Ray
>>>On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" >>> wrote:
>>>
 Benson Margulies wrote
> It sure seems as if there are no PMC members fond enough of the git
> idea to call a vote. I'm treating this as a dead topic for now.
>
 Looks like :(

 I had a brief discussion two weeks ago with Ray, and he had an
 interesting idea. @Ray do you want to bring it up?

 Regards
 Carsten
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org 

>>>
>>
>>
>>
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 
> 


 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Git dies of lack of interest?

[Benson Margulies]

David,

There is, at least, substantial apathy about git on the part of the
sub-communities that work on some of the sub-projects. In my view,
this apathy, including perhaps a bit of antipathy, sunk the discussion
of just converting as one big repo. As I see it, Felix is a bit of a
loose confederation, and Ray's suggestion is consistent with letting
each of the tribes make up its own mind.

At least, that's how I read the recent email messages (and lacks of
email messages).

--benson


On Tue, Dec 1, 2015 at 10:20 AM, David Jencks  wrote:
> I apologize for losing track of this whole discussion.  I don’t recall seeing 
> a convincing to me reason to have, at least initially, more than one git 
> repo.  Wasn’t there even a new git feature that let you check out only part 
> of a project?
>
> However many repos we decide on, I’m in favor of git :-)  With my chronic 
> distraction I will wait a bit to see if someone else organizes the vote 
> (thanks Carsten).
>
> david jencks
>
>> On Dec 1, 2015, at 7:12 AM, Carsten Ziegeler  wrote:
>>
>> Benson Margulies wrote
>>> I would like to peel the bundle plugin. Does any pmc member sympathize
>>> sufficiently to start a vote to test consensus to do that?
>>
>> I don't want to be a PITA, but would you care about writing a more
>> detailed description of what that would mean? (git repo name, how it is
>> set up) I'm actually not sure what it would need as a description but
>> definitely a little bit more than just saying "move to git" :)
>>
>> I wouldn't mind starting a vote based on that - unless someone signals
>> that this is a stupid idea :)
>>
>> Carsten
>>
>>>
>>> On Dec 1, 2015 9:38 AM, "Raymond Auge" >> > wrote:
>>>
>>>U ok.. let me see if I can belatedly recapture the brilliance..
>>>
>>>I think it was simply the observation that if the end result was to have
>>>many repos, couldn't each subproject just start pealing itself off
>>>into a
>>>git repo as it sees fit?
>>>
>>>Call it lazy migration if you will.
>>>
>>>The side effects are going to be limited to those sub projects as
>>>they are
>>>in transition. But the bulk of main project can safely continue to
>>>work in
>>>the meantime.
>>>
>>>That's the entire anti-climactic idea.
>>>
>>>- Ray
>>>On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" >>> wrote:
>>>
 Benson Margulies wrote
> It sure seems as if there are no PMC members fond enough of the git
> idea to call a vote. I'm treating this as a dead topic for now.
>
 Looks like :(

 I had a brief discussion two weeks ago with Ray, and he had an
 interesting idea. @Ray do you want to bring it up?

 Regards
 Carsten
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org 

>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>

Re: Git dies of lack of interest?

[Carsten Ziegeler]

Benson Margulies wrote
> Here's how I'd call the vote:
> 
> This is a vote to move the reference source of the maven-bundle-plugin to git.
> 
> To be specific,
> 
> - http://git.apache.org/ will list the repository as
> 'felix-maven-bundle-plugin.git' (because all repo names start with
> their project name).
> - all existing history will be migrated using svn2git.
> - the 'top' of the repo will correspond to
> https://svn.apache.org/repos/asf/felix/trunk/tools/maven-bundle-plugin.
> - The code will be removed and replaced with a readme.txt in svn on trunk.
> 
Sounds good to me, assuming that commit mails are still send out to the
same list as before?
 
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Git dies of lack of interest?

[Benson Margulies]

On Tue, Dec 1, 2015 at 11:16 AM, Carsten Ziegeler  wrote:
> Benson Margulies wrote
>> Here's how I'd call the vote:
>>
>> This is a vote to move the reference source of the maven-bundle-plugin to 
>> git.
>>
>> To be specific,
>>
>> - http://git.apache.org/ will list the repository as
>> 'felix-maven-bundle-plugin.git' (because all repo names start with
>> their project name).
>> - all existing history will be migrated using svn2git.
>> - the 'top' of the repo will correspond to
>> https://svn.apache.org/repos/asf/felix/trunk/tools/maven-bundle-plugin.
>> - The code will be removed and replaced with a readme.txt in svn on trunk.
>>
> Sounds good to me, assuming that commit mails are still send out to the
> same list as before?

Yes, that's the behavior of the Foundation's git infrastructure.

>
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Resolved] (FELIX-4816) bndtools-ify Dependency Manager

[Pierre De Rop (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre De Rop resolved FELIX-4816.
--
   Resolution: Fixed
Fix Version/s: org.apache.felix.dependencymanager-r1

forgot to close this issue, which was already resolved in R1 release.

> bndtools-ify Dependency Manager
> ---
>
> Key: FELIX-4816
> URL: https://issues.apache.org/jira/browse/FELIX-4816
> Project: Felix
>  Issue Type: Wish
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Runtime, Dependency Manager Samples, Dependency Manager 
> Shell
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
> Fix For: org.apache.felix.dependencymanager-r1
>
>
> For the new dependency manager version, we have made the choice the use 
> bndtools and gradle for building the dependency manager.
> To build DM using gradle:
> * If necessary, configure your https proxy settings: 
> export GRADLE_OPTS="-Dhttps.proxyHost=www.somehost.org -Dhttps.proxyPort=8080"
> * Install java7
> * Compile Dependendency Manager (you must compile annotations first):
> ** ./gradlew org.apache.felix.dependencymanager.annotation:jar
> ** ./gradlew jar
> ** ./gradle test   (to run junit tests)
> ** ./gradle check   (to run integration tests)
> Here is the instructions for building DM within Eclipse/bndTools:
> * Install Jdk7 and Jdk8 (Java8 is only required to compile and run the DM 
> benchmark tool)
> * In Eclipse, configure two JREs for both java7 and java8:
> ** go to Windows -> Preferences -> Java -> Installed JREs
> ** Then add two JREs: one for java7, and the other for java8
> ** Declare the java7 JRE as the default one
> * Install BndTools 2.4.1, and a subversion plugin for Eclipse
> * Open BndTools perspective
> * Import Dependency Manager into Eclipse, and compile everything. if it's the 
> first time you import the project into eclipse, it may happen that some 
> modules that requires the Dependency Manager Annotations bnd plugin don't 
> compile: It's a know issue. To work around, restart eclipse and 
> rebuild every modules. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)