You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2017/10/17 09:52:03 UTC
[git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Hi,
The discussions with infra are settling and I would like to schedule
the migration for tomorrow evening at 22:00 CEST. I am not sure of the
"downtime", but hopefully it won't be more than a couple of hours.
Some final notes:
- there is no access to features that require administrative access to
the repos. That includes, but not limited to: travis integration,
setting descriptions, tags, certain kinds of bots.
- infra is ok with this migration, but is likely to be overwhelmed if
we are going to have requests that require manual intervention to our
200+ repositories. We are expected to assist ( e.g. by providing
scripts ) should too many repositories need attention or break
- there is at least one project that is scaling down its number of git
repositories (couchdb), mainly due to (quoting):
a) PRs on different repos for the same semantic change need unusual
coordination to land, intermittent CI will break, or needs
extra tooling.
b) Keeping main dependency list updated by hand is tedious (can be
automated tho).
c) Doing branches/tags/releases synchronised across all repos is a
pain (can be automated, but is an extra layer of hassle either way).
For me personally all of these are fine, and I expect that the
improvements brought by Git will offset the downsides. I want to make
sure though that everyone is aware of these and and considers that the
SVN to Git migration can proceed.
Please speak up if you find something of concern.
Thanks,
Robert
RE: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Stefan Seifert <ss...@pro-vision.de>.
+1
>-----Original Message-----
>From: Julian Sedding [mailto:jsedding@gmail.com]
>Sent: Tuesday, October 17, 2017 12:30 PM
>To: Sling Developers List <de...@sling.apache.org>
>Subject: Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
>
>Please go ahead with the migration.
>
>Thanks
>Julian
>
>On Tue, Oct 17, 2017 at 12:12 PM, Bertrand Delacretaz
><bd...@apache.org> wrote:
>> On Tue, Oct 17, 2017 at 11:52 AM, Robert Munteanu <ro...@apache.org>
>wrote:
>>> ...I want to make
>>> sure though that everyone is aware of these and and considers that the
>>> SVN to Git migration can proceed...
>>
>> I'm fine with that, thanks!
>>
>> -Bertrand
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Julian Sedding <js...@gmail.com>.
Please go ahead with the migration.
Thanks
Julian
On Tue, Oct 17, 2017 at 12:12 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Tue, Oct 17, 2017 at 11:52 AM, Robert Munteanu <ro...@apache.org> wrote:
>> ...I want to make
>> sure though that everyone is aware of these and and considers that the
>> SVN to Git migration can proceed...
>
> I'm fine with that, thanks!
>
> -Bertrand
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Oct 17, 2017 at 11:52 AM, Robert Munteanu <ro...@apache.org> wrote:
> ...I want to make
> sure though that everyone is aware of these and and considers that the
> SVN to Git migration can proceed...
I'm fine with that, thanks!
-Bertrand
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Oct 18, 2017 at 2:20 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...Do we now have to contact infra before we can create a new module ?..
https://gitbox.apache.org has a link to create new repositories.
-Bertrand
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2017-10-18 at 13:20 +0100, Ian Boston wrote:
> Also, I assume any existing Pull requests will have to be ported to
> the new
> structure, and if they cover multiple repositories they will have to
> be
> synchronized to prevent breaking builds.
I posted a couple of weeks ago a message on every pull request asking
submitters to make sure their pull requests are available locally as
that repository will be going away.
Unfortunately I can't move over the pull requests to the new repos and
"soon", probably this week, after the migration is done, the old Sling
github repo will be taken down and replaced.
Robert
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
Does that mean, every repo will have 1 pom.xml file and no more than one ?
If so, what will be the steps for creating a new module in say
contrib/extensions be ?
Currently its
mkdir
edit/build/test commit.
Do we now have to contact infra before we can create a new module ?
Also, I assume any existing Pull requests will have to be ported to the new
structure, and if they cover multiple repositories they will have to be
synchronized to prevent breaking builds.
Best Regards
Ian
On 18 October 2017 at 12:56, Oliver Lietz <ap...@oliverlietz.de> wrote:
> On Tuesday 17 October 2017 23:16:30 Robert Munteanu wrote:
> > On Tue, 2017-10-17 at 16:22 +0300, Robert Munteanu wrote:
> > > On Tue, 2017-10-17 at 13:03 +0000, Justin Edelson wrote:
> > > > On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <rombert@apache.org
> > > >
> > > > wrote:
> > > > > Perhaps the people that actually work with these multi-project
> > > > > extensions would like to comment? By a quick check we have:
> > > > >
> > > > > - models
> > > >
> > > > The models bundles can be released independently, i.e. I've done a
> > > > number
> > > > of releases of the implementation bundle without touching the API
> > > > bundle.
> > > >
> > > > While Konrad is correct that ITs are an issue, my strong preference
> > > > with
> > > > Sling Models is to minimize the use of ITs, i.e. use them only for
> > > > code
> > > > paths which are difficult to test via a unit test, so I don't
> > > > really
> > > > see
> > > > that as an issue.
> > >
> > > +1, ideally most changes would be covered by an unit test, not an
> > > integration test. Even so, validation has its pax-exam ITs in the
> > > core
> > > bundle, only the test content is outside of the bundle.
> >
> > Any other comments? At this point I'm inclined to go with git
> > repository per module, given that we should cover fixes with
> > integration tests rather than unit tests.
>
> I guess we are able to also move the test services into the core module and
> create a bundle for them with Tiny Bundles (already discussed in the past
> but
> no time for implementing it so far).
>
> Strong +1 for one Git repo per module (to keep it simple also).
>
> Thanks again for your great work, Robert!
>
> Regards,
> O.
>
> > Thanks,
> >
> > Robert
>
>
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Tuesday 17 October 2017 23:16:30 Robert Munteanu wrote:
> On Tue, 2017-10-17 at 16:22 +0300, Robert Munteanu wrote:
> > On Tue, 2017-10-17 at 13:03 +0000, Justin Edelson wrote:
> > > On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <rombert@apache.org
> > >
> > > wrote:
> > > > Perhaps the people that actually work with these multi-project
> > > > extensions would like to comment? By a quick check we have:
> > > >
> > > > - models
> > >
> > > The models bundles can be released independently, i.e. I've done a
> > > number
> > > of releases of the implementation bundle without touching the API
> > > bundle.
> > >
> > > While Konrad is correct that ITs are an issue, my strong preference
> > > with
> > > Sling Models is to minimize the use of ITs, i.e. use them only for
> > > code
> > > paths which are difficult to test via a unit test, so I don't
> > > really
> > > see
> > > that as an issue.
> >
> > +1, ideally most changes would be covered by an unit test, not an
> > integration test. Even so, validation has its pax-exam ITs in the
> > core
> > bundle, only the test content is outside of the bundle.
>
> Any other comments? At this point I'm inclined to go with git
> repository per module, given that we should cover fixes with
> integration tests rather than unit tests.
I guess we are able to also move the test services into the core module and
create a bundle for them with Tiny Bundles (already discussed in the past but
no time for implementing it so far).
Strong +1 for one Git repo per module (to keep it simple also).
Thanks again for your great work, Robert!
Regards,
O.
> Thanks,
>
> Robert
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2017-10-17 at 16:22 +0300, Robert Munteanu wrote:
> On Tue, 2017-10-17 at 13:03 +0000, Justin Edelson wrote:
> > On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <rombert@apache.org
> > >
> > wrote:
> >
> > >
> > >
> > > Perhaps the people that actually work with these multi-project
> > > extensions would like to comment? By a quick check we have:
> > >
> > > - models
> > >
> > >
> >
> > The models bundles can be released independently, i.e. I've done a
> > number
> > of releases of the implementation bundle without touching the API
> > bundle.
> >
> > While Konrad is correct that ITs are an issue, my strong preference
> > with
> > Sling Models is to minimize the use of ITs, i.e. use them only for
> > code
> > paths which are difficult to test via a unit test, so I don't
> > really
> > see
> > that as an issue.
>
> +1, ideally most changes would be covered by an unit test, not an
> integration test. Even so, validation has its pax-exam ITs in the
> core
> bundle, only the test content is outside of the bundle.
Any other comments? At this point I'm inclined to go with git
repository per module, given that we should cover fixes with
integration tests rather than unit tests.
Thanks,
Robert
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2017-10-17 at 13:03 +0000, Justin Edelson wrote:
> On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <ro...@apache.org>
> wrote:
>
> >
> >
> > Perhaps the people that actually work with these multi-project
> > extensions would like to comment? By a quick check we have:
> >
> > - models
> >
> >
>
> The models bundles can be released independently, i.e. I've done a
> number
> of releases of the implementation bundle without touching the API
> bundle.
>
> While Konrad is correct that ITs are an issue, my strong preference
> with
> Sling Models is to minimize the use of ITs, i.e. use them only for
> code
> paths which are difficult to test via a unit test, so I don't really
> see
> that as an issue.
+1, ideally most changes would be covered by an unit test, not an
integration test. Even so, validation has its pax-exam ITs in the core
bundle, only the test content is outside of the bundle.
Robert
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Oct 17, 2017 at 10:19 PM, Stefan Seifert <ss...@pro-vision.de> wrote:
>
>
>>-----Original Message-----
>>From: Justin Edelson [mailto:justin@justinedelson.com]
>>Sent: Tuesday, October 17, 2017 3:04 PM
>>To: dev@sling.apache.org
>>Subject: Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final
>>notes
>>
>>On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <ro...@apache.org> wrote:
>>
>>>
>>>
>>> Perhaps the people that actually work with these multi-project
>>> extensions would like to comment? By a quick check we have:
>>>
>>> - models
>>>
>>>
>>The models bundles can be released independently, i.e. I've done a number
>>of releases of the implementation bundle without touching the API bundle.
>>
>>While Konrad is correct that ITs are an issue, my strong preference with
>>Sling Models is to minimize the use of ITs, i.e. use them only for code
>>paths which are difficult to test via a unit test, so I don't really see
>>that as an issue.
>
> +1 to stick with git-repo-per-module
>
> same applies to caconfig - 95% of tests are unit tests, only few integration tests to make sure all is working together
>
> stefan
+1 to stick with git-repo-per-module
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
RE: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Stefan Seifert <ss...@pro-vision.de>.
>-----Original Message-----
>From: Justin Edelson [mailto:justin@justinedelson.com]
>Sent: Tuesday, October 17, 2017 3:04 PM
>To: dev@sling.apache.org
>Subject: Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final
>notes
>
>On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <ro...@apache.org> wrote:
>
>>
>>
>> Perhaps the people that actually work with these multi-project
>> extensions would like to comment? By a quick check we have:
>>
>> - models
>>
>>
>The models bundles can be released independently, i.e. I've done a number
>of releases of the implementation bundle without touching the API bundle.
>
>While Konrad is correct that ITs are an issue, my strong preference with
>Sling Models is to minimize the use of ITs, i.e. use them only for code
>paths which are difficult to test via a unit test, so I don't really see
>that as an issue.
+1 to stick with git-repo-per-module
same applies to caconfig - 95% of tests are unit tests, only few integration tests to make sure all is working together
stefan
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Justin Edelson <ju...@justinedelson.com>.
On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <ro...@apache.org> wrote:
>
>
> Perhaps the people that actually work with these multi-project
> extensions would like to comment? By a quick check we have:
>
> - models
>
>
The models bundles can be released independently, i.e. I've done a number
of releases of the implementation bundle without touching the API bundle.
While Konrad is correct that ITs are an issue, my strong preference with
Sling Models is to minimize the use of ITs, i.e. use them only for code
paths which are difficult to test via a unit test, so I don't really see
that as an issue.
Regards,
Justin
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Konrad Windszus <ko...@gmx.de>.
I see the main issues with a tighter coupling of API and Impl with the according IT module or test-services bundle.
In the best case every bugfix or new feature should also be reflected in the ITs.
So after thinking a bit more about it, I think it is fine to derive from our general 1 module = 1 git repository pattern for at least
1. validation
2. models
3. healthcheck
and maybe some others where the ITs are in a dedicated module and not in the generic launchpad testing.
That way it is much easier to encourage people to also contribute to ITs (because opening two PRs, one for the actual feature/bugfix and another one for the IT is a lot of hassle). Also checking the PRs becomes easier, because the reactor build will also build and execute the ITs.
Konrad
> Am 17.10.2017 um 14:49 schrieb Robert Munteanu <ro...@apache.org>:
>
> Hi Christian,
>
> Thanks for bringing this to the dev list. I have seen part of this
> argument from various people, but until now no one has decided to
> actually write about it :-)
>
> On Tue, 2017-10-17 at 13:49 +0200, Christian Schneider wrote:
>> I am bit concerned about the number of repositories we are about to
>> create
>> on git and the relation between them.
>>
>> Lets take an extension as an example:
>>
>> validation
>> - reactor
>> - api
>> - core
>> - examples
>> - test-services
>>
>> If I understand correctly then we plan to create one git repo for
>> each
>> module above. So it would be 5 repos for the validation extension.
>>
>> I think this is quite problematic for several reasons.
>> - If you change something in validation you often will change more
>> than one
>> of the modules above.
>> - Like in svn today you can easily forget to update dependencies
>> after a
>> release. This results in the build not working anymore after the old
>> snapshots are discarded by nexus. Addtionally you build with a
>> potentially
>> wrong set of dependencies in the meantime. In git this is even more
>> problematic as you need to update several repos then to make changes
>> instead just several directories in one svn tree.
>> - It is difficult to do a build of the whole validation extension
>
> Well, these are 4 repositories, there will not be a validation.reactor
> modules. I don't think the examples change a lot, and we should
> probably move all examples/samples to the 'sling-samples' repo, where
> they are more visible ( personal opinion, nothing discussed/decided yet
> ). So I would not count examples as a repository that creates overhead.
>
> Indeed, there can be scenarios where api + impl or api + impl + tests
> need to change together. My gut feeling though is that they don't
> happen that often. And many of our modules have 'in-module' integration
> tests, where there is no test content outside of the bundle.
>
> For checking out and building multiple grouped projects we would like
> to use a tool such as google repo. See [1] and [2] for some rough
> ideas. In the same way we can generate one of more aggregator poms.
>
> What does remain mostly uncovered is commits and pushes to multiple
> repositories. There you indeed have to perform multiple commits. But
> I'd argue that either:
>
> - impl changes frequently, api does not ; not a problem for us
> - impl changes frequently, api changes as well; looks like api and impl
> are really tied together so should they really be separate bundles?
>
>
>> So I propose to rather use one repository per extension. Additionally
>> I
>> would also version and release the whole extension together.
>> - This makes it easy to do and test changes that reach over more than
>> one
>> module
>> - The release process is much easier and you can not forget to update
>> dependencies
>>
>> Of course such a model creates some unnecessary artifacts in a
>> release. For
>> example you would get a new api bundle even when there are no changes
>> in
>> it. This is not very problematic though as we already version APIs on
>> package level. So the user would still have full backwards
>> compatibility.
>>
>> The difficult task in this model is of course which modules to bundle
>> together in a repo. I think for extensions this is obvious but for
>> other
>> parts of sling it is less clear.
>>
>> As a good example that this approach can work see the apache aries
>> project.
>> In Aries we used to release each bundle individually. This created
>> the same
>> problems as in sling. We moved some projects to git but on a coarse
>> grained
>> level and it seems to work quite well.
>>
>> See these projects as examples:
>> https://github.com/apache/aries-rsa
>> https://github.com/apache/aries-jpa
>
> The problems we can encounter are mostly build related, and not
> affected by releases. If this model is working for Aries we can
> consider it. I do not oppose it, even though my preference is
> different.
>
> Perhaps the people that actually work with these multi-project
> extensions would like to comment? By a quick check we have:
>
> - caconfig
> - healthchek
> - models
> - sightly
> - validation
>
> as reactor poms with more than 2 modules in the /bundles subtree.
>
> Thanks,
>
> Robert
>
>>
>> Each of those projects can be built in one step and the build is
>> always
>> consistently using the correct versions. A release can be done on top
>> level
>> in one step. Still for example the Aries RSA spi is still at package
>> version 1.0.0. So external projects that build on it will still be
>> compatible with the newest Aries RSA release.
>>
>> I know I am a it late to the party with my proposal but Robert
>> encouraged
>> me to still come up with it as after the move to git it will be too
>> late.
>
> [1]: https://cwiki.apache.org/confluence/display/SLING/Move+from+Subver
> sion+to+Git
> [2]: https://issues.apache.org/jira/browse/SLING-7164
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Robert Munteanu <ro...@apache.org>.
Hi Christian,
Thanks for bringing this to the dev list. I have seen part of this
argument from various people, but until now no one has decided to
actually write about it :-)
On Tue, 2017-10-17 at 13:49 +0200, Christian Schneider wrote:
> I am bit concerned about the number of repositories we are about to
> create
> on git and the relation between them.
>
> Lets take an extension as an example:
>
> validation
> - reactor
> - api
> - core
> - examples
> - test-services
>
> If I understand correctly then we plan to create one git repo for
> each
> module above. So it would be 5 repos for the validation extension.
>
> I think this is quite problematic for several reasons.
> - If you change something in validation you often will change more
> than one
> of the modules above.
> - Like in svn today you can easily forget to update dependencies
> after a
> release. This results in the build not working anymore after the old
> snapshots are discarded by nexus. Addtionally you build with a
> potentially
> wrong set of dependencies in the meantime. In git this is even more
> problematic as you need to update several repos then to make changes
> instead just several directories in one svn tree.
> - It is difficult to do a build of the whole validation extension
Well, these are 4 repositories, there will not be a validation.reactor
modules. I don't think the examples change a lot, and we should
probably move all examples/samples to the 'sling-samples' repo, where
they are more visible ( personal opinion, nothing discussed/decided yet
). So I would not count examples as a repository that creates overhead.
Indeed, there can be scenarios where api + impl or api + impl + tests
need to change together. My gut feeling though is that they don't
happen that often. And many of our modules have 'in-module' integration
tests, where there is no test content outside of the bundle.
For checking out and building multiple grouped projects we would like
to use a tool such as google repo. See [1] and [2] for some rough
ideas. In the same way we can generate one of more aggregator poms.
What does remain mostly uncovered is commits and pushes to multiple
repositories. There you indeed have to perform multiple commits. But
I'd argue that either:
- impl changes frequently, api does not ; not a problem for us
- impl changes frequently, api changes as well; looks like api and impl
are really tied together so should they really be separate bundles?
> So I propose to rather use one repository per extension. Additionally
> I
> would also version and release the whole extension together.
> - This makes it easy to do and test changes that reach over more than
> one
> module
> - The release process is much easier and you can not forget to update
> dependencies
>
> Of course such a model creates some unnecessary artifacts in a
> release. For
> example you would get a new api bundle even when there are no changes
> in
> it. This is not very problematic though as we already version APIs on
> package level. So the user would still have full backwards
> compatibility.
>
> The difficult task in this model is of course which modules to bundle
> together in a repo. I think for extensions this is obvious but for
> other
> parts of sling it is less clear.
>
> As a good example that this approach can work see the apache aries
> project.
> In Aries we used to release each bundle individually. This created
> the same
> problems as in sling. We moved some projects to git but on a coarse
> grained
> level and it seems to work quite well.
>
> See these projects as examples:
> https://github.com/apache/aries-rsa
> https://github.com/apache/aries-jpa
The problems we can encounter are mostly build related, and not
affected by releases. If this model is working for Aries we can
consider it. I do not oppose it, even though my preference is
different.
Perhaps the people that actually work with these multi-project
extensions would like to comment? By a quick check we have:
- caconfig
- healthchek
- models
- sightly
- validation
as reactor poms with more than 2 modules in the /bundles subtree.
Thanks,
Robert
>
> Each of those projects can be built in one step and the build is
> always
> consistently using the correct versions. A release can be done on top
> level
> in one step. Still for example the Aries RSA spi is still at package
> version 1.0.0. So external projects that build on it will still be
> compatible with the newest Aries RSA release.
>
> I know I am a it late to the party with my proposal but Robert
> encouraged
> me to still come up with it as after the move to git it will be too
> late.
[1]: https://cwiki.apache.org/confluence/display/SLING/Move+from+Subver
sion+to+Git
[2]: https://issues.apache.org/jira/browse/SLING-7164
Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes
Posted by Christian Schneider <ch...@die-schneider.net>.
I am bit concerned about the number of repositories we are about to create
on git and the relation between them.
Lets take an extension as an example:
validation
- reactor
- api
- core
- examples
- test-services
If I understand correctly then we plan to create one git repo for each
module above. So it would be 5 repos for the validation extension.
I think this is quite problematic for several reasons.
- If you change something in validation you often will change more than one
of the modules above.
- Like in svn today you can easily forget to update dependencies after a
release. This results in the build not working anymore after the old
snapshots are discarded by nexus. Addtionally you build with a potentially
wrong set of dependencies in the meantime. In git this is even more
problematic as you need to update several repos then to make changes
instead just several directories in one svn tree.
- It is difficult to do a build of the whole validation extension
So I propose to rather use one repository per extension. Additionally I
would also version and release the whole extension together.
- This makes it easy to do and test changes that reach over more than one
module
- The release process is much easier and you can not forget to update
dependencies
Of course such a model creates some unnecessary artifacts in a release. For
example you would get a new api bundle even when there are no changes in
it. This is not very problematic though as we already version APIs on
package level. So the user would still have full backwards compatibility.
The difficult task in this model is of course which modules to bundle
together in a repo. I think for extensions this is obvious but for other
parts of sling it is less clear.
As a good example that this approach can work see the apache aries project.
In Aries we used to release each bundle individually. This created the same
problems as in sling. We moved some projects to git but on a coarse grained
level and it seems to work quite well.
See these projects as examples:
https://github.com/apache/aries-rsa
https://github.com/apache/aries-jpa
Each of those projects can be built in one step and the build is always
consistently using the correct versions. A release can be done on top level
in one step. Still for example the Aries RSA spi is still at package
version 1.0.0. So external projects that build on it will still be
compatible with the newest Aries RSA release.
I know I am a it late to the party with my proposal but Robert encouraged
me to still come up with it as after the move to git it will be too late.
Best
Christian
2017-10-17 11:52 GMT+02:00 Robert Munteanu <ro...@apache.org>:
> Hi,
>
> The discussions with infra are settling and I would like to schedule
> the migration for tomorrow evening at 22:00 CEST. I am not sure of the
> "downtime", but hopefully it won't be more than a couple of hours.
>
> Some final notes:
>
> - there is no access to features that require administrative access to
> the repos. That includes, but not limited to: travis integration,
> setting descriptions, tags, certain kinds of bots.
> - infra is ok with this migration, but is likely to be overwhelmed if
> we are going to have requests that require manual intervention to our
> 200+ repositories. We are expected to assist ( e.g. by providing
> scripts ) should too many repositories need attention or break
> - there is at least one project that is scaling down its number of git
> repositories (couchdb), mainly due to (quoting):
>
> a) PRs on different repos for the same semantic change need unusual
> coordination to land, intermittent CI will break, or needs
> extra tooling.
> b) Keeping main dependency list updated by hand is tedious (can be
> automated tho).
> c) Doing branches/tags/releases synchronised across all repos is a
> pain (can be automated, but is an extra layer of hassle either way).
>
> For me personally all of these are fine, and I expect that the
> improvements brought by Git will offset the downsides. I want to make
> sure though that everyone is aware of these and and considers that the
> SVN to Git migration can proceed.
>
> Please speak up if you find something of concern.
>
> Thanks,
>
> Robert
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Computer Scientist
http://www.adobe.com