Where do we put new git modules?

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

Hi,

Having just kicked off the donation vote for the resource encryption
module stuff, I was thinking about where to store the module in git.

Typically new donations would end up in contrib but we don't have that.
We could create a new repo outright, but that's a 'costly' process, as
it's hard to change if decide the name is not right.

We could either:

- place it in the whiteboard and move it to a proper repo before its
first release, with the release manager proposing a name
- having a separate discussion for the git repo name in parallel to the
import and importing it into a separate repo directly

Thoughts?

Robert

Re: Where do we put new git modules?

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

On Tue, 2018-01-09 at 15:48 +0000, Stefan Seifert wrote:
> > On Tue, Jan 9, 2018 at 1:47 PM, Robert Munteanu <rombert@apache.org
> > > wrote:
> > > ...- place it in the whiteboard and move it to a proper repo
> > > before its
> > > first release, with the release manager proposing a name..
> > 
> > +1, it's simple and leaves time to make a proper naming decision.
> > 
> > -Bertrand
> 
> yes, this would avoid making the naming decision early, or even the
> decision to release it at all.
> on the other hand it makes it more difficult if the contribution was
> already developed in a standalone git repo outside the ASF and
> perhaps there is already a commit history we want preserve - getting
> this into the whiteboard master branch in a subdirectory is
> complicated.

We can both import a directory with history and export a directory with
history using Git. Some scripting is required, but I can take care of
that with the first import, documentation included.

The export part is mostly covered in [1] as we took care of the SVN →
Git migration.

The import part is much simpler IIRC, basically 

1. git format-patch on the 'source' repo to generate patches for all
commmits
2. git am --directory=new-module-dir on the 'target' repo to apply the
patches to the 'new-module-dir' directory.

Thanks,

Robert

[1]: https://github.com/apache/sling-tooling-scm

RE: Where do we put new git modules?

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

you can push a separate whiteboard branch directly to a new git repo including all history with one command.

i agree that that commit history before dontation is not a big issue, but the commit history after the donation and before moving to a new git repo is important.

stefan

>-----Original Message-----
>From: Daniel Klco [mailto:daniel.klco@gmail.com]
>Sent: Tuesday, January 9, 2018 4:59 PM
>To: dev@sling.apache.org
>Subject: RE: Where do we put new git modules?
>
>I was just thinking about this as well. What would be the advantage of
>branches over subfolders? When converted to the "real" repo for the module,
>you'd still lose the commit history, right?
>
>Folders might make it easier to see and explore the "contrib" /
>experimental features.
>
>On Jan 9, 2018 7:48 AM, "Stefan Seifert" <ss...@pro-vision.de> wrote:
>
>>
>> >On Tue, Jan 9, 2018 at 1:47 PM, Robert Munteanu <ro...@apache.org>
>> wrote:
>> >> ...- place it in the whiteboard and move it to a proper repo before
>its
>> >> first release, with the release manager proposing a name..
>> >
>> >+1, it's simple and leaves time to make a proper naming decision.
>> >
>> >-Bertrand
>>
>> yes, this would avoid making the naming decision early, or even the
>> decision to release it at all.
>> on the other hand it makes it more difficult if the contribution was
>> already developed in a standalone git repo outside the ASF and perhaps
>> there is already a commit history we want preserve - getting this into
>the
>> whiteboard master branch in a subdirectory is complicated.
>>
>> or do you propose a new branch for each contribution in the whiteboard,
>> not related to it's master branch at all?
>> having everything in the master branch also makes it difficult to split
>it
>> later (yes i know, it's possible in git, but still requires more effort
>> then just having one branch per module).
>>
>> having one branch per contrib/whiteboard module may seem unorthodox on
>the
>> first sight, but might come very handy when it's moved later, and also
>for
>> the first import.
>>
>> stefan
>>
>>

RE: Where do we put new git modules?

[Daniel Klco <da...@gmail.com>]

I was just thinking about this as well. What would be the advantage of
branches over subfolders? When converted to the "real" repo for the module,
you'd still lose the commit history, right?

Folders might make it easier to see and explore the "contrib" /
experimental features.

On Jan 9, 2018 7:48 AM, "Stefan Seifert" <ss...@pro-vision.de> wrote:

>
> >On Tue, Jan 9, 2018 at 1:47 PM, Robert Munteanu <ro...@apache.org>
> wrote:
> >> ...- place it in the whiteboard and move it to a proper repo before its
> >> first release, with the release manager proposing a name..
> >
> >+1, it's simple and leaves time to make a proper naming decision.
> >
> >-Bertrand
>
> yes, this would avoid making the naming decision early, or even the
> decision to release it at all.
> on the other hand it makes it more difficult if the contribution was
> already developed in a standalone git repo outside the ASF and perhaps
> there is already a commit history we want preserve - getting this into the
> whiteboard master branch in a subdirectory is complicated.
>
> or do you propose a new branch for each contribution in the whiteboard,
> not related to it's master branch at all?
> having everything in the master branch also makes it difficult to split it
> later (yes i know, it's possible in git, but still requires more effort
> then just having one branch per module).
>
> having one branch per contrib/whiteboard module may seem unorthodox on the
> first sight, but might come very handy when it's moved later, and also for
> the first import.
>
> stefan
>
>

Re: Where do we put new git modules?

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Jan 10, 2018 at 12:39 PM, Robert Munteanu <ro...@apache.org> wrote:
> ...Unless strictly needed, I would suggest that we import just the latest
> state, not the repository history...

+1, but as Stefan notes, once imported the history is important and we
shouldn't lose it - for which your copy-with script mechanism helps.

-Bertrand

Re: Where do we put new git modules?

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

On Thu, 2018-01-11 at 13:45 +0000, Jason Bailey wrote:
> Couldn't this also be phrased as being that the import be squashed or
> rebased into a single commit prior to the import occurring?  

Yes, it can be phrased like that. I am not sure whether attaching a
source code file with a checksum is a hard requirement or just the most
convenient way.

Robert

> 
> -----Original Message-----
> From: Robert Munteanu [mailto:rombert@apache.org] 
> Sent: Wednesday, January 10, 2018 6:39 AM
> To: dev@sling.apache.org
> Subject: Re: Where do we put new git modules?
> 
> EXTERNAL
> 
> On Tue, 2018-01-09 at 16:55 +0100, Bertrand Delacretaz wrote:
> > On Tue, Jan 9, 2018 at 4:48 PM, Stefan Seifert <sseifert@pro-vision
> > .d
> > e> wrote:
> > > ...it makes it more difficult if the contribution was already 
> > > developed in a standalone git repo outside the ASF and perhaps
> > > there 
> > > is already a commit history we want preserve...
> > 
> > I don't think we are interested in the history of those donations
> > in 
> > general.
> > 
> > If a special case needs that we can always handle it in a
> > different 
> > way.
> 
> This got me thinking for a little bit. Donations were always done as
> as source code dumps, and that's what was voted on. We did not vote
> on histories, and a case can be made that source code histories are
> less safe to import, as we don't review the whole history, but
> instead the latest state - the patch.
> 
> Unless strictly needed, I would suggest that we import just the
> latest state, not the repository history.
> 
> Robert

RE: Where do we put new git modules?

[Jason Bailey <Ja...@sas.com>]

Couldn't this also be phrased as being that the import be squashed or rebased into a single commit prior to the import occurring?  

-----Original Message-----
From: Robert Munteanu [mailto:rombert@apache.org] 
Sent: Wednesday, January 10, 2018 6:39 AM
To: dev@sling.apache.org
Subject: Re: Where do we put new git modules?

EXTERNAL

On Tue, 2018-01-09 at 16:55 +0100, Bertrand Delacretaz wrote:
> On Tue, Jan 9, 2018 at 4:48 PM, Stefan Seifert <sseifert@pro-vision.d
> e> wrote:
> > ...it makes it more difficult if the contribution was already 
> > developed in a standalone git repo outside the ASF and perhaps there 
> > is already a commit history we want preserve...
>
> I don't think we are interested in the history of those donations in 
> general.
>
> If a special case needs that we can always handle it in a different 
> way.

This got me thinking for a little bit. Donations were always done as as source code dumps, and that's what was voted on. We did not vote on histories, and a case can be made that source code histories are less safe to import, as we don't review the whole history, but instead the latest state - the patch.

Unless strictly needed, I would suggest that we import just the latest state, not the repository history.

Robert

Re: Where do we put new git modules?

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

On Tue, 2018-01-09 at 16:55 +0100, Bertrand Delacretaz wrote:
> On Tue, Jan 9, 2018 at 4:48 PM, Stefan Seifert <sseifert@pro-vision.d
> e> wrote:
> > ...it makes it more difficult if the contribution was already
> > developed in a standalone git
> > repo outside the ASF and perhaps there is already a commit history
> > we want preserve...
> 
> I don't think we are interested in the history of those donations in
> general.
> 
> If a special case needs that we can always handle it in a different
> way.

This got me thinking for a little bit. Donations were always done as as
source code dumps, and that's what was voted on. We did not vote on
histories, and a case can be made that source code histories are less
safe to import, as we don't review the whole history, but instead the
latest state - the patch.

Unless strictly needed, I would suggest that we import just the latest
state, not the repository history.

Robert

Re: Where do we put new git modules?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Jan 9, 2018 at 4:48 PM, Stefan Seifert <ss...@pro-vision.de> wrote:
> ...it makes it more difficult if the contribution was already developed in a standalone git
> repo outside the ASF and perhaps there is already a commit history we want preserve...

I don't think we are interested in the history of those donations in general.

If a special case needs that we can always handle it in a different way.

-Bertrand

RE: Where do we put new git modules?

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

>On Tue, Jan 9, 2018 at 1:47 PM, Robert Munteanu <ro...@apache.org> wrote:
>> ...- place it in the whiteboard and move it to a proper repo before its
>> first release, with the release manager proposing a name..
>
>+1, it's simple and leaves time to make a proper naming decision.
>
>-Bertrand

yes, this would avoid making the naming decision early, or even the decision to release it at all.
on the other hand it makes it more difficult if the contribution was already developed in a standalone git repo outside the ASF and perhaps there is already a commit history we want preserve - getting this into the whiteboard master branch in a subdirectory is complicated.

or do you propose a new branch for each contribution in the whiteboard, not related to it's master branch at all?
having everything in the master branch also makes it difficult to split it later (yes i know, it's possible in git, but still requires more effort then just having one branch per module).

having one branch per contrib/whiteboard module may seem unorthodox on the first sight, but might come very handy when it's moved later, and also for the first import.

stefan

Re: Where do we put new git modules?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Jan 9, 2018 at 1:47 PM, Robert Munteanu <ro...@apache.org> wrote:
> ...- place it in the whiteboard and move it to a proper repo before its
> first release, with the release manager proposing a name..

+1, it's simple and leaves time to make a proper naming decision.

-Bertrand