git?

[Benson Margulies <be...@basistech.com>]

There was some discussion a while back about git, which I recall
(perhaps inaccurately) as vaguely positive. It's a lot easier if each
releasable thing gets its own git repo.

How do folks feel about starting with a migration of the bundle plugin?

--benson

Re: git?

[Guillaume Nodet <gn...@apache.org>]

+1


2015-11-02 13:24 GMT+01:00 Marcel Offermans <ma...@luminis.nl>:

> I would be more comfortable if we first had someone volunteer to adapt all
> (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure
> that all projects keep working. Then demonstrate all of that (with a copy
> of our repository), and update our documentation to reflect the new
> processes before we decide on making such a move. I have a feeling this is
> going to be a lot of work and it could break quite a few processes that we
> currently have which is why I don’t think we should “just switch” and then
> try to pick up the broken pieces.
>
> Greetings, Marcel
>
> On 31 October 2015 at 22:01:01 , Oliver Lietz (apache@oliverlietz.de)
> wrote:
>
> On Friday 30 October 2015 06:41:09 Benson Margulies wrote:
> > On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > > Am 30.10.15 um 01:48 schrieb Benson Margulies:
> > >> Is this a consensus to proceed yet? It's been a few days since the
> > >> last contribution.
> > >
> > > We clearly have different opinions, they range from "why change?",
> > > "let's get moving" to "let's do more than a simple conversion".
> > > I don't see a clear consensus/agreement on any of the three. For each
> > > opinion there are imho good/valid arguments. I have the feeling that a
> > > formal vote does not lead us anywhere.
> > >
> > > Maybe someone can clearly identify/list the benefits for everyone if we
> > > move from svn to a single git repo - compared to using the already
> > > existing git proxy. I think this should give everyone a clear view of
> > > why the migration makes sense. And if there are no compelling reasons
> > > then we have a decision as well.
> >
> > I think I can state some advantages:
> >
> >
> > 1: Make it significantly easier to apply patches from people who
> > provide them via github.
> >
> > 2: Make it significantly easier to create branches in the main repo
> > for collaborative changes.
> >
> > 3: Take a first step towards subdividing into multiple repos where
> > that makes sense.
>
> some more:
>
> https://issues.apache.org/jira/browse/SLING-3987
>
> https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git
>
> Is there already a project at Apache which moved from Subversion to Git
> setting up multiple repos or even a repo per release artifact?
>
> Regards,
> O.
>
> > My sense of the email thread is that we have some enthusiastic
> > supporters of moving to git, and some '+0' weak objectors. So, in some
> > models of consensus process, that would be a reason to go ahead. Do
> > you want to recast this as a VOTE as a way of clarifying views?
> >
> > > Carsten
> > > --
> > > Carsten Ziegeler
> > > Adobe Research Switzerland
> > > cziegeler@apache.org
>
>

Re: git?

[Benson Margulies <bi...@gmail.com>]

On Mon, Nov 2, 2015 at 9:55 AM, Pierre De Rop <pi...@gmail.com> wrote:
> Hello Benson;
>
> Currently only DependencyManager is using bndtools and gradle (and IIUC,
> SCR will jump to bndtools soon).
>
> So, I propose that you first do a prototype with only all maven based sub
> project and make also a jira issue that describes all the impacts,
> including any impacts regarding the release process. Then I will look into
> it and will help to see how to adapt DM.

OK. I am to some extent inclined to ask the PMC to reach a consensus,
formally, on whether to do this at all. If the decision is to do it,
then the prototype would be the first task.


>
> However, I think it would be worth to first read the new release process
> used by DM in [1] (we are not using maven or the nexus staging repository
> anymore, we are only simply using svn from the gradle script).
>
> FYI, the gradle script used to generate DM binaries is the one that is
> generated by bndtools. The only specific gradle script we have done is: [2]
> and is only used to make releases. The readme from [3] describes how to
> make DM releases and how to use the script.
>
> [1] https://issues.apache.org/jira/browse/FELIX-4818
> [2]
> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/release/build.gradle
> [3]
> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/release/README.release?view=log
>
>
> cheers;
> /Pierre
>
> On Mon, Nov 2, 2015 at 1:41 PM, Benson Margulies <bi...@gmail.com>
> wrote:
>
>> I am a gradle idiot. Is someone else willing to help or at least give me
>> some pointers?
>> On Nov 2, 2015 7:24 AM, "Marcel Offermans" <ma...@luminis.nl>
>> wrote:
>>
>> > I would be more comfortable if we first had someone volunteer to adapt
>> all
>> > (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure
>> > that all projects keep working. Then demonstrate all of that (with a copy
>> > of our repository), and update our documentation to reflect the new
>> > processes before we decide on making such a move. I have a feeling this
>> is
>> > going to be a lot of work and it could break quite a few processes that
>> we
>> > currently have which is why I don’t think we should “just switch” and
>> then
>> > try to pick up the broken pieces.
>> >
>> > Greetings, Marcel
>> >
>> > On 31 October 2015 at 22:01:01 , Oliver Lietz (apache@oliverlietz.de)
>> > wrote:
>> >
>> > On Friday 30 October 2015 06:41:09 Benson Margulies wrote:
>> > > On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <
>> cziegeler@apache.org>
>> > wrote:
>> > > > Am 30.10.15 um 01:48 schrieb Benson Margulies:
>> > > >> Is this a consensus to proceed yet? It's been a few days since the
>> > > >> last contribution.
>> > > >
>> > > > We clearly have different opinions, they range from "why change?",
>> > > > "let's get moving" to "let's do more than a simple conversion".
>> > > > I don't see a clear consensus/agreement on any of the three. For each
>> > > > opinion there are imho good/valid arguments. I have the feeling that
>> a
>> > > > formal vote does not lead us anywhere.
>> > > >
>> > > > Maybe someone can clearly identify/list the benefits for everyone if
>> we
>> > > > move from svn to a single git repo - compared to using the already
>> > > > existing git proxy. I think this should give everyone a clear view of
>> > > > why the migration makes sense. And if there are no compelling reasons
>> > > > then we have a decision as well.
>> > >
>> > > I think I can state some advantages:
>> > >
>> > >
>> > > 1: Make it significantly easier to apply patches from people who
>> > > provide them via github.
>> > >
>> > > 2: Make it significantly easier to create branches in the main repo
>> > > for collaborative changes.
>> > >
>> > > 3: Take a first step towards subdividing into multiple repos where
>> > > that makes sense.
>> >
>> > some more:
>> >
>> > https://issues.apache.org/jira/browse/SLING-3987
>> >
>> >
>> https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git
>> >
>> > Is there already a project at Apache which moved from Subversion to Git
>> > setting up multiple repos or even a repo per release artifact?
>> >
>> > Regards,
>> > O.
>> >
>> > > My sense of the email thread is that we have some enthusiastic
>> > > supporters of moving to git, and some '+0' weak objectors. So, in some
>> > > models of consensus process, that would be a reason to go ahead. Do
>> > > you want to recast this as a VOTE as a way of clarifying views?
>> > >
>> > > > Carsten
>> > > > --
>> > > > Carsten Ziegeler
>> > > > Adobe Research Switzerland
>> > > > cziegeler@apache.org
>> >
>> >
>>

Re: git?

[Pierre De Rop <pi...@gmail.com>]

Hello Benson;

Currently only DependencyManager is using bndtools and gradle (and IIUC,
SCR will jump to bndtools soon).

So, I propose that you first do a prototype with only all maven based sub
project and make also a jira issue that describes all the impacts,
including any impacts regarding the release process. Then I will look into
it and will help to see how to adapt DM.

However, I think it would be worth to first read the new release process
used by DM in [1] (we are not using maven or the nexus staging repository
anymore, we are only simply using svn from the gradle script).

FYI, the gradle script used to generate DM binaries is the one that is
generated by bndtools. The only specific gradle script we have done is: [2]
and is only used to make releases. The readme from [3] describes how to
make DM releases and how to use the script.

[1] https://issues.apache.org/jira/browse/FELIX-4818
[2]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/release/build.gradle
[3]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/release/README.release?view=log


cheers;
/Pierre

On Mon, Nov 2, 2015 at 1:41 PM, Benson Margulies <bi...@gmail.com>
wrote:

> I am a gradle idiot. Is someone else willing to help or at least give me
> some pointers?
> On Nov 2, 2015 7:24 AM, "Marcel Offermans" <ma...@luminis.nl>
> wrote:
>
> > I would be more comfortable if we first had someone volunteer to adapt
> all
> > (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure
> > that all projects keep working. Then demonstrate all of that (with a copy
> > of our repository), and update our documentation to reflect the new
> > processes before we decide on making such a move. I have a feeling this
> is
> > going to be a lot of work and it could break quite a few processes that
> we
> > currently have which is why I don’t think we should “just switch” and
> then
> > try to pick up the broken pieces.
> >
> > Greetings, Marcel
> >
> > On 31 October 2015 at 22:01:01 , Oliver Lietz (apache@oliverlietz.de)
> > wrote:
> >
> > On Friday 30 October 2015 06:41:09 Benson Margulies wrote:
> > > On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <
> cziegeler@apache.org>
> > wrote:
> > > > Am 30.10.15 um 01:48 schrieb Benson Margulies:
> > > >> Is this a consensus to proceed yet? It's been a few days since the
> > > >> last contribution.
> > > >
> > > > We clearly have different opinions, they range from "why change?",
> > > > "let's get moving" to "let's do more than a simple conversion".
> > > > I don't see a clear consensus/agreement on any of the three. For each
> > > > opinion there are imho good/valid arguments. I have the feeling that
> a
> > > > formal vote does not lead us anywhere.
> > > >
> > > > Maybe someone can clearly identify/list the benefits for everyone if
> we
> > > > move from svn to a single git repo - compared to using the already
> > > > existing git proxy. I think this should give everyone a clear view of
> > > > why the migration makes sense. And if there are no compelling reasons
> > > > then we have a decision as well.
> > >
> > > I think I can state some advantages:
> > >
> > >
> > > 1: Make it significantly easier to apply patches from people who
> > > provide them via github.
> > >
> > > 2: Make it significantly easier to create branches in the main repo
> > > for collaborative changes.
> > >
> > > 3: Take a first step towards subdividing into multiple repos where
> > > that makes sense.
> >
> > some more:
> >
> > https://issues.apache.org/jira/browse/SLING-3987
> >
> >
> https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git
> >
> > Is there already a project at Apache which moved from Subversion to Git
> > setting up multiple repos or even a repo per release artifact?
> >
> > Regards,
> > O.
> >
> > > My sense of the email thread is that we have some enthusiastic
> > > supporters of moving to git, and some '+0' weak objectors. So, in some
> > > models of consensus process, that would be a reason to go ahead. Do
> > > you want to recast this as a VOTE as a way of clarifying views?
> > >
> > > > Carsten
> > > > --
> > > > Carsten Ziegeler
> > > > Adobe Research Switzerland
> > > > cziegeler@apache.org
> >
> >
>

Re: git?

[Benson Margulies <bi...@gmail.com>]

I am a gradle idiot. Is someone else willing to help or at least give me
some pointers?
On Nov 2, 2015 7:24 AM, "Marcel Offermans" <ma...@luminis.nl>
wrote:

> I would be more comfortable if we first had someone volunteer to adapt all
> (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure
> that all projects keep working. Then demonstrate all of that (with a copy
> of our repository), and update our documentation to reflect the new
> processes before we decide on making such a move. I have a feeling this is
> going to be a lot of work and it could break quite a few processes that we
> currently have which is why I don’t think we should “just switch” and then
> try to pick up the broken pieces.
>
> Greetings, Marcel
>
> On 31 October 2015 at 22:01:01 , Oliver Lietz (apache@oliverlietz.de)
> wrote:
>
> On Friday 30 October 2015 06:41:09 Benson Margulies wrote:
> > On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > > Am 30.10.15 um 01:48 schrieb Benson Margulies:
> > >> Is this a consensus to proceed yet? It's been a few days since the
> > >> last contribution.
> > >
> > > We clearly have different opinions, they range from "why change?",
> > > "let's get moving" to "let's do more than a simple conversion".
> > > I don't see a clear consensus/agreement on any of the three. For each
> > > opinion there are imho good/valid arguments. I have the feeling that a
> > > formal vote does not lead us anywhere.
> > >
> > > Maybe someone can clearly identify/list the benefits for everyone if we
> > > move from svn to a single git repo - compared to using the already
> > > existing git proxy. I think this should give everyone a clear view of
> > > why the migration makes sense. And if there are no compelling reasons
> > > then we have a decision as well.
> >
> > I think I can state some advantages:
> >
> >
> > 1: Make it significantly easier to apply patches from people who
> > provide them via github.
> >
> > 2: Make it significantly easier to create branches in the main repo
> > for collaborative changes.
> >
> > 3: Take a first step towards subdividing into multiple repos where
> > that makes sense.
>
> some more:
>
> https://issues.apache.org/jira/browse/SLING-3987
>
> https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git
>
> Is there already a project at Apache which moved from Subversion to Git
> setting up multiple repos or even a repo per release artifact?
>
> Regards,
> O.
>
> > My sense of the email thread is that we have some enthusiastic
> > supporters of moving to git, and some '+0' weak objectors. So, in some
> > models of consensus process, that would be a reason to go ahead. Do
> > you want to recast this as a VOTE as a way of clarifying views?
> >
> > > Carsten
> > > --
> > > Carsten Ziegeler
> > > Adobe Research Switzerland
> > > cziegeler@apache.org
>
>

Re: git?

[Marcel Offermans <ma...@luminis.nl>]

I would be more comfortable if we first had someone volunteer to adapt all (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure that all projects keep working. Then demonstrate all of that (with a copy of our repository), and update our documentation to reflect the new processes before we decide on making such a move. I have a feeling this is going to be a lot of work and it could break quite a few processes that we currently have which is why I don’t think we should “just switch” and then try to pick up the broken pieces.

Greetings, Marcel

On 31 October 2015 at 22:01:01 , Oliver Lietz (apache@oliverlietz.de) wrote:

On Friday 30 October 2015 06:41:09 Benson Margulies wrote:  
> On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <cz...@apache.org>  
wrote:  
> > Am 30.10.15 um 01:48 schrieb Benson Margulies:  
> >> Is this a consensus to proceed yet? It's been a few days since the  
> >> last contribution.  
> >  
> > We clearly have different opinions, they range from "why change?",  
> > "let's get moving" to "let's do more than a simple conversion".  
> > I don't see a clear consensus/agreement on any of the three. For each  
> > opinion there are imho good/valid arguments. I have the feeling that a  
> > formal vote does not lead us anywhere.  
> >  
> > Maybe someone can clearly identify/list the benefits for everyone if we  
> > move from svn to a single git repo - compared to using the already  
> > existing git proxy. I think this should give everyone a clear view of  
> > why the migration makes sense. And if there are no compelling reasons  
> > then we have a decision as well.  
>  
> I think I can state some advantages:  
>  
>  
> 1: Make it significantly easier to apply patches from people who  
> provide them via github.  
>  
> 2: Make it significantly easier to create branches in the main repo  
> for collaborative changes.  
>  
> 3: Take a first step towards subdividing into multiple repos where  
> that makes sense.  

some more:  

https://issues.apache.org/jira/browse/SLING-3987  
https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git  

Is there already a project at Apache which moved from Subversion to Git  
setting up multiple repos or even a repo per release artifact?  

Regards,  
O.  

> My sense of the email thread is that we have some enthusiastic  
> supporters of moving to git, and some '+0' weak objectors. So, in some  
> models of consensus process, that would be a reason to go ahead. Do  
> you want to recast this as a VOTE as a way of clarifying views?  
>  
> > Carsten  
> > --  
> > Carsten Ziegeler  
> > Adobe Research Switzerland  
> > cziegeler@apache.org  

Re: git?

[Oliver Lietz <ap...@oliverlietz.de>]

On Friday 30 October 2015 06:41:09 Benson Margulies wrote:
> On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <cz...@apache.org> 
wrote:
> > Am 30.10.15 um 01:48 schrieb Benson Margulies:
> >> Is this a consensus to proceed yet? It's been a few days since the
> >> last contribution.
> > 
> > We clearly have different opinions, they range from "why change?",
> > "let's get moving" to "let's do more than a simple conversion".
> > I don't see a clear consensus/agreement on any of the three. For each
> > opinion there are imho good/valid arguments. I have the feeling that a
> > formal vote does not lead us anywhere.
> > 
> > Maybe someone can clearly identify/list the benefits for everyone if we
> > move from svn to a single git repo - compared to using the already
> > existing git proxy. I think this should give everyone a clear view of
> > why the migration makes sense. And if there are no compelling reasons
> > then we have a decision as well.
> 
> I think I can state some advantages:
> 
> 
> 1: Make it significantly easier to apply patches from people who
> provide them via github.
> 
> 2: Make it significantly easier to create branches in the main repo
> for collaborative changes.
> 
> 3: Take a first step towards subdividing into multiple repos where
> that makes sense.

some more:

https://issues.apache.org/jira/browse/SLING-3987
https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git

Is there already a project at Apache which moved from Subversion to Git 
setting up multiple repos or even a repo per release artifact?

Regards,
O.

> My sense of the email thread is that we have some enthusiastic
> supporters of moving to git, and some '+0' weak objectors. So, in some
> models of consensus process, that would be a reason to go ahead. Do
> you want to recast this as a VOTE as a way of clarifying views?
> 
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Am 30.10.15 um 11:41 schrieb Benson Margulies:
> On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Am 30.10.15 um 01:48 schrieb Benson Margulies:
>>> Is this a consensus to proceed yet? It's been a few days since the
>>> last contribution.
>>>
>> We clearly have different opinions, they range from "why change?",
>> "let's get moving" to "let's do more than a simple conversion".
>> I don't see a clear consensus/agreement on any of the three. For each
>> opinion there are imho good/valid arguments. I have the feeling that a
>> formal vote does not lead us anywhere.
>>
>> Maybe someone can clearly identify/list the benefits for everyone if we
>> move from svn to a single git repo - compared to using the already
>> existing git proxy. I think this should give everyone a clear view of
>> why the migration makes sense. And if there are no compelling reasons
>> then we have a decision as well.
> 
> I think I can state some advantages:
> 
> 
> 1: Make it significantly easier to apply patches from people who
> provide them via github.

What exactly is the problem here? I have no problem in applying those
patches easily with svn

> 
> 2: Make it significantly easier to create branches in the main repo
> for collaborative changes.

Creating a branch in svn is easy as well (svn cp). I assume you mean the
merging part which is better in git?

> 
> 3: Take a first step towards subdividing into multiple repos where
> that makes sense.

This is only an advantage if we want to go there and I saw more
objection on doing that than on going to git in general.

> My sense of the email thread is that we have some enthusiastic
> supporters of moving to git, and some '+0' weak objectors. So, in some
> models of consensus process, that would be a reason to go ahead. Do
> you want to recast this as a VOTE as a way of clarifying views?
> 

This change has a significant influence on everyone, so lazy consensus
does not apply here.
We need a formal vote which needs to be open for some time to give
everyone a chance. But before starting this, we really should agree that
the above are the advantages and that  there are no disadvantages.

I don't want to block the move, however rushing it through is not a good
idea either and taking some days time to think about it, gives everyone
a chance to voice his opinion.

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

Re: git?

[Benson Margulies <bi...@gmail.com>]

On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Am 30.10.15 um 01:48 schrieb Benson Margulies:
>> Is this a consensus to proceed yet? It's been a few days since the
>> last contribution.
>>
> We clearly have different opinions, they range from "why change?",
> "let's get moving" to "let's do more than a simple conversion".
> I don't see a clear consensus/agreement on any of the three. For each
> opinion there are imho good/valid arguments. I have the feeling that a
> formal vote does not lead us anywhere.
>
> Maybe someone can clearly identify/list the benefits for everyone if we
> move from svn to a single git repo - compared to using the already
> existing git proxy. I think this should give everyone a clear view of
> why the migration makes sense. And if there are no compelling reasons
> then we have a decision as well.

I think I can state some advantages:


1: Make it significantly easier to apply patches from people who
provide them via github.

2: Make it significantly easier to create branches in the main repo
for collaborative changes.

3: Take a first step towards subdividing into multiple repos where
that makes sense.

My sense of the email thread is that we have some enthusiastic
supporters of moving to git, and some '+0' weak objectors. So, in some
models of consensus process, that would be a reason to go ahead. Do
you want to recast this as a VOTE as a way of clarifying views?


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

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Am 30.10.15 um 01:48 schrieb Benson Margulies:
> Is this a consensus to proceed yet? It's been a few days since the
> last contribution.
> 
We clearly have different opinions, they range from "why change?",
"let's get moving" to "let's do more than a simple conversion".
I don't see a clear consensus/agreement on any of the three. For each
opinion there are imho good/valid arguments. I have the feeling that a
formal vote does not lead us anywhere.

Maybe someone can clearly identify/list the benefits for everyone if we
move from svn to a single git repo - compared to using the already
existing git proxy. I think this should give everyone a clear view of
why the migration makes sense. And if there are no compelling reasons
then we have a decision as well.

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

Re: git?

[Benson Margulies <bi...@gmail.com>]

Is this a consensus to proceed yet? It's been a few days since the
last contribution.

On Wed, Oct 28, 2015 at 3:30 AM, Chetan Mehrotra <ch...@apache.org> wrote:
> On Sat, Oct 24, 2015 at 11:50 PM, Marcel Offermans
> <ma...@luminis.nl> wrote:
>> I’m +0 on making a switch because it’s also a lot of work and I don’t think the benefits are huge. If it works, don’t fix it. :)
>
> +1 to that. Side-line for me too.
>
> SVN isn't that bad after all, and along with 'git svn' most of the
> benefits of git (quick local branching/fast commit history etc) can be
> realized locally by developers.
>
> Not that imp but for me at times the linear progressing svn revision
> feels more useful to determine if a particular CL made it to a
> particular released.

Re: git?

[Chetan Mehrotra <ch...@apache.org>]

On Sat, Oct 24, 2015 at 11:50 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> I’m +0 on making a switch because it’s also a lot of work and I don’t think the benefits are huge. If it works, don’t fix it. :)

+1 to that. Side-line for me too.

SVN isn't that bad after all, and along with 'git svn' most of the
benefits of git (quick local branching/fast commit history etc) can be
realized locally by developers.

Not that imp but for me at times the linear progressing svn revision
feels more useful to determine if a particular CL made it to a
particular released.

Re: git?

["Richard S. Hall" <he...@ungoverned.org>]

> On Oct 27, 2015, at 18:06, Simon Chemouil <sc...@gmail.com> wrote:
> 
> Richard S. Hall a écrit le 27/10/2015 21:22 :
>> Simon,
>> 
>> You do realize that in Subversion you can just checkout a given 
>> subproject, create a patch against it, then delete it, right?
> 
> I do. Well I don't want to sound like a fanboy, but Git allows to deal
> with multiple remotes (e.g when maintaining a shared private branch) and
> makes branching and feature patches, rebasing them as upstream evolves,
> much easier and lighter. I used CVS and SVN for years and I feel Git has
> made work easier.

Well, ok, then, but your original arguments about repo size didn’t make much sense then…

-> richard

Re: git?

[Simon Chemouil <sc...@gmail.com>]

Richard S. Hall a écrit le 27/10/2015 21:22 :
> Simon,
> 
> You do realize that in Subversion you can just checkout a given 
> subproject, create a patch against it, then delete it, right?

I do. Well I don't want to sound like a fanboy, but Git allows to deal
with multiple remotes (e.g when maintaining a shared private branch) and
makes branching and feature patches, rebasing them as upstream evolves,
much easier and lighter. I used CVS and SVN for years and I feel Git has
made work easier.

-- 
Simon

Re: git?

["Richard S. Hall" <he...@ungoverned.org>]

Simon,

You do realize that in Subversion you can just checkout a given 
subproject, create a patch against it, then delete it, right?

-> richard

On 10/27/15 15:52 , Simon Chemouil wrote:
> Benson Margulies wrote:
>> There was some discussion a while back about git, which I recall
>> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
>> releasable thing gets its own git repo.
> Hi,
>
> At this point it looks like the switch is going to happen, and there has
> been this argument repeated a few times that the current situation with
> SVN is not broken and that changing will imply significant pain.
>
> It's most likely true :).
>
> However as a user of Felix and its sub-projects, I'd like to state that
> this switch would be very welcome and ease working with Felix and
> contributing patches a lot.
>
> First, the Felix SVN repo is humongous and mixes so many sub-projects
> that it's a pain to navigate through it to get the right ones, the right
> branch, the right commit.
>
> Second, there's the problem of hassle-free contribution: when I
> encounter an issue, I just want to just fork a sub-project, and create a
> pull request and the associated JIRA ticket, and go back to my routine.
> But forking the whole felix project just for a single a component is a
> big overhead, and last time I tried the Felix Git repo on GitHub did not
> look up-to-date. It might not look like it because you guys have your
> environments set up and you spent enough time to do so, but that is an
> artificial entry barrier to contribution (not because it's difficult,
> but because it's so heavy compared to the Git workflow we got used to).
>
> So while this switch might not go as smoothly as hoped, it will also
> benefit users and I believe will help the Felix project get
> contributors, new committers and even maybe new sub-projects, as long as
> there is no new overhead introduced by the way the switch is made :-)
>
> In my experience having one repo per bundle results in the opposite
> overhead (having too many repos to clone, update, etc), and I think
> having one repo per sub-project is the right compromise. That's also
> we've been doing at work for a while (we had one repo per bundle before
> for a long time).
>
> Finally, it would be great not to bump versions for bundles that have
> not changed just to avoid having several releases prefixes handled by
> the maven-release-plugin within the same repository. So I am not
> favourable to systematically making all bundles in a sub-project part of
> the same multi-module Maven project (and thus share bundle version by
> default) for that reason alone.
>
> Although proper package semantic versioning would make this transparent
> at runtime (or 'install' time), it makes it impossible to track releases
> and the evolution of the different bundles, and generally feels against
> OSGi principles' of proper modules and versions.
>
> A big non-binding +1 from me. :)
>

Re: git?

[Simon Chemouil <sc...@gmail.com>]

Benson Margulies wrote:
> There was some discussion a while back about git, which I recall
> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
> releasable thing gets its own git repo.

Hi,

At this point it looks like the switch is going to happen, and there has
been this argument repeated a few times that the current situation with
SVN is not broken and that changing will imply significant pain.

It's most likely true :).

However as a user of Felix and its sub-projects, I'd like to state that
this switch would be very welcome and ease working with Felix and
contributing patches a lot.

First, the Felix SVN repo is humongous and mixes so many sub-projects
that it's a pain to navigate through it to get the right ones, the right
branch, the right commit.

Second, there's the problem of hassle-free contribution: when I
encounter an issue, I just want to just fork a sub-project, and create a
pull request and the associated JIRA ticket, and go back to my routine.
But forking the whole felix project just for a single a component is a
big overhead, and last time I tried the Felix Git repo on GitHub did not
look up-to-date. It might not look like it because you guys have your
environments set up and you spent enough time to do so, but that is an
artificial entry barrier to contribution (not because it's difficult,
but because it's so heavy compared to the Git workflow we got used to).

So while this switch might not go as smoothly as hoped, it will also
benefit users and I believe will help the Felix project get
contributors, new committers and even maybe new sub-projects, as long as
there is no new overhead introduced by the way the switch is made :-)

In my experience having one repo per bundle results in the opposite
overhead (having too many repos to clone, update, etc), and I think
having one repo per sub-project is the right compromise. That's also
we've been doing at work for a while (we had one repo per bundle before
for a long time).

Finally, it would be great not to bump versions for bundles that have
not changed just to avoid having several releases prefixes handled by
the maven-release-plugin within the same repository. So I am not
favourable to systematically making all bundles in a sub-project part of
the same multi-module Maven project (and thus share bundle version by
default) for that reason alone.

Although proper package semantic versioning would make this transparent
at runtime (or 'install' time), it makes it impossible to track releases
and the evolution of the different bundles, and generally feels against
OSGi principles' of proper modules and versions.

A big non-binding +1 from me. :)

-- 
Simon Chemouil

RE: git?

[Stefan Seifert <ss...@pro-vision.de>]

i'm for a move to git as well.

concerning the options listed by carsten:

"b) create git repos by functional modules" makes sense if all modules belonging to a "function" are released together, this is not everywhere the case currently. if we release them independently we violate the git branch/tag concept which unlike svn cannot branch/tag on subtrees, only the whole repo. we should make this clear when listing the options, e.g.

b1) create git repos by functional modules (release projects independently)
b2) create git repos by functional modules (release them all together)


my favorite options are b2) and c)


i advice against a), we had done this with our own multi-module open source projects at http://wcm.io and moved away from it to b1) and are still not fully happy with it. but in no way we want to go back to svn. 

btw. the same discussion pop ups from time to time on the sling mailing list, oliver lietz has put together some information and points to consider at [1]

stefan

[1] https://cwiki.apache.org/confluence/x/8ZLHAg


>-----Original Message-----
>From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>Sent: Tuesday, October 27, 2015 1:46 PM
>To: dev@felix.apache.org
>Subject: Re: git?
>
>Looking at this thread, there seems to be no one really against moving
>to git.
>
>When it comes to moving, we have three options:
>
>a) create a single git repo
>b) create git repos by functional modules
>c) create a git repo for every artifact
>
>Depending on which variant we pick, the more work it is to get
>everything moved. Therefore apart from deciding for the option it
>depends on a volunteer to drive this thing.
>
>I'm unsure on how we come to a decision on the option. I think all
>arguments are on the plate and there is little use in reiterating these
>in slightly different fashions.
>
>The thing I don't know is, how much effort it requires to
>request/create/setup another git repo, e.g. if we start with a) and
>there is a desire to create a separate repo for something. (I know the
>git commands to move a subtree to a different repo, therefore I'm just
>asking about the effort on the infra side)
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org

Re: git?

[Benson Margulies <bi...@gmail.com>]

On Tue, Oct 27, 2015 at 3:00 PM, David Jencks <da...@gmail.com> wrote:
> I suspect it’s obvious already, but I’m in favor of moving to a single git repo and stopping there unless and until we find it quite inconvenient.
>
> A million thanks Benson for doing the work.

I won't say 'you're welcome' until I've done some work, and I don't
perceive a consensus to get started quite just yet :-)

>
> thanks
> david jencks
>
>> On Oct 27, 2015, at 10:07 AM, Benson Margulies <bi...@gmail.com> wrote:
>>
>> On Tue, Oct 27, 2015 at 10:02 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> Am 27.10.15 um 14:52 schrieb Benson Margulies:
>>>> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>> Am 27.10.15 um 14:28 schrieb Benson Margulies:
>>>>>> As a volunteer of record, I have a preference at this point for
>>>>>> flipping the entire repo. It's not zero work; all the <scm/> elements
>>>>>> have to be edited, and release plugin config adjusted, for the maven
>>>>>> plugins. But that's very straightforward. Once we get this much done,
>>>>>> we can then start to move things to their own repo.
>>>>>
>>>>> What does it take to get a new git repo setup? Just in INFRA jira issue?
>>>>
>>>> Yes. There's a particular form of that JIRA that says,
>>>>
>>>>   'please convert our mirror to a writable repo and set SVN readonly'
>>>>
>>>> as opposed to
>>>>
>>>>  'please create a new, empty', repo.
>>>>
>>>> The 'all-at-once' plan uses the first option.
>>>>
>>>
>>> Right, understood and sorry to ask again, but if we do the all at once
>>> plan and want to split something into another new git repo, what does it
>>> take then?
>>
>> For each new repo, a JIRA asking for a new repo, and we move the
>> content ourselves.
>>
>>
>>>
>>> Carsten
>>>
>>>>>
>>>>> Regards
>>>>> Carsten
>>>>>
>>>>>>
>>>>>> ___However___, I'm willing to take up any other work plan that the
>>>>>> group agrees upon.
>>>>>>
>>>>>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <ma...@hupie.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 27/10/15 13:45, Carsten Ziegeler wrote:
>>>>>>>>
>>>>>>>> Looking at this thread, there seems to be no one really against moving
>>>>>>>> to git.
>>>>>>>>
>>>>>>>> When it comes to moving, we have three options:
>>>>>>>>
>>>>>>>> a) create a single git repo
>>>>>>>
>>>>>>>
>>>>>>> I'd start here.
>>>>>>> It's the simplest and lowest risk thing to do, doesn't break your parent-pom
>>>>>>> hierarchy, etc.
>>>>>>>
>>>>>>> It merely switches the VCS.
>>>>>>>
>>>>>>> And then work from there, try out different solutions for your parent-pom
>>>>>>> hierarchy, releasing, etc
>>>>>>>
>>>>>>> You can always split out parts of the tree later while preserving history.
>>>>>>> Git doesn't mind and has great tooling to do that.
>>>>>>>
>>>>>>>
>>>>>>>> b) create git repos by functional modules
>>>>>>>> c) create a git repo for every artifact
>>>>>>>>
>>>>>>>> Depending on which variant we pick, the more work it is to get
>>>>>>>> everything moved. Therefore apart from deciding for the option it
>>>>>>>> depends on a volunteer to drive this thing.
>>>>>>>>
>>>>>>>> I'm unsure on how we come to a decision on the option. I think all
>>>>>>>> arguments are on the plate and there is little use in reiterating these
>>>>>>>> in slightly different fashions.
>>>>>>>>
>>>>>>>> The thing I don't know is, how much effort it requires to
>>>>>>>> request/create/setup another git repo, e.g. if we start with a) and
>>>>>>>> there is a desire to create a separate repo for something. (I know the
>>>>>>>> git commands to move a subtree to a different repo, therefore I'm just
>>>>>>>> asking about the effort on the infra side)
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Carsten
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ferry Huberts
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziegeler@apache.org
>>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>

Re: git?

[David Jencks <da...@gmail.com>]

I suspect it’s obvious already, but I’m in favor of moving to a single git repo and stopping there unless and until we find it quite inconvenient.

A million thanks Benson for doing the work.

thanks
david jencks

> On Oct 27, 2015, at 10:07 AM, Benson Margulies <bi...@gmail.com> wrote:
> 
> On Tue, Oct 27, 2015 at 10:02 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Am 27.10.15 um 14:52 schrieb Benson Margulies:
>>> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>> Am 27.10.15 um 14:28 schrieb Benson Margulies:
>>>>> As a volunteer of record, I have a preference at this point for
>>>>> flipping the entire repo. It's not zero work; all the <scm/> elements
>>>>> have to be edited, and release plugin config adjusted, for the maven
>>>>> plugins. But that's very straightforward. Once we get this much done,
>>>>> we can then start to move things to their own repo.
>>>> 
>>>> What does it take to get a new git repo setup? Just in INFRA jira issue?
>>> 
>>> Yes. There's a particular form of that JIRA that says,
>>> 
>>>   'please convert our mirror to a writable repo and set SVN readonly'
>>> 
>>> as opposed to
>>> 
>>>  'please create a new, empty', repo.
>>> 
>>> The 'all-at-once' plan uses the first option.
>>> 
>> 
>> Right, understood and sorry to ask again, but if we do the all at once
>> plan and want to split something into another new git repo, what does it
>> take then?
> 
> For each new repo, a JIRA asking for a new repo, and we move the
> content ourselves.
> 
> 
>> 
>> Carsten
>> 
>>>> 
>>>> Regards
>>>> Carsten
>>>> 
>>>>> 
>>>>> ___However___, I'm willing to take up any other work plan that the
>>>>> group agrees upon.
>>>>> 
>>>>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <ma...@hupie.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> On 27/10/15 13:45, Carsten Ziegeler wrote:
>>>>>>> 
>>>>>>> Looking at this thread, there seems to be no one really against moving
>>>>>>> to git.
>>>>>>> 
>>>>>>> When it comes to moving, we have three options:
>>>>>>> 
>>>>>>> a) create a single git repo
>>>>>> 
>>>>>> 
>>>>>> I'd start here.
>>>>>> It's the simplest and lowest risk thing to do, doesn't break your parent-pom
>>>>>> hierarchy, etc.
>>>>>> 
>>>>>> It merely switches the VCS.
>>>>>> 
>>>>>> And then work from there, try out different solutions for your parent-pom
>>>>>> hierarchy, releasing, etc
>>>>>> 
>>>>>> You can always split out parts of the tree later while preserving history.
>>>>>> Git doesn't mind and has great tooling to do that.
>>>>>> 
>>>>>> 
>>>>>>> b) create git repos by functional modules
>>>>>>> c) create a git repo for every artifact
>>>>>>> 
>>>>>>> Depending on which variant we pick, the more work it is to get
>>>>>>> everything moved. Therefore apart from deciding for the option it
>>>>>>> depends on a volunteer to drive this thing.
>>>>>>> 
>>>>>>> I'm unsure on how we come to a decision on the option. I think all
>>>>>>> arguments are on the plate and there is little use in reiterating these
>>>>>>> in slightly different fashions.
>>>>>>> 
>>>>>>> The thing I don't know is, how much effort it requires to
>>>>>>> request/create/setup another git repo, e.g. if we start with a) and
>>>>>>> there is a desire to create a separate repo for something. (I know the
>>>>>>> git commands to move a subtree to a different repo, therefore I'm just
>>>>>>> asking about the effort on the infra side)
>>>>>>> 
>>>>>>> Regards
>>>>>>> Carsten
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Ferry Huberts
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Carsten Ziegeler
>>>> Adobe Research Switzerland
>>>> cziegeler@apache.org
>>> 
>> 
>> 
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org

Re: git?

[Benson Margulies <bi...@gmail.com>]

On Tue, Oct 27, 2015 at 10:02 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Am 27.10.15 um 14:52 schrieb Benson Margulies:
>> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> Am 27.10.15 um 14:28 schrieb Benson Margulies:
>>>> As a volunteer of record, I have a preference at this point for
>>>> flipping the entire repo. It's not zero work; all the <scm/> elements
>>>> have to be edited, and release plugin config adjusted, for the maven
>>>> plugins. But that's very straightforward. Once we get this much done,
>>>> we can then start to move things to their own repo.
>>>
>>> What does it take to get a new git repo setup? Just in INFRA jira issue?
>>
>> Yes. There's a particular form of that JIRA that says,
>>
>>    'please convert our mirror to a writable repo and set SVN readonly'
>>
>> as opposed to
>>
>>   'please create a new, empty', repo.
>>
>> The 'all-at-once' plan uses the first option.
>>
>
> Right, understood and sorry to ask again, but if we do the all at once
> plan and want to split something into another new git repo, what does it
> take then?

For each new repo, a JIRA asking for a new repo, and we move the
content ourselves.


>
> Carsten
>
>>>
>>> Regards
>>> Carsten
>>>
>>>>
>>>> ___However___, I'm willing to take up any other work plan that the
>>>> group agrees upon.
>>>>
>>>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <ma...@hupie.com> wrote:
>>>>>
>>>>>
>>>>> On 27/10/15 13:45, Carsten Ziegeler wrote:
>>>>>>
>>>>>> Looking at this thread, there seems to be no one really against moving
>>>>>> to git.
>>>>>>
>>>>>> When it comes to moving, we have three options:
>>>>>>
>>>>>> a) create a single git repo
>>>>>
>>>>>
>>>>> I'd start here.
>>>>> It's the simplest and lowest risk thing to do, doesn't break your parent-pom
>>>>> hierarchy, etc.
>>>>>
>>>>> It merely switches the VCS.
>>>>>
>>>>> And then work from there, try out different solutions for your parent-pom
>>>>> hierarchy, releasing, etc
>>>>>
>>>>> You can always split out parts of the tree later while preserving history.
>>>>> Git doesn't mind and has great tooling to do that.
>>>>>
>>>>>
>>>>>> b) create git repos by functional modules
>>>>>> c) create a git repo for every artifact
>>>>>>
>>>>>> Depending on which variant we pick, the more work it is to get
>>>>>> everything moved. Therefore apart from deciding for the option it
>>>>>> depends on a volunteer to drive this thing.
>>>>>>
>>>>>> I'm unsure on how we come to a decision on the option. I think all
>>>>>> arguments are on the plate and there is little use in reiterating these
>>>>>> in slightly different fashions.
>>>>>>
>>>>>> The thing I don't know is, how much effort it requires to
>>>>>> request/create/setup another git repo, e.g. if we start with a) and
>>>>>> there is a desire to create a separate repo for something. (I know the
>>>>>> git commands to move a subtree to a different repo, therefore I'm just
>>>>>> asking about the effort on the infra side)
>>>>>>
>>>>>> Regards
>>>>>> Carsten
>>>>>>
>>>>>
>>>>> --
>>>>> Ferry Huberts
>>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Am 27.10.15 um 14:52 schrieb Benson Margulies:
> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Am 27.10.15 um 14:28 schrieb Benson Margulies:
>>> As a volunteer of record, I have a preference at this point for
>>> flipping the entire repo. It's not zero work; all the <scm/> elements
>>> have to be edited, and release plugin config adjusted, for the maven
>>> plugins. But that's very straightforward. Once we get this much done,
>>> we can then start to move things to their own repo.
>>
>> What does it take to get a new git repo setup? Just in INFRA jira issue?
> 
> Yes. There's a particular form of that JIRA that says,
> 
>    'please convert our mirror to a writable repo and set SVN readonly'
> 
> as opposed to
> 
>   'please create a new, empty', repo.
> 
> The 'all-at-once' plan uses the first option.
> 

Right, understood and sorry to ask again, but if we do the all at once
plan and want to split something into another new git repo, what does it
take then?

Carsten

>>
>> Regards
>> Carsten
>>
>>>
>>> ___However___, I'm willing to take up any other work plan that the
>>> group agrees upon.
>>>
>>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <ma...@hupie.com> wrote:
>>>>
>>>>
>>>> On 27/10/15 13:45, Carsten Ziegeler wrote:
>>>>>
>>>>> Looking at this thread, there seems to be no one really against moving
>>>>> to git.
>>>>>
>>>>> When it comes to moving, we have three options:
>>>>>
>>>>> a) create a single git repo
>>>>
>>>>
>>>> I'd start here.
>>>> It's the simplest and lowest risk thing to do, doesn't break your parent-pom
>>>> hierarchy, etc.
>>>>
>>>> It merely switches the VCS.
>>>>
>>>> And then work from there, try out different solutions for your parent-pom
>>>> hierarchy, releasing, etc
>>>>
>>>> You can always split out parts of the tree later while preserving history.
>>>> Git doesn't mind and has great tooling to do that.
>>>>
>>>>
>>>>> b) create git repos by functional modules
>>>>> c) create a git repo for every artifact
>>>>>
>>>>> Depending on which variant we pick, the more work it is to get
>>>>> everything moved. Therefore apart from deciding for the option it
>>>>> depends on a volunteer to drive this thing.
>>>>>
>>>>> I'm unsure on how we come to a decision on the option. I think all
>>>>> arguments are on the plate and there is little use in reiterating these
>>>>> in slightly different fashions.
>>>>>
>>>>> The thing I don't know is, how much effort it requires to
>>>>> request/create/setup another git repo, e.g. if we start with a) and
>>>>> there is a desire to create a separate repo for something. (I know the
>>>>> git commands to move a subtree to a different repo, therefore I'm just
>>>>> asking about the effort on the infra side)
>>>>>
>>>>> Regards
>>>>> Carsten
>>>>>
>>>>
>>>> --
>>>> Ferry Huberts
>>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
> 


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

Re: git?

[Benson Margulies <bi...@gmail.com>]

On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Am 27.10.15 um 14:28 schrieb Benson Margulies:
>> As a volunteer of record, I have a preference at this point for
>> flipping the entire repo. It's not zero work; all the <scm/> elements
>> have to be edited, and release plugin config adjusted, for the maven
>> plugins. But that's very straightforward. Once we get this much done,
>> we can then start to move things to their own repo.
>
> What does it take to get a new git repo setup? Just in INFRA jira issue?

Yes. There's a particular form of that JIRA that says,

   'please convert our mirror to a writable repo and set SVN readonly'

as opposed to

  'please create a new, empty', repo.

The 'all-at-once' plan uses the first option.

>
> Regards
> Carsten
>
>>
>> ___However___, I'm willing to take up any other work plan that the
>> group agrees upon.
>>
>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <ma...@hupie.com> wrote:
>>>
>>>
>>> On 27/10/15 13:45, Carsten Ziegeler wrote:
>>>>
>>>> Looking at this thread, there seems to be no one really against moving
>>>> to git.
>>>>
>>>> When it comes to moving, we have three options:
>>>>
>>>> a) create a single git repo
>>>
>>>
>>> I'd start here.
>>> It's the simplest and lowest risk thing to do, doesn't break your parent-pom
>>> hierarchy, etc.
>>>
>>> It merely switches the VCS.
>>>
>>> And then work from there, try out different solutions for your parent-pom
>>> hierarchy, releasing, etc
>>>
>>> You can always split out parts of the tree later while preserving history.
>>> Git doesn't mind and has great tooling to do that.
>>>
>>>
>>>> b) create git repos by functional modules
>>>> c) create a git repo for every artifact
>>>>
>>>> Depending on which variant we pick, the more work it is to get
>>>> everything moved. Therefore apart from deciding for the option it
>>>> depends on a volunteer to drive this thing.
>>>>
>>>> I'm unsure on how we come to a decision on the option. I think all
>>>> arguments are on the plate and there is little use in reiterating these
>>>> in slightly different fashions.
>>>>
>>>> The thing I don't know is, how much effort it requires to
>>>> request/create/setup another git repo, e.g. if we start with a) and
>>>> there is a desire to create a separate repo for something. (I know the
>>>> git commands to move a subtree to a different repo, therefore I'm just
>>>> asking about the effort on the infra side)
>>>>
>>>> Regards
>>>> Carsten
>>>>
>>>
>>> --
>>> Ferry Huberts
>>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Am 27.10.15 um 14:28 schrieb Benson Margulies:
> As a volunteer of record, I have a preference at this point for
> flipping the entire repo. It's not zero work; all the <scm/> elements
> have to be edited, and release plugin config adjusted, for the maven
> plugins. But that's very straightforward. Once we get this much done,
> we can then start to move things to their own repo.

What does it take to get a new git repo setup? Just in INFRA jira issue?

Regards
Carsten

> 
> ___However___, I'm willing to take up any other work plan that the
> group agrees upon.
> 
> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <ma...@hupie.com> wrote:
>>
>>
>> On 27/10/15 13:45, Carsten Ziegeler wrote:
>>>
>>> Looking at this thread, there seems to be no one really against moving
>>> to git.
>>>
>>> When it comes to moving, we have three options:
>>>
>>> a) create a single git repo
>>
>>
>> I'd start here.
>> It's the simplest and lowest risk thing to do, doesn't break your parent-pom
>> hierarchy, etc.
>>
>> It merely switches the VCS.
>>
>> And then work from there, try out different solutions for your parent-pom
>> hierarchy, releasing, etc
>>
>> You can always split out parts of the tree later while preserving history.
>> Git doesn't mind and has great tooling to do that.
>>
>>
>>> b) create git repos by functional modules
>>> c) create a git repo for every artifact
>>>
>>> Depending on which variant we pick, the more work it is to get
>>> everything moved. Therefore apart from deciding for the option it
>>> depends on a volunteer to drive this thing.
>>>
>>> I'm unsure on how we come to a decision on the option. I think all
>>> arguments are on the plate and there is little use in reiterating these
>>> in slightly different fashions.
>>>
>>> The thing I don't know is, how much effort it requires to
>>> request/create/setup another git repo, e.g. if we start with a) and
>>> there is a desire to create a separate repo for something. (I know the
>>> git commands to move a subtree to a different repo, therefore I'm just
>>> asking about the effort on the infra side)
>>>
>>> Regards
>>> Carsten
>>>
>>
>> --
>> Ferry Huberts
> 


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

Re: git?

[Benson Margulies <bi...@gmail.com>]

As a volunteer of record, I have a preference at this point for
flipping the entire repo. It's not zero work; all the <scm/> elements
have to be edited, and release plugin config adjusted, for the maven
plugins. But that's very straightforward. Once we get this much done,
we can then start to move things to their own repo.

___However___, I'm willing to take up any other work plan that the
group agrees upon.

On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <ma...@hupie.com> wrote:
>
>
> On 27/10/15 13:45, Carsten Ziegeler wrote:
>>
>> Looking at this thread, there seems to be no one really against moving
>> to git.
>>
>> When it comes to moving, we have three options:
>>
>> a) create a single git repo
>
>
> I'd start here.
> It's the simplest and lowest risk thing to do, doesn't break your parent-pom
> hierarchy, etc.
>
> It merely switches the VCS.
>
> And then work from there, try out different solutions for your parent-pom
> hierarchy, releasing, etc
>
> You can always split out parts of the tree later while preserving history.
> Git doesn't mind and has great tooling to do that.
>
>
>> b) create git repos by functional modules
>> c) create a git repo for every artifact
>>
>> Depending on which variant we pick, the more work it is to get
>> everything moved. Therefore apart from deciding for the option it
>> depends on a volunteer to drive this thing.
>>
>> I'm unsure on how we come to a decision on the option. I think all
>> arguments are on the plate and there is little use in reiterating these
>> in slightly different fashions.
>>
>> The thing I don't know is, how much effort it requires to
>> request/create/setup another git repo, e.g. if we start with a) and
>> there is a desire to create a separate repo for something. (I know the
>> git commands to move a subtree to a different repo, therefore I'm just
>> asking about the effort on the infra side)
>>
>> Regards
>> Carsten
>>
>
> --
> Ferry Huberts

Re: git?

[Ferry Huberts <ma...@hupie.com>]

On 27/10/15 13:45, Carsten Ziegeler wrote:
> Looking at this thread, there seems to be no one really against moving
> to git.
>
> When it comes to moving, we have three options:
>
> a) create a single git repo

I'd start here.
It's the simplest and lowest risk thing to do, doesn't break your 
parent-pom hierarchy, etc.

It merely switches the VCS.

And then work from there, try out different solutions for your 
parent-pom hierarchy, releasing, etc

You can always split out parts of the tree later while preserving 
history. Git doesn't mind and has great tooling to do that.

> b) create git repos by functional modules
> c) create a git repo for every artifact
>
> Depending on which variant we pick, the more work it is to get
> everything moved. Therefore apart from deciding for the option it
> depends on a volunteer to drive this thing.
>
> I'm unsure on how we come to a decision on the option. I think all
> arguments are on the plate and there is little use in reiterating these
> in slightly different fashions.
>
> The thing I don't know is, how much effort it requires to
> request/create/setup another git repo, e.g. if we start with a) and
> there is a desire to create a separate repo for something. (I know the
> git commands to move a subtree to a different repo, therefore I'm just
> asking about the effort on the infra side)
>
> Regards
> Carsten
>

-- 
Ferry Huberts

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Looking at this thread, there seems to be no one really against moving
to git.

When it comes to moving, we have three options:

a) create a single git repo
b) create git repos by functional modules
c) create a git repo for every artifact

Depending on which variant we pick, the more work it is to get
everything moved. Therefore apart from deciding for the option it
depends on a volunteer to drive this thing.

I'm unsure on how we come to a decision on the option. I think all
arguments are on the plate and there is little use in reiterating these
in slightly different fashions.

The thing I don't know is, how much effort it requires to
request/create/setup another git repo, e.g. if we start with a) and
there is a desire to create a separate repo for something. (I know the
git commands to move a subtree to a different repo, therefore I'm just
asking about the effort on the infra side)

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

Re: git?

[Christian Schneider <ch...@die-schneider.net>]

I fully agree.

Christian

On 27.10.2015 13:15, Richard S. Hall wrote:
> I have no idea how it impacts anything, but keep in mind that 
> framework releases regularly (and generally) include more than one 
> subproject. I don't know how it complicates anything, just wanting to 
> point it out. In other words, it would be nice if those pushing this 
> make sure they work out all of the ramifications for all subprojects 
> in advance, since they are fixing something that isn't broken.
>
> -> richard

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: git?

["Richard S. Hall" <he...@ungoverned.org>]

I have no idea how it impacts anything, but keep in mind that framework 
releases regularly (and generally) include more than one subproject. I 
don't know how it complicates anything, just wanting to point it out. In 
other words, it would be nice if those pushing this make sure they work 
out all of the ramifications for all subprojects in advance, since they 
are fixing something that isn't broken.

-> richard

On 10/27/15 08:11 , Oliver Lietz wrote:
> On Tuesday 27 October 2015 11:26:37 Carsten Ziegeler wrote:
>> Am 27.10.15 um 11:12 schrieb Benson Margulies:
>>> My recommendation at this point in the discussion is to convert the
>>> repo _en bloc_, then split out very independent things (if any), and
>>> only then contemplate add-ons.
>> I think we should split up from the beginning. We can split up by
>> functional blocks, or we clearly identify a number of things where we
>> already know today that it would make sense to keep them in a single
>> repository.
>> Personally, I would put every artifact which is released in a single git
>> repo. It's a one time conversion from svn to git and with all the
>> different tooling available ,dealing with several git repos is not that
>> difficult. But of course different people think and work differently, so
>> I guess going with a compromise is the best option.
> +1 for a repo per release artifact. Simple rule and simply works best™.
>
> O.
>
>> Carsten

Re: git?

[Oliver Lietz <ap...@oliverlietz.de>]

On Tuesday 27 October 2015 11:26:37 Carsten Ziegeler wrote:
> Am 27.10.15 um 11:12 schrieb Benson Margulies:
> > My recommendation at this point in the discussion is to convert the
> > repo _en bloc_, then split out very independent things (if any), and
> > only then contemplate add-ons.
> 
> I think we should split up from the beginning. We can split up by
> functional blocks, or we clearly identify a number of things where we
> already know today that it would make sense to keep them in a single
> repository.
> Personally, I would put every artifact which is released in a single git
> repo. It's a one time conversion from svn to git and with all the
> different tooling available ,dealing with several git repos is not that
> difficult. But of course different people think and work differently, so
> I guess going with a compromise is the best option.

+1 for a repo per release artifact. Simple rule and simply works best™.

O.

> Carsten

Re: git?

[Christian Schneider <ch...@die-schneider.net>]

What do you think about releasing more coarse grained on kind of a 
subproject level (like e.g DependencyManager)?
I think it makes git much easier to use as then you can have one git 
repo per subproject and releases are simple
to manage.

As subprojects are quite loosely coupled to each other you typically can 
concentrate your work on one such
subproject / git repo at a time. So this would work without additional 
tooling.

Christian

On 27.10.2015 11:26, Carsten Ziegeler wrote:
> Am 27.10.15 um 11:12 schrieb Benson Margulies:
>> My recommendation at this point in the discussion is to convert the
>> repo _en bloc_, then split out very independent things (if any), and
>> only then contemplate add-ons.
>>
> I think we should split up from the beginning. We can split up by
> functional blocks, or we clearly identify a number of things where we
> already know today that it would make sense to keep them in a single
> repository.
> Personally, I would put every artifact which is released in a single git
> repo. It's a one time conversion from svn to git and with all the
> different tooling available ,dealing with several git repos is not that
> difficult. But of course different people think and work differently, so
> I guess going with a compromise is the best option.
>
> Carsten


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Am 27.10.15 um 11:12 schrieb Benson Margulies:
> My recommendation at this point in the discussion is to convert the
> repo _en bloc_, then split out very independent things (if any), and
> only then contemplate add-ons.
> 
I think we should split up from the beginning. We can split up by
functional blocks, or we clearly identify a number of things where we
already know today that it would make sense to keep them in a single
repository.
Personally, I would put every artifact which is released in a single git
repo. It's a one time conversion from svn to git and with all the
different tooling available ,dealing with several git repos is not that
difficult. But of course different people think and work differently, so
I guess going with a compromise is the best option.

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

Re: git?

[Ferry Huberts <ma...@hupie.com>]

I see.

I asked the git conversion question a few years ago of Felix (the guy).
Back then it was a big no-no. I do hope things have changed now for the 
project.

I'm a big fan of Git and have done a major Git conversion for a large 
site some 6 years ago, and can tell you from experience that Git adjusts 
really well to any workflow you choose and will actually cost less time 
(and is actually easier!) than other VCSes.

The conversion did spark a lot of controversy and 'religious' arguments. 
In the end _nobody_ complained after an initial 3 week adjustment period 
in which they got to understand Git a bit better, and got a feel for the 
advantages after actually working with Git.

So best of luck.

On 27/10/15 11:37, Benson Margulies wrote:
> For Ferry,
>
> The workflow to apply github pull requests with git svn is complex and
> error prone. More and more, contributions from the outside come in as
> pull requests.
>
> What's 'broken', and I choose that term with some trepidation, is that
> some of us really prefer some git workflow (task branches, whatever),
> and use git at our day jobs, and would rather not switch our brains to
> svn or the combination. The premise of this discussion is that if
> we're willing to do the work, others are willing to see us do it. It
> could be that there isn't a consensus for that.
>
>
>
> On Tue, Oct 27, 2015 at 6:22 AM, Ferry Huberts <ma...@hupie.com> wrote:
>> Side-line for me too.
>>
>> How about just using 'git svn ...'
>>
>> Work locally in git, store in svn.
>> What's the big deal?
>>
>> If there are blocking process issues _then_ you switch, right?
>>
>>
>>
>>
>> On 27/10/15 11:16, Achim Nierbeck wrote:
>>>
>>> Just looking from the side-line of this ...
>>> ... but all of this sounds more like a lot of pain compared to the gain.
>>>
>>> SVN isn't that bad after all, so why fix something that isn't really
>>> broken?
>>> Right now I don't see much of a benefit to this, but as I'm not part of
>>> any
>>> decision makers here,
>>> take this just as a little hint :-)
>>>
>>> regards, Achim
>>>
>>>
>>> 2015-10-27 11:12 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>>
>>>> My recommendation at this point in the discussion is to convert the
>>>> repo _en bloc_, then split out very independent things (if any), and
>>>> only then contemplate add-ons.
>>>>
>>>
>>>
>>>
>>
>> --
>> Ferry Huberts

-- 
Ferry Huberts

Re: git?

[Benson Margulies <bi...@gmail.com>]

For Ferry,

The workflow to apply github pull requests with git svn is complex and
error prone. More and more, contributions from the outside come in as
pull requests.

What's 'broken', and I choose that term with some trepidation, is that
some of us really prefer some git workflow (task branches, whatever),
and use git at our day jobs, and would rather not switch our brains to
svn or the combination. The premise of this discussion is that if
we're willing to do the work, others are willing to see us do it. It
could be that there isn't a consensus for that.



On Tue, Oct 27, 2015 at 6:22 AM, Ferry Huberts <ma...@hupie.com> wrote:
> Side-line for me too.
>
> How about just using 'git svn ...'
>
> Work locally in git, store in svn.
> What's the big deal?
>
> If there are blocking process issues _then_ you switch, right?
>
>
>
>
> On 27/10/15 11:16, Achim Nierbeck wrote:
>>
>> Just looking from the side-line of this ...
>> ... but all of this sounds more like a lot of pain compared to the gain.
>>
>> SVN isn't that bad after all, so why fix something that isn't really
>> broken?
>> Right now I don't see much of a benefit to this, but as I'm not part of
>> any
>> decision makers here,
>> take this just as a little hint :-)
>>
>> regards, Achim
>>
>>
>> 2015-10-27 11:12 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>
>>> My recommendation at this point in the discussion is to convert the
>>> repo _en bloc_, then split out very independent things (if any), and
>>> only then contemplate add-ons.
>>>
>>
>>
>>
>
> --
> Ferry Huberts

Re: git?

[Ferry Huberts <ma...@hupie.com>]

Side-line for me too.

How about just using 'git svn ...'

Work locally in git, store in svn.
What's the big deal?

If there are blocking process issues _then_ you switch, right?



On 27/10/15 11:16, Achim Nierbeck wrote:
> Just looking from the side-line of this ...
> ... but all of this sounds more like a lot of pain compared to the gain.
>
> SVN isn't that bad after all, so why fix something that isn't really broken?
> Right now I don't see much of a benefit to this, but as I'm not part of any
> decision makers here,
> take this just as a little hint :-)
>
> regards, Achim
>
>
> 2015-10-27 11:12 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>
>> My recommendation at this point in the discussion is to convert the
>> repo _en bloc_, then split out very independent things (if any), and
>> only then contemplate add-ons.
>>
>
>
>

-- 
Ferry Huberts

Re: git?

[Achim Nierbeck <bc...@googlemail.com>]

Just looking from the side-line of this ...
... but all of this sounds more like a lot of pain compared to the gain.

SVN isn't that bad after all, so why fix something that isn't really broken?
Right now I don't see much of a benefit to this, but as I'm not part of any
decision makers here,
take this just as a little hint :-)

regards, Achim


2015-10-27 11:12 GMT+01:00 Benson Margulies <bi...@gmail.com>:

> My recommendation at this point in the discussion is to convert the
> repo _en bloc_, then split out very independent things (if any), and
> only then contemplate add-ons.
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: git?

[Benson Margulies <bi...@gmail.com>]

My recommendation at this point in the discussion is to convert the
repo _en bloc_, then split out very independent things (if any), and
only then contemplate add-ons.

Re: git?

[de...@mobigov.com]

 

http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/


A decent replacement for gitslave that is currently maintained and
hosted in contrib in git itself. 

On 2015-10-27 03:27, Carsten Ziegeler wrote: 

> Am 26.10.15 um 21:17 schrieb Oliver Lietz:
> 
>> gitslave is no longer maintained, I suggest to look at Google repo[0] at least.
> 
> As a user of gitslave for some time I can only second this. Apart from
> not being maintained for several years, I had a lot of problems with it.
> I know that it works for the majority of people without problems, but
> there are cases where it simply fails. And I experienced too much pain
> with it :(
> 
> Carsten
 

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Am 26.10.15 um 21:17 schrieb Oliver Lietz:
> 
> gitslave is no longer maintained, I suggest to look at Google repo[0] at 
> least.
> 
As a user of gitslave for some time I can only second this. Apart from
not being maintained for several years, I had a lot of problems with it.
I know that it works for the majority of people without problems, but
there are cases where it simply fails. And I experienced too much pain
with it :(

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

Re: git?

[Oliver Lietz <ap...@oliverlietz.de>]

On Monday 26 October 2015 11:23:32 Robert Munteanu wrote:
> On Sun, 2015-10-25 at 07:47 +0100, Christian Schneider wrote:
> > I am not sure if one git repo for everything would be a good idea.
> > The
> > main reason is that in git (unlike in subversion) each branch and tag
> > you do contains all the other unrelated projects too.
> > I think it would also be quite difficult to checkout a state of the
> > repo
> > where you need bundle A in branch A1 and bundle B in branch B2.
> > Probably
> > this would mean that you need to checkout two instances of the repo
> > to have both branches visisble at the same time. You would then also
> > have to be really careful to not pick a project from the wrong
> > checkout
> > as it would be in kind of an undefined state there.
> > 
> > The other solution of having one git repo per bundle also seems to be
> > quite difficult to manage as you need to checkout and sync every such
> > checkout in the correct way. I have seen a project that does this at
> > a
> > customer and it is not very easy to work in this structure.
> > 
> > In the Aries project we went for kind of a compromise.
> > 
> > We aim for releases by subproject. So each subproject can go into one
> > git repo.
> > The advantage is that each tag in git really covers the whole
> > subproject. So from the git side this is natural.
> 
> If you have multiple git subprojects you can tie them into one git
> repository without resorting to submodules.
> 
> I've used a tool called gitslave [1] with very good results when
> splitting a large repository into multiple smaller ones ( 94 at the
> moment ).
> 
> gitslave allows you to define a single 'master' repository which
> minimally needs to hold a .gitslave file which points to the child
> repositories. You can then use the 'gits' command to run commands over
> multiple repositories, e.g.
> 
> * gits populate to create the child repositories
> * gits pull to run 'git pull' over all child repositoroes
> * gits push to 'run git push' over all child repositories
> 
> ... I guess you get the idea.

gitslave is no longer maintained, I suggest to look at Google repo[0] at 
least.

Regards,
O.

[0] https://code.google.com/p/git-repo/

> HTH,
> 
> Robert
> 
> 
> [1]: http://gitslave.sourceforge.net/
[...]

Re: git?

[Jan Willem Janssen <ja...@luminis.eu>]

> On 26 Oct 2015, at 10:03, Carsten Ziegeler <cz...@apache.org> wrote:
> 
>> 
>> In the 12+ years I’ve been working on apache projects I can’t recall any time when I’ve wanted to simultaneously check out different branches of modules of the same top level project.  Therefore, unless anyone has actual contrary experience, I’d be in favor of trying a single git repo and refining it into multiple repos if we discover problems in real life use.  (I have wanted to check out different branches of the same project simultaneously, but with git this is not helped by more repos).
> 
> But if you to look at two modules in detail, like .e.g. a specific tag
> or branch of event admin and a tag/branch of metatype, you can't do this
> with a single git repo. You can only see one or the other.
> Therefore I don't think a single git repo is a good thing.

"git worktree" solved that inconvenience.


--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814

My world is revolving around INAETICS and Amdatu

Luminis Technologies B.V.
Churchillplein 1
7314 BZ   Apeldoorn
+31 88 586 46 00

http://www.luminis-technologies.com
http://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01

Re: git?

[Peter Kriens <pk...@gmail.com>]

And it takes .3 secs to switch your workspace between your two branches/tags … 

Don’t forget that a lot of things that are heavy in SVN are feather weight in Git.

Kind regards,

	Peter Kriens



> On 26 okt. 2015, at 10:03, Carsten Ziegeler <cz...@apache.org> wrote:
> 
> Am 25.10.15 um 17:12 schrieb David Jencks:
>> Hi,
>> 
>> In the 12+ years I’ve been working on apache projects I can’t recall any time when I’ve wanted to simultaneously check out different branches of modules of the same top level project.  Therefore, unless anyone has actual contrary experience, I’d be in favor of trying a single git repo and refining it into multiple repos if we discover problems in real life use.  (I have wanted to check out different branches of the same project simultaneously, but with git this is not helped by more repos).
> 
> But if you to look at two modules in detail, like .e.g. a specific tag
> or branch of event admin and a tag/branch of metatype, you can't do this
> with a single git repo. You can only see one or the other.
> Therefore I don't think a single git repo is a good thing.
> 
> Carsten
>> 
>> thanks
>> david jencks
>> 
>>> On Oct 25, 2015, at 2:47 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>> 
>>> I am not sure if one git repo for everything would be a good idea. The main reason is that in git (unlike in subversion) each branch and tag you do contains all the other unrelated projects too.
>>> I think it would also be quite difficult to checkout a state of the repo where you need bundle A in branch A1 and bundle B in branch B2. Probably this would mean that you need to checkout two instances of the repo
>>> to have both branches visisble at the same time. You would then also have to be really careful to not pick a project from the wrong checkout as it would be in kind of an undefined state there.
>>> 
>>> The other solution of having one git repo per bundle also seems to be quite difficult to manage as you need to checkout and sync every such checkout in the correct way. I have seen a project that does this at a customer and it is not very easy to work in this structure.
>>> 
>>> In the Aries project we went for kind of a compromise.
>>> 
>>> We aim for releases by subproject. So each subproject can go into one git repo.
>>> The advantage is that each tag in git really covers the whole subproject. So from the git side this is natural.
>>> 
>>> The downside is of course that in many cases bundles are released that did not change at all.
>>> We make sure the package versions are done with semantic versioning.  So from the OSGi point of view the versioning
>>> is still working as before.
>>> 
>>> At the moment we have not yet done the migration to git but it is planned. We are currently moving each subproject to the release by subproject model gradually.
>>> Theoretically we can then move each subproject to git independently. I am not sure though how to move the change history over in that case.
>>> In any case the Aries JPA project is the first one that is fully converted to the release by subproject model if you want to take a look.
>>> https://github.com/apache/aries/tree/trunk/jpa
>>> 
>>> Christian
>>> 
>>> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
>>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <da...@gmail.com> wrote:
>>>>> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.
>>>> Well, there are git submodules. But I hate to take everyone into that
>>>> rabbit hole. I think we should aim to start with one big repo and
>>>> assume we can tame the maven-release-plugin to start with.
>>>> 
>>>> 
>>>>> FWIW, I’m hoping to move DS onto a gradle based build soon.
>>>>> 
>>>>> thanks
>>>>> david jencks
>>>>> 
>>>>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
>>>>>> 
>>>>>> Greeting, Marcel,
>>>>>> 
>>>>>> It's not my intention to try to talk anyone into changing how they
>>>>>> release anything. For the things that are built with Maven, it's my
>>>>>> preference to avoid exercising the maven-release-plugin's feature of
>>>>>> handling multiple released items in a repo, but it's just a
>>>>>> preference. If the acceptable compromise is to have less repos than
>>>>>> releasable items (possibly as few as one repo), I'd personally rather
>>>>>> do that than not move to git at all.
>>>>>> 
>>>>>> regards,
>>>>>> 
>>>>>> benson
>>>>>> 
>>>>>> 
>>>>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>>>>>> <ma...@luminis.nl> wrote:
>>>>>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>>>>>> 
>>>>>>>>> So I would definitely argue against getting a Git repository per bundle.
>>>>>>>>> Per subproject sounds like the right granularity to me.
>>>>>>>> If a subproject is released all at once, then we're completely
>>>>>>>> agreeing. If not, then your preference means exercising the
>>>>>>>> occasionally squishy part of the release plugin; maybe it will get
>>>>>>>> fixed once and for all.
>>>>>>> So for the dependency manager we reasoned as follows:
>>>>>>> 
>>>>>>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>>>>>> 
>>>>>>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>>>>>> 
>>>>>>> Greetings, Marcel
>>>>>>> 
>>>>>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org

Re: git?

[Carsten Ziegeler <cz...@apache.org>]

Am 25.10.15 um 17:12 schrieb David Jencks:
> Hi,
> 
> In the 12+ years I’ve been working on apache projects I can’t recall any time when I’ve wanted to simultaneously check out different branches of modules of the same top level project.  Therefore, unless anyone has actual contrary experience, I’d be in favor of trying a single git repo and refining it into multiple repos if we discover problems in real life use.  (I have wanted to check out different branches of the same project simultaneously, but with git this is not helped by more repos).

But if you to look at two modules in detail, like .e.g. a specific tag
or branch of event admin and a tag/branch of metatype, you can't do this
with a single git repo. You can only see one or the other.
Therefore I don't think a single git repo is a good thing.

Carsten
> 
> thanks
> david jencks
> 
>> On Oct 25, 2015, at 2:47 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> I am not sure if one git repo for everything would be a good idea. The main reason is that in git (unlike in subversion) each branch and tag you do contains all the other unrelated projects too.
>> I think it would also be quite difficult to checkout a state of the repo where you need bundle A in branch A1 and bundle B in branch B2. Probably this would mean that you need to checkout two instances of the repo
>> to have both branches visisble at the same time. You would then also have to be really careful to not pick a project from the wrong checkout as it would be in kind of an undefined state there.
>>
>> The other solution of having one git repo per bundle also seems to be quite difficult to manage as you need to checkout and sync every such checkout in the correct way. I have seen a project that does this at a customer and it is not very easy to work in this structure.
>>
>> In the Aries project we went for kind of a compromise.
>>
>> We aim for releases by subproject. So each subproject can go into one git repo.
>> The advantage is that each tag in git really covers the whole subproject. So from the git side this is natural.
>>
>> The downside is of course that in many cases bundles are released that did not change at all.
>> We make sure the package versions are done with semantic versioning.  So from the OSGi point of view the versioning
>> is still working as before.
>>
>> At the moment we have not yet done the migration to git but it is planned. We are currently moving each subproject to the release by subproject model gradually.
>> Theoretically we can then move each subproject to git independently. I am not sure though how to move the change history over in that case.
>> In any case the Aries JPA project is the first one that is fully converted to the release by subproject model if you want to take a look.
>> https://github.com/apache/aries/tree/trunk/jpa
>>
>> Christian
>>
>> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <da...@gmail.com> wrote:
>>>> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.
>>> Well, there are git submodules. But I hate to take everyone into that
>>> rabbit hole. I think we should aim to start with one big repo and
>>> assume we can tame the maven-release-plugin to start with.
>>>
>>>
>>>> FWIW, I’m hoping to move DS onto a gradle based build soon.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
>>>>>
>>>>> Greeting, Marcel,
>>>>>
>>>>> It's not my intention to try to talk anyone into changing how they
>>>>> release anything. For the things that are built with Maven, it's my
>>>>> preference to avoid exercising the maven-release-plugin's feature of
>>>>> handling multiple released items in a repo, but it's just a
>>>>> preference. If the acceptable compromise is to have less repos than
>>>>> releasable items (possibly as few as one repo), I'd personally rather
>>>>> do that than not move to git at all.
>>>>>
>>>>> regards,
>>>>>
>>>>> benson
>>>>>
>>>>>
>>>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>>>>> <ma...@luminis.nl> wrote:
>>>>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>>>>>
>>>>>>>> So I would definitely argue against getting a Git repository per bundle.
>>>>>>>> Per subproject sounds like the right granularity to me.
>>>>>>> If a subproject is released all at once, then we're completely
>>>>>>> agreeing. If not, then your preference means exercising the
>>>>>>> occasionally squishy part of the release plugin; maybe it will get
>>>>>>> fixed once and for all.
>>>>>> So for the dependency manager we reasoned as follows:
>>>>>>
>>>>>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>>>>>
>>>>>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>>>>>
>>>>>> Greetings, Marcel
>>>>>>
>>>>>>
>>
> 
> 


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

Re: git?

[Benson Margulies <bi...@gmail.com>]

There is a relatively standard Apache workflow that handles GH PR's.
The committer merges the PR and pushes it, editing a comment to say
'closes #nnn" and the PR gets closed.


On Sun, Oct 25, 2015 at 12:51 PM, David Jencks <da...@gmail.com> wrote:
> While working on bnd and OSGI at github I’ve become quite attached to the triangular workflow model.  (cf https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows <https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows>) I probably should know already, but does anyone know how practical it is to do this with apache git and developer branches at github?
>
> I don’t know if apache git is at version 2.5 yet, but from the above link it looks like the new worktree feature may provide an alternate solution to the multiple-branches problem.
>
> david jencks
>
>> On Oct 25, 2015, at 12:12 PM, David Jencks <da...@gmail.com> wrote:
>>
>> Hi,
>>
>> In the 12+ years I’ve been working on apache projects I can’t recall any time when I’ve wanted to simultaneously check out different branches of modules of the same top level project.  Therefore, unless anyone has actual contrary experience, I’d be in favor of trying a single git repo and refining it into multiple repos if we discover problems in real life use.  (I have wanted to check out different branches of the same project simultaneously, but with git this is not helped by more repos).
>>
>> thanks
>> david jencks
>>
>>> On Oct 25, 2015, at 2:47 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>>
>>> I am not sure if one git repo for everything would be a good idea. The main reason is that in git (unlike in subversion) each branch and tag you do contains all the other unrelated projects too.
>>> I think it would also be quite difficult to checkout a state of the repo where you need bundle A in branch A1 and bundle B in branch B2. Probably this would mean that you need to checkout two instances of the repo
>>> to have both branches visisble at the same time. You would then also have to be really careful to not pick a project from the wrong checkout as it would be in kind of an undefined state there.
>>>
>>> The other solution of having one git repo per bundle also seems to be quite difficult to manage as you need to checkout and sync every such checkout in the correct way. I have seen a project that does this at a customer and it is not very easy to work in this structure.
>>>
>>> In the Aries project we went for kind of a compromise.
>>>
>>> We aim for releases by subproject. So each subproject can go into one git repo.
>>> The advantage is that each tag in git really covers the whole subproject. So from the git side this is natural.
>>>
>>> The downside is of course that in many cases bundles are released that did not change at all.
>>> We make sure the package versions are done with semantic versioning.  So from the OSGi point of view the versioning
>>> is still working as before.
>>>
>>> At the moment we have not yet done the migration to git but it is planned. We are currently moving each subproject to the release by subproject model gradually.
>>> Theoretically we can then move each subproject to git independently. I am not sure though how to move the change history over in that case.
>>> In any case the Aries JPA project is the first one that is fully converted to the release by subproject model if you want to take a look.
>>> https://github.com/apache/aries/tree/trunk/jpa
>>>
>>> Christian
>>>
>>> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
>>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <da...@gmail.com> wrote:
>>>>> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.
>>>> Well, there are git submodules. But I hate to take everyone into that
>>>> rabbit hole. I think we should aim to start with one big repo and
>>>> assume we can tame the maven-release-plugin to start with.
>>>>
>>>>
>>>>> FWIW, I’m hoping to move DS onto a gradle based build soon.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
>>>>>>
>>>>>> Greeting, Marcel,
>>>>>>
>>>>>> It's not my intention to try to talk anyone into changing how they
>>>>>> release anything. For the things that are built with Maven, it's my
>>>>>> preference to avoid exercising the maven-release-plugin's feature of
>>>>>> handling multiple released items in a repo, but it's just a
>>>>>> preference. If the acceptable compromise is to have less repos than
>>>>>> releasable items (possibly as few as one repo), I'd personally rather
>>>>>> do that than not move to git at all.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> benson
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>>>>>> <ma...@luminis.nl> wrote:
>>>>>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>>>>>>
>>>>>>>>> So I would definitely argue against getting a Git repository per bundle.
>>>>>>>>> Per subproject sounds like the right granularity to me.
>>>>>>>> If a subproject is released all at once, then we're completely
>>>>>>>> agreeing. If not, then your preference means exercising the
>>>>>>>> occasionally squishy part of the release plugin; maybe it will get
>>>>>>>> fixed once and for all.
>>>>>>> So for the dependency manager we reasoned as follows:
>>>>>>>
>>>>>>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>>>>>>
>>>>>>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>>>>>>
>>>>>>> Greetings, Marcel
>>>>>>>
>>>>>>>
>>>
>>
>

Re: git?

[David Jencks <da...@gmail.com>]

While working on bnd and OSGI at github I’ve become quite attached to the triangular workflow model.  (cf https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows <https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows>) I probably should know already, but does anyone know how practical it is to do this with apache git and developer branches at github?

I don’t know if apache git is at version 2.5 yet, but from the above link it looks like the new worktree feature may provide an alternate solution to the multiple-branches problem.

david jencks

> On Oct 25, 2015, at 12:12 PM, David Jencks <da...@gmail.com> wrote:
> 
> Hi,
> 
> In the 12+ years I’ve been working on apache projects I can’t recall any time when I’ve wanted to simultaneously check out different branches of modules of the same top level project.  Therefore, unless anyone has actual contrary experience, I’d be in favor of trying a single git repo and refining it into multiple repos if we discover problems in real life use.  (I have wanted to check out different branches of the same project simultaneously, but with git this is not helped by more repos).
> 
> thanks
> david jencks
> 
>> On Oct 25, 2015, at 2:47 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>> 
>> I am not sure if one git repo for everything would be a good idea. The main reason is that in git (unlike in subversion) each branch and tag you do contains all the other unrelated projects too.
>> I think it would also be quite difficult to checkout a state of the repo where you need bundle A in branch A1 and bundle B in branch B2. Probably this would mean that you need to checkout two instances of the repo
>> to have both branches visisble at the same time. You would then also have to be really careful to not pick a project from the wrong checkout as it would be in kind of an undefined state there.
>> 
>> The other solution of having one git repo per bundle also seems to be quite difficult to manage as you need to checkout and sync every such checkout in the correct way. I have seen a project that does this at a customer and it is not very easy to work in this structure.
>> 
>> In the Aries project we went for kind of a compromise.
>> 
>> We aim for releases by subproject. So each subproject can go into one git repo.
>> The advantage is that each tag in git really covers the whole subproject. So from the git side this is natural.
>> 
>> The downside is of course that in many cases bundles are released that did not change at all.
>> We make sure the package versions are done with semantic versioning.  So from the OSGi point of view the versioning
>> is still working as before.
>> 
>> At the moment we have not yet done the migration to git but it is planned. We are currently moving each subproject to the release by subproject model gradually.
>> Theoretically we can then move each subproject to git independently. I am not sure though how to move the change history over in that case.
>> In any case the Aries JPA project is the first one that is fully converted to the release by subproject model if you want to take a look.
>> https://github.com/apache/aries/tree/trunk/jpa
>> 
>> Christian
>> 
>> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <da...@gmail.com> wrote:
>>>> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.
>>> Well, there are git submodules. But I hate to take everyone into that
>>> rabbit hole. I think we should aim to start with one big repo and
>>> assume we can tame the maven-release-plugin to start with.
>>> 
>>> 
>>>> FWIW, I’m hoping to move DS onto a gradle based build soon.
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
>>>>> 
>>>>> Greeting, Marcel,
>>>>> 
>>>>> It's not my intention to try to talk anyone into changing how they
>>>>> release anything. For the things that are built with Maven, it's my
>>>>> preference to avoid exercising the maven-release-plugin's feature of
>>>>> handling multiple released items in a repo, but it's just a
>>>>> preference. If the acceptable compromise is to have less repos than
>>>>> releasable items (possibly as few as one repo), I'd personally rather
>>>>> do that than not move to git at all.
>>>>> 
>>>>> regards,
>>>>> 
>>>>> benson
>>>>> 
>>>>> 
>>>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>>>>> <ma...@luminis.nl> wrote:
>>>>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>>>>> 
>>>>>>>> So I would definitely argue against getting a Git repository per bundle.
>>>>>>>> Per subproject sounds like the right granularity to me.
>>>>>>> If a subproject is released all at once, then we're completely
>>>>>>> agreeing. If not, then your preference means exercising the
>>>>>>> occasionally squishy part of the release plugin; maybe it will get
>>>>>>> fixed once and for all.
>>>>>> So for the dependency manager we reasoned as follows:
>>>>>> 
>>>>>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>>>>> 
>>>>>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>>>>> 
>>>>>> Greetings, Marcel
>>>>>> 
>>>>>> 
>> 
> 

Re: git?

[David Jencks <da...@gmail.com>]

Hi,

In the 12+ years I’ve been working on apache projects I can’t recall any time when I’ve wanted to simultaneously check out different branches of modules of the same top level project.  Therefore, unless anyone has actual contrary experience, I’d be in favor of trying a single git repo and refining it into multiple repos if we discover problems in real life use.  (I have wanted to check out different branches of the same project simultaneously, but with git this is not helped by more repos).

thanks
david jencks

> On Oct 25, 2015, at 2:47 AM, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> I am not sure if one git repo for everything would be a good idea. The main reason is that in git (unlike in subversion) each branch and tag you do contains all the other unrelated projects too.
> I think it would also be quite difficult to checkout a state of the repo where you need bundle A in branch A1 and bundle B in branch B2. Probably this would mean that you need to checkout two instances of the repo
> to have both branches visisble at the same time. You would then also have to be really careful to not pick a project from the wrong checkout as it would be in kind of an undefined state there.
> 
> The other solution of having one git repo per bundle also seems to be quite difficult to manage as you need to checkout and sync every such checkout in the correct way. I have seen a project that does this at a customer and it is not very easy to work in this structure.
> 
> In the Aries project we went for kind of a compromise.
> 
> We aim for releases by subproject. So each subproject can go into one git repo.
> The advantage is that each tag in git really covers the whole subproject. So from the git side this is natural.
> 
> The downside is of course that in many cases bundles are released that did not change at all.
> We make sure the package versions are done with semantic versioning.  So from the OSGi point of view the versioning
> is still working as before.
> 
> At the moment we have not yet done the migration to git but it is planned. We are currently moving each subproject to the release by subproject model gradually.
> Theoretically we can then move each subproject to git independently. I am not sure though how to move the change history over in that case.
> In any case the Aries JPA project is the first one that is fully converted to the release by subproject model if you want to take a look.
> https://github.com/apache/aries/tree/trunk/jpa
> 
> Christian
> 
> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <da...@gmail.com> wrote:
>>> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.
>> Well, there are git submodules. But I hate to take everyone into that
>> rabbit hole. I think we should aim to start with one big repo and
>> assume we can tame the maven-release-plugin to start with.
>> 
>> 
>>> FWIW, I’m hoping to move DS onto a gradle based build soon.
>>> 
>>> thanks
>>> david jencks
>>> 
>>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
>>>> 
>>>> Greeting, Marcel,
>>>> 
>>>> It's not my intention to try to talk anyone into changing how they
>>>> release anything. For the things that are built with Maven, it's my
>>>> preference to avoid exercising the maven-release-plugin's feature of
>>>> handling multiple released items in a repo, but it's just a
>>>> preference. If the acceptable compromise is to have less repos than
>>>> releasable items (possibly as few as one repo), I'd personally rather
>>>> do that than not move to git at all.
>>>> 
>>>> regards,
>>>> 
>>>> benson
>>>> 
>>>> 
>>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>>>> <ma...@luminis.nl> wrote:
>>>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>>>> 
>>>>>>> So I would definitely argue against getting a Git repository per bundle.
>>>>>>> Per subproject sounds like the right granularity to me.
>>>>>> If a subproject is released all at once, then we're completely
>>>>>> agreeing. If not, then your preference means exercising the
>>>>>> occasionally squishy part of the release plugin; maybe it will get
>>>>>> fixed once and for all.
>>>>> So for the dependency manager we reasoned as follows:
>>>>> 
>>>>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>>>> 
>>>>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>>>> 
>>>>> Greetings, Marcel
>>>>> 
>>>>> 
> 

Re: git?

[Robert Munteanu <ro...@apache.org>]

On Sun, 2015-10-25 at 07:47 +0100, Christian Schneider wrote:
> I am not sure if one git repo for everything would be a good idea.
> The 
> main reason is that in git (unlike in subversion) each branch and tag
> you do contains all the other unrelated projects too.
> I think it would also be quite difficult to checkout a state of the
> repo 
> where you need bundle A in branch A1 and bundle B in branch B2.
> Probably 
> this would mean that you need to checkout two instances of the repo
> to have both branches visisble at the same time. You would then also 
> have to be really careful to not pick a project from the wrong
> checkout 
> as it would be in kind of an undefined state there.

> The other solution of having one git repo per bundle also seems to be
> quite difficult to manage as you need to checkout and sync every such
> checkout in the correct way. I have seen a project that does this at
> a 
> customer and it is not very easy to work in this structure.
> 
> In the Aries project we went for kind of a compromise.
> 
> We aim for releases by subproject. So each subproject can go into one
> git repo.
> The advantage is that each tag in git really covers the whole 
> subproject. So from the git side this is natural.


If you have multiple git subprojects you can tie them into one git
repository without resorting to submodules.

I've used a tool called gitslave [1] with very good results when
splitting a large repository into multiple smaller ones ( 94 at the
moment ).

gitslave allows you to define a single 'master' repository which
minimally needs to hold a .gitslave file which points to the child
repositories. You can then use the 'gits' command to run commands over
multiple repositories, e.g.

* gits populate to create the child repositories
* gits pull to run 'git pull' over all child repositoroes
* gits push to 'run git push' over all child repositories

... I guess you get the idea.

HTH,

Robert


[1]: http://gitslave.sourceforge.net/

> 
> The downside is of course that in many cases bundles are released
> that 
> did not change at all.
> We make sure the package versions are done with semantic
> versioning.  So 
> from the OSGi point of view the versioning
> is still working as before.
> 
> At the moment we have not yet done the migration to git but it is 
> planned. We are currently moving each subproject to the release by 
> subproject model gradually.
> Theoretically we can then move each subproject to git independently.
> I 
> am not sure though how to move the change history over in that case.
> In any case the Aries JPA project is the first one that is fully 
> converted to the release by subproject model if you want to take a
> look.
> https://github.com/apache/aries/tree/trunk/jpa
> 
> Christian
> 
> Am 24.10.2015 um 23:32 schrieb Benson Margulies:
> > On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <david.a.jencks@gmail
> > .com> wrote:
> > > I like having several felix subprojects open in one eclipse
> > > instance at once, which the current svn structure
> > > facilitates.  Having just one git svn rebase to run is nice.  Is
> > > there a way to stitch together  several smaller git repos that
> > > would work similarly?  Not knowing how to do this, I am starting
> > > to lean towards one big repo.
> > Well, there are git submodules. But I hate to take everyone into
> > that
> > rabbit hole. I think we should aim to start with one big repo and
> > assume we can tame the maven-release-plugin to start with.
> > 
> > 
> > > FWIW, I’m hoping to move DS onto a gradle based build soon.
> > > 
> > > thanks
> > > david jencks
> > > 
> > > > On Oct 24, 2015, at 2:51 PM, Benson Margulies <benson@basistech
> > > > .com> wrote:
> > > > 
> > > > Greeting, Marcel,
> > > > 
> > > > It's not my intention to try to talk anyone into changing how
> > > > they
> > > > release anything. For the things that are built with Maven,
> > > > it's my
> > > > preference to avoid exercising the maven-release-plugin's
> > > > feature of
> > > > handling multiple released items in a repo, but it's just a
> > > > preference. If the acceptable compromise is to have less repos
> > > > than
> > > > releasable items (possibly as few as one repo), I'd personally
> > > > rather
> > > > do that than not move to git at all.
> > > > 
> > > > regards,
> > > > 
> > > > benson
> > > > 
> > > > 
> > > > On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
> > > > <ma...@luminis.nl> wrote:
> > > > > On 24 October 2015 at 11:36:03, Benson Margulies (benson@basi
> > > > > stech.com(mailto:benson@basistech.com)) wrote:
> > > > > 
> > > > > > > So I would definitely argue against getting a Git
> > > > > > > repository per bundle.
> > > > > > > Per subproject sounds like the right granularity to me.
> > > > > > If a subproject is released all at once, then we're
> > > > > > completely
> > > > > > agreeing. If not, then your preference means exercising the
> > > > > > occasionally squishy part of the release plugin; maybe it
> > > > > > will get
> > > > > > fixed once and for all.
> > > > > So for the dependency manager we reasoned as follows:
> > > > > 
> > > > > 1) When talking about releases within Apache, we are talking
> > > > > about source code. Releasing that a subproject at a time
> > > > > makes sense to me as the code, even if it ends up in
> > > > > different bundles, clearly belongs together.
> > > > > 
> > > > > 2) Binary releases are a matter of convenience and “what is
> > > > > convenient” depends a lot on where you’re coming from. A lot
> > > > > of people would argue that putting a binary in Maven is
> > > > > convenient, but there are definitely other options. The
> > > > > binary releases also don’t have to have a 1:1 mapping with
> > > > > the source, so we can have N bundles being put in Maven and
> > > > > other repositories all from the same source release.
> > > > > 
> > > > > Greetings, Marcel
> > > > > 
> > > > > 
> 

Re: git?

[Christian Schneider <ch...@die-schneider.net>]

I am not sure if one git repo for everything would be a good idea. The 
main reason is that in git (unlike in subversion) each branch and tag 
you do contains all the other unrelated projects too.
I think it would also be quite difficult to checkout a state of the repo 
where you need bundle A in branch A1 and bundle B in branch B2. Probably 
this would mean that you need to checkout two instances of the repo
to have both branches visisble at the same time. You would then also 
have to be really careful to not pick a project from the wrong checkout 
as it would be in kind of an undefined state there.

The other solution of having one git repo per bundle also seems to be 
quite difficult to manage as you need to checkout and sync every such 
checkout in the correct way. I have seen a project that does this at a 
customer and it is not very easy to work in this structure.

In the Aries project we went for kind of a compromise.

We aim for releases by subproject. So each subproject can go into one 
git repo.
The advantage is that each tag in git really covers the whole 
subproject. So from the git side this is natural.

The downside is of course that in many cases bundles are released that 
did not change at all.
We make sure the package versions are done with semantic versioning.  So 
from the OSGi point of view the versioning
is still working as before.

At the moment we have not yet done the migration to git but it is 
planned. We are currently moving each subproject to the release by 
subproject model gradually.
Theoretically we can then move each subproject to git independently. I 
am not sure though how to move the change history over in that case.
In any case the Aries JPA project is the first one that is fully 
converted to the release by subproject model if you want to take a look.
https://github.com/apache/aries/tree/trunk/jpa

Christian

Am 24.10.2015 um 23:32 schrieb Benson Margulies:
> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <da...@gmail.com> wrote:
>> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.
> Well, there are git submodules. But I hate to take everyone into that
> rabbit hole. I think we should aim to start with one big repo and
> assume we can tame the maven-release-plugin to start with.
>
>
>> FWIW, I’m hoping to move DS onto a gradle based build soon.
>>
>> thanks
>> david jencks
>>
>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
>>>
>>> Greeting, Marcel,
>>>
>>> It's not my intention to try to talk anyone into changing how they
>>> release anything. For the things that are built with Maven, it's my
>>> preference to avoid exercising the maven-release-plugin's feature of
>>> handling multiple released items in a repo, but it's just a
>>> preference. If the acceptable compromise is to have less repos than
>>> releasable items (possibly as few as one repo), I'd personally rather
>>> do that than not move to git at all.
>>>
>>> regards,
>>>
>>> benson
>>>
>>>
>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>>> <ma...@luminis.nl> wrote:
>>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>>>
>>>>>> So I would definitely argue against getting a Git repository per bundle.
>>>>>> Per subproject sounds like the right granularity to me.
>>>>> If a subproject is released all at once, then we're completely
>>>>> agreeing. If not, then your preference means exercising the
>>>>> occasionally squishy part of the release plugin; maybe it will get
>>>>> fixed once and for all.
>>>> So for the dependency manager we reasoned as follows:
>>>>
>>>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>>>
>>>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>>>
>>>> Greetings, Marcel
>>>>
>>>>

Re: git?

[Benson Margulies <bi...@gmail.com>]

On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <da...@gmail.com> wrote:
> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.

Well, there are git submodules. But I hate to take everyone into that
rabbit hole. I think we should aim to start with one big repo and
assume we can tame the maven-release-plugin to start with.


>
> FWIW, I’m hoping to move DS onto a gradle based build soon.
>
> thanks
> david jencks
>
>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
>>
>> Greeting, Marcel,
>>
>> It's not my intention to try to talk anyone into changing how they
>> release anything. For the things that are built with Maven, it's my
>> preference to avoid exercising the maven-release-plugin's feature of
>> handling multiple released items in a repo, but it's just a
>> preference. If the acceptable compromise is to have less repos than
>> releasable items (possibly as few as one repo), I'd personally rather
>> do that than not move to git at all.
>>
>> regards,
>>
>> benson
>>
>>
>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
>> <ma...@luminis.nl> wrote:
>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>>
>>>>> So I would definitely argue against getting a Git repository per bundle.
>>>>> Per subproject sounds like the right granularity to me.
>>>>
>>>> If a subproject is released all at once, then we're completely
>>>> agreeing. If not, then your preference means exercising the
>>>> occasionally squishy part of the release plugin; maybe it will get
>>>> fixed once and for all.
>>>
>>> So for the dependency manager we reasoned as follows:
>>>
>>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>>
>>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>>
>>> Greetings, Marcel
>>>
>>>
>

Re: git?

[de...@mobigov.com]

 

If I am understanding you correctlyl you can create your own git project
and add the other git repos as submodules in your project. Then do 

git submodule foreach git pull origin master

I personally hate git submodules though.

David Daniel

On 2015-10-24 16:21, David Jencks wrote: 

> I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates. Having just one git svn rebase to run is nice. Is there a way to stitch together several smaller git repos that would work similarly? Not knowing how to do this, I am starting to lean towards one big repo.
> 
> FWIW, I'm hoping to move DS onto a gradle based build soon.
> 
> thanks
> david jencks
> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote: Greeting, Marcel, It's not my intention to try to talk anyone into changing how they release anything. For the things that are built with Maven, it's my preference to avoid exercising the maven-release-plugin's feature of handling multiple released items in a repo, but it's just a preference. If the acceptable compromise is to have less repos than releasable items (possibly as few as one repo), I'd personally rather do that than not move to git at all. regards, benson On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans <ma...@luminis.nl> wrote: On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote: So I would definitely argue against getting a Git repository per bundle. Per subproject sounds like the right granularity to me. If a subproject is released all at once, then we're completely agreeing. If not, then your preference means exercising the
occasionally squishy part of the release plugin; maybe it will get fixed once and for all.
 So for the dependency manager we reasoned as follows: 1) When talking
about releases within Apache, we are talking about source code.
Releasing that a subproject at a time makes sense to me as the code,
even if it ends up in different bundles, clearly belongs together. 2)
Binary releases are a matter of convenience and "what is convenient"
depends a lot on where you're coming from. A lot of people would argue
that putting a binary in Maven is convenient, but there are definitely
other options. The binary releases also don't have to have a 1:1 mapping
with the source, so we can have N bundles being put in Maven and other
repositories all from the same source release. Greetings, Marcel 

Re: git?

[David Jencks <da...@gmail.com>]

I like having several felix subprojects open in one eclipse instance at once, which the current svn structure facilitates.  Having just one git svn rebase to run is nice.  Is there a way to stitch together  several smaller git repos that would work similarly?  Not knowing how to do this, I am starting to lean towards one big repo.

FWIW, I’m hoping to move DS onto a gradle based build soon.

thanks
david jencks

> On Oct 24, 2015, at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
> 
> Greeting, Marcel,
> 
> It's not my intention to try to talk anyone into changing how they
> release anything. For the things that are built with Maven, it's my
> preference to avoid exercising the maven-release-plugin's feature of
> handling multiple released items in a repo, but it's just a
> preference. If the acceptable compromise is to have less repos than
> releasable items (possibly as few as one repo), I'd personally rather
> do that than not move to git at all.
> 
> regards,
> 
> benson
> 
> 
> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
> <ma...@luminis.nl> wrote:
>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>> 
>>>> So I would definitely argue against getting a Git repository per bundle.
>>>> Per subproject sounds like the right granularity to me.
>>> 
>>> If a subproject is released all at once, then we're completely
>>> agreeing. If not, then your preference means exercising the
>>> occasionally squishy part of the release plugin; maybe it will get
>>> fixed once and for all.
>> 
>> So for the dependency manager we reasoned as follows:
>> 
>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>> 
>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>> 
>> Greetings, Marcel
>> 
>> 

Re: git?

[Benson Margulies <be...@basistech.com>]

This thread has again quiesced. I respectfully submit that it's time
for a PMC member to start a [VOTE] thread to see whether there is a
decision to proceed.


On Sat, Oct 24, 2015 at 2:51 PM, Benson Margulies <be...@basistech.com> wrote:
> Greeting, Marcel,
>
> It's not my intention to try to talk anyone into changing how they
> release anything. For the things that are built with Maven, it's my
> preference to avoid exercising the maven-release-plugin's feature of
> handling multiple released items in a repo, but it's just a
> preference. If the acceptable compromise is to have less repos than
> releasable items (possibly as few as one repo), I'd personally rather
> do that than not move to git at all.
>
> regards,
>
> benson
>
>
> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
> <ma...@luminis.nl> wrote:
>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>>
>>> > So I would definitely argue against getting a Git repository per bundle.
>>> > Per subproject sounds like the right granularity to me.
>>>
>>> If a subproject is released all at once, then we're completely
>>> agreeing. If not, then your preference means exercising the
>>> occasionally squishy part of the release plugin; maybe it will get
>>> fixed once and for all.
>>
>> So for the dependency manager we reasoned as follows:
>>
>> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>>
>> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>>
>> Greetings, Marcel
>>
>>

Re: git?

[Benson Margulies <be...@basistech.com>]

Greeting, Marcel,

It's not my intention to try to talk anyone into changing how they
release anything. For the things that are built with Maven, it's my
preference to avoid exercising the maven-release-plugin's feature of
handling multiple released items in a repo, but it's just a
preference. If the acceptable compromise is to have less repos than
releasable items (possibly as few as one repo), I'd personally rather
do that than not move to git at all.

regards,

benson


On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:
>
>> > So I would definitely argue against getting a Git repository per bundle.
>> > Per subproject sounds like the right granularity to me.
>>
>> If a subproject is released all at once, then we're completely
>> agreeing. If not, then your preference means exercising the
>> occasionally squishy part of the release plugin; maybe it will get
>> fixed once and for all.
>
> So for the dependency manager we reasoned as follows:
>
> 1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.
>
> 2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.
>
> Greetings, Marcel
>
>

Re: git?

[Marcel Offermans <ma...@luminis.nl>]

On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@basistech.com)) wrote:

> > So I would definitely argue against getting a Git repository per bundle.  
> > Per subproject sounds like the right granularity to me.  
>  
> If a subproject is released all at once, then we're completely  
> agreeing. If not, then your preference means exercising the  
> occasionally squishy part of the release plugin; maybe it will get  
> fixed once and for all.

So for the dependency manager we reasoned as follows:

1) When talking about releases within Apache, we are talking about source code. Releasing that a subproject at a time makes sense to me as the code, even if it ends up in different bundles, clearly belongs together.

2) Binary releases are a matter of convenience and “what is convenient” depends a lot on where you’re coming from. A lot of people would argue that putting a binary in Maven is convenient, but there are definitely other options. The binary releases also don’t have to have a 1:1 mapping with the source, so we can have N bundles being put in Maven and other repositories all from the same source release.

Greetings, Marcel

Re: git?

[Benson Margulies <be...@basistech.com>]

On Sat, Oct 24, 2015 at 2:27 PM, Richard Hall <he...@ungoverned.org> wrote:
> On Oct 24, 2015 2:21 PM, "Marcel Offermans" <ma...@luminis.nl>
> wrote:
>>
>> Within Felix we have “subprojects” that consist of one or more bundles
> and I would argue that they are always released together. This does not
> mean that for every release, every bundle needs to change, sometimes only a
> subset of the released bundles change.
>>
>> So I would definitely argue against getting a Git repository per bundle.
> Per subproject sounds like the right granularity to me.

If a subproject is released all at once, then we're completely
agreeing. If not, then your preference means exercising the
occasionally squishy part of the release plugin; maybe it will get
fixed once and for all.


>>
>> Regarding Maven I don’t have much experience on how to set that up with
> Git. Note that not all subprojects use Maven. Specifically the “dependency
> manager” uses a gradle/bndtools based setup. We could easily move that to
> its own Git repository. It is already setup for that.
>>
>> In general I like Git, and outside of the Apache projects I’m involved in
> I almost exclusively use it, but I’m +0 on making a switch because it’s
> also a lot of work and I don’t think the benefits are huge. If it works,
> don’t fix it. :)
>
> +1
>
> I don't care, but I agree the benefits aren't super compelling other than
> buzzword compliance.
>
>>
>> Greetings, Marcel
>>
>> On 24 October 2015 at 11:06:02, Benson Margulies (benson@basistech.com)
> wrote:
>>
>> Here's the basic issue. The maven-release-plugin doesn't always work
>> with git when the pom you are releasing is not the top of the
>> repository. I put a great deal of work into fixing it, and yet others
>> continue to report problems. (It works for my favorite test case.)
>>
>> So, the conservative strategy is to put each group that are released
>> together into a repo.
>>
>> As far as migration, INFRA only understands 'one big flip.' That
>> offers us two choices if our goal is to subdivide:
>>
>> 1: Let infra do the flip, and then gradually get new repos and move
>> some things into them.
>>
>> 2: Do our own migration: one by one, get infra to make new, empty,
>> repos, and use the existing mirror repo as a source to push the pieces
>> into them.
>>
>> I don't see much value in item #1 over item #2. So I'd propose to
>> start by asking infra for a repo for the overall parent pom, which I
>> think needs to live in a repo by itself (that's how we do it at
>> Maven). Once we have released the pom from there, we can migrate
>> others in whatever grouping we prefer.
>>
>> As the new committer here, I have to ask: what decision-making process
>> would be good?
>>
>>
>>
>>
>> On Sat, Oct 24, 2015 at 1:00 AM, David Jencks <da...@gmail.com>
> wrote:
>> > YAY!!
>> >
>> > as you can tell, I’m in favor of it.
>> >
>> > I think that 1 repo per project may be too small. For instance I think
> it makes sense to have one repo for the 3 gogo projects, even though they
> are released separately. I think soon there will be at least 4 scr projects
> and I’d like them to be in 1 repo.
>> >
>> > Do you know how infra feels about gradual migration? Are they fine with
> it or do they prefer all-at-once?
>> >
>> > thanks
>> > david jencks
>> >
>> >> On Oct 23, 2015, at 10:36 PM, Benson Margulies <be...@basistech.com>
> wrote:
>> >>
>> >> There was some discussion a while back about git, which I recall
>> >> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
>> >> releasable thing gets its own git repo.
>> >>
>> >> How do folks feel about starting with a migration of the bundle plugin?
>> >>
>> >> --benson
>> >

Re: git?

[Richard Hall <he...@ungoverned.org>]

On Oct 24, 2015 2:21 PM, "Marcel Offermans" <ma...@luminis.nl>
wrote:
>
> Within Felix we have “subprojects” that consist of one or more bundles
and I would argue that they are always released together. This does not
mean that for every release, every bundle needs to change, sometimes only a
subset of the released bundles change.
>
> So I would definitely argue against getting a Git repository per bundle.
Per subproject sounds like the right granularity to me.
>
> Regarding Maven I don’t have much experience on how to set that up with
Git. Note that not all subprojects use Maven. Specifically the “dependency
manager” uses a gradle/bndtools based setup. We could easily move that to
its own Git repository. It is already setup for that.
>
> In general I like Git, and outside of the Apache projects I’m involved in
I almost exclusively use it, but I’m +0 on making a switch because it’s
also a lot of work and I don’t think the benefits are huge. If it works,
don’t fix it. :)

+1

I don't care, but I agree the benefits aren't super compelling other than
buzzword compliance.

>
> Greetings, Marcel
>
> On 24 October 2015 at 11:06:02, Benson Margulies (benson@basistech.com)
wrote:
>
> Here's the basic issue. The maven-release-plugin doesn't always work
> with git when the pom you are releasing is not the top of the
> repository. I put a great deal of work into fixing it, and yet others
> continue to report problems. (It works for my favorite test case.)
>
> So, the conservative strategy is to put each group that are released
> together into a repo.
>
> As far as migration, INFRA only understands 'one big flip.' That
> offers us two choices if our goal is to subdivide:
>
> 1: Let infra do the flip, and then gradually get new repos and move
> some things into them.
>
> 2: Do our own migration: one by one, get infra to make new, empty,
> repos, and use the existing mirror repo as a source to push the pieces
> into them.
>
> I don't see much value in item #1 over item #2. So I'd propose to
> start by asking infra for a repo for the overall parent pom, which I
> think needs to live in a repo by itself (that's how we do it at
> Maven). Once we have released the pom from there, we can migrate
> others in whatever grouping we prefer.
>
> As the new committer here, I have to ask: what decision-making process
> would be good?
>
>
>
>
> On Sat, Oct 24, 2015 at 1:00 AM, David Jencks <da...@gmail.com>
wrote:
> > YAY!!
> >
> > as you can tell, I’m in favor of it.
> >
> > I think that 1 repo per project may be too small. For instance I think
it makes sense to have one repo for the 3 gogo projects, even though they
are released separately. I think soon there will be at least 4 scr projects
and I’d like them to be in 1 repo.
> >
> > Do you know how infra feels about gradual migration? Are they fine with
it or do they prefer all-at-once?
> >
> > thanks
> > david jencks
> >
> >> On Oct 23, 2015, at 10:36 PM, Benson Margulies <be...@basistech.com>
wrote:
> >>
> >> There was some discussion a while back about git, which I recall
> >> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
> >> releasable thing gets its own git repo.
> >>
> >> How do folks feel about starting with a migration of the bundle plugin?
> >>
> >> --benson
> >

Re: git?

[Marcel Offermans <ma...@luminis.nl>]

Within Felix we have “subprojects” that consist of one or more bundles and I would argue that they are always released together. This does not mean that for every release, every bundle needs to change, sometimes only a subset of the released bundles change.

So I would definitely argue against getting a Git repository per bundle. Per subproject sounds like the right granularity to me.

Regarding Maven I don’t have much experience on how to set that up with Git. Note that not all subprojects use Maven. Specifically the “dependency manager” uses a gradle/bndtools based setup. We could easily move that to its own Git repository. It is already setup for that.

In general I like Git, and outside of the Apache projects I’m involved in I almost exclusively use it, but I’m +0 on making a switch because it’s also a lot of work and I don’t think the benefits are huge. If it works, don’t fix it. :)

Greetings, Marcel

On 24 October 2015 at 11:06:02, Benson Margulies (benson@basistech.com) wrote:

Here's the basic issue. The maven-release-plugin doesn't always work  
with git when the pom you are releasing is not the top of the  
repository. I put a great deal of work into fixing it, and yet others  
continue to report problems. (It works for my favorite test case.)  

So, the conservative strategy is to put each group that are released  
together into a repo.  

As far as migration, INFRA only understands 'one big flip.' That  
offers us two choices if our goal is to subdivide:  

1: Let infra do the flip, and then gradually get new repos and move  
some things into them.  

2: Do our own migration: one by one, get infra to make new, empty,  
repos, and use the existing mirror repo as a source to push the pieces  
into them.  

I don't see much value in item #1 over item #2. So I'd propose to  
start by asking infra for a repo for the overall parent pom, which I  
think needs to live in a repo by itself (that's how we do it at  
Maven). Once we have released the pom from there, we can migrate  
others in whatever grouping we prefer.  

As the new committer here, I have to ask: what decision-making process  
would be good?  




On Sat, Oct 24, 2015 at 1:00 AM, David Jencks <da...@gmail.com> wrote:  
> YAY!!  
>  
> as you can tell, I’m in favor of it.  
>  
> I think that 1 repo per project may be too small. For instance I think it makes sense to have one repo for the 3 gogo projects, even though they are released separately. I think soon there will be at least 4 scr projects and I’d like them to be in 1 repo.  
>  
> Do you know how infra feels about gradual migration? Are they fine with it or do they prefer all-at-once?  
>  
> thanks  
> david jencks  
>  
>> On Oct 23, 2015, at 10:36 PM, Benson Margulies <be...@basistech.com> wrote:  
>>  
>> There was some discussion a while back about git, which I recall  
>> (perhaps inaccurately) as vaguely positive. It's a lot easier if each  
>> releasable thing gets its own git repo.  
>>  
>> How do folks feel about starting with a migration of the bundle plugin?  
>>  
>> --benson  
>  

Re: git?

[Benson Margulies <be...@basistech.com>]

Here's the basic issue. The maven-release-plugin doesn't always work
with git when the pom you are releasing is not the top of the
repository. I put a great deal of work into fixing it, and yet others
continue to report problems. (It works for my favorite test case.)

So, the conservative strategy is to put each group that are released
together into a repo.

As far as migration, INFRA only understands 'one big flip.' That
offers us two choices if our goal is to subdivide:

1: Let infra do the flip, and then gradually get new repos and move
some things into them.

2: Do our own migration: one by one, get infra to make new, empty,
repos, and use the existing mirror repo as a source to push the pieces
into them.

I don't see much value in item #1 over item #2. So I'd propose to
start by asking infra for a repo for the overall parent pom, which I
think needs to live in a repo by itself (that's how we do it at
Maven). Once we have released the pom from there, we can migrate
others in whatever grouping we prefer.

As the new committer here, I have to ask: what decision-making process
would be good?




On Sat, Oct 24, 2015 at 1:00 AM, David Jencks <da...@gmail.com> wrote:
> YAY!!
>
> as you can tell, I’m in favor of it.
>
> I think that 1 repo per project may be too small.  For instance I think it makes sense to have one repo for the 3 gogo projects, even though they are released separately.  I think soon there will be at least 4 scr projects and I’d like them to be in 1 repo.
>
> Do you know how infra feels about gradual migration?  Are they fine with it or do they prefer all-at-once?
>
> thanks
> david jencks
>
>> On Oct 23, 2015, at 10:36 PM, Benson Margulies <be...@basistech.com> wrote:
>>
>> There was some discussion a while back about git, which I recall
>> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
>> releasable thing gets its own git repo.
>>
>> How do folks feel about starting with a migration of the bundle plugin?
>>
>> --benson
>

Re: git?

[David Jencks <da...@gmail.com>]

YAY!!

as you can tell, I’m in favor of it.

I think that 1 repo per project may be too small.  For instance I think it makes sense to have one repo for the 3 gogo projects, even though they are released separately.  I think soon there will be at least 4 scr projects and I’d like them to be in 1 repo.

Do you know how infra feels about gradual migration?  Are they fine with it or do they prefer all-at-once?

thanks
david jencks

> On Oct 23, 2015, at 10:36 PM, Benson Margulies <be...@basistech.com> wrote:
> 
> There was some discussion a while back about git, which I recall
> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
> releasable thing gets its own git repo.
> 
> How do folks feel about starting with a migration of the bundle plugin?
> 
> --benson