Re: Migration of remaining plugins to Git

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Michael Osipov-2
Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> In order to be able to build a composite 'trunk' for all components of
> maven (that are org.apache.*) can we move the remaining things left in
> Subversion to Git, and mirror them to Github?
>
> `git submodule` (etc) would be how we'd recreate a developer experience
> that felt like a single trunk that would be cloneable in a single command.

This have been discussed, afaik, for the plugins already. That would
result in an explosion of repositories. It wasn't worthwhile.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Hervé BOUTEMY
yes, git is really ubiquitous now and nowadays could perhaps help some
contributions
here is our tracking of git migration [1]

there are a few entries that we could move if someone takes the job:
Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release

there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to many
git repos that are documented but not solved yet
Plugins and shared components are the 2 big repos, with respectively 41 and 26
parts if we switch to git that look hard to manage if we don't have a plan.
Perphaps Jenkins pipelines could provide some solutions on the Jenkins side.

Skins is perhaps not an issue any more now that we deprecated 3 old skins,
then only 2 skins remain. Pom would be feasible now that I reworked Maven
parent poms to be only in one global release: just the history migration could
be tricky given this exact rework :)


Then we can move forward:
- just do it for some svn repos
- a plan, particularly on Jenkins side, has to be found for plugins and shared

any taker for some of the work?

Regards,

Hervé


[1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration

[2] https://cwiki.apache.org/confluence/display/MAVEN/Git
+Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos

Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :

> Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > In order to be able to build a composite 'trunk' for all components of
> > maven (that are org.apache.*) can we move the remaining things left in
> > Subversion to Git, and mirror them to Github?
> >
> > `git submodule` (etc) would be how we'd recreate a developer experience
> > that felt like a single trunk that would be cloneable in a single command.
>
> This have been discussed, afaik, for the plugins already. That would
> result in an explosion of repositories. It wasn't worthwhile.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Hervé BOUTEMY
I updated the page to mark in green the repos that are ready to migrate: just
need the job to be done (with the help of infra, I suppose) with immediate one
to one migration

We can in parallel work on organizing more complex 1 to many migration plan

Thank you for your help on this tedious work that exhausted previous
volunteers...

Regards,

Hervé

Le dimanche 18 juin 2017, 12:12:54 CEST Paul Hammant a écrit :

> Choose one to start with, is what I would do.
>
> git svn clone of a trunk only, then make that master. branch/tag history
> can be retained in Subversion but also up on MavenCentral as
> foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> operation by specifying the first Svn commit for the module in question,
> it'll need many hours to iterate over all commits to pluck out the ones
> pertinent to the trunk of that module.
>
> GitHub only allows a single effective 'parent directory' for repos, so
> instead of the general github.com/apache org (and in lieu of
> github.com/apache/maven/<repo-name> which is what you'd actually want), we
> could do github.com/apache-maven/<repo-name>.
>
> I volunteer for some of the work.  Err, maybe I should read those
> confluence pages.
>
> - Paul
>
>
>
> On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <[hidden email]>
>
> wrote:
> > yes, git is really ubiquitous now and nowadays could perhaps help some
> > contributions
> > here is our tracking of git migration [1]
> >
> > there are a few entries that we could move if someone takes the job:
> > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> >
> > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to
> > many
> > git repos that are documented but not solved yet
> > Plugins and shared components are the 2 big repos, with respectively 41
> > and 26
> > parts if we switch to git that look hard to manage if we don't have a
> > plan.
> > Perphaps Jenkins pipelines could provide some solutions on the Jenkins
> > side.
> >
> > Skins is perhaps not an issue any more now that we deprecated 3 old skins,
> > then only 2 skins remain. Pom would be feasible now that I reworked Maven
> > parent poms to be only in one global release: just the history migration
> > could
> > be tricky given this exact rework :)
> >
> >
> > Then we can move forward:
> > - just do it for some svn repos
> > - a plan, particularly on Jenkins side, has to be found for plugins and
> > shared
> >
> > any taker for some of the work?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
> >
> > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > In order to be able to build a composite 'trunk' for all components of
> > > > maven (that are org.apache.*) can we move the remaining things left in
> > > > Subversion to Git, and mirror them to Github?
> > > >
> > > > `git submodule` (etc) would be how we'd recreate a developer
> > > > experience
> > > > that felt like a single trunk that would be cloneable in a single
> >
> > command.
> >
> > > This have been discussed, afaik, for the plugins already. That would
> > > result in an explosion of repositories. It wasn't worthwhile.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Paul Hammant
In reply to this post by Hervé BOUTEMY
Good thought. We could ask about a timeline.

On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
[hidden email]> wrote:

> They are now adding user grouping... I wonder how long before repo grouping
> too
>
> On Sun 18 Jun 2017 at 17:12, Paul Hammant <[hidden email]> wrote:
>
> > Choose one to start with, is what I would do.
> >
> > git svn clone of a trunk only, then make that master. branch/tag history
> > can be retained in Subversion but also up on MavenCentral as
> > foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> > operation by specifying the first Svn commit for the module in question,
> > it'll need many hours to iterate over all commits to pluck out the ones
> > pertinent to the trunk of that module.
> >
> > GitHub only allows a single effective 'parent directory' for repos, so
> > instead of the general github.com/apache org (and in lieu of
> > github.com/apache/maven/<repo-name> which is what you'd actually want),
> we
> > could do github.com/apache-maven/<repo-name>.
> >
> > I volunteer for some of the work.  Err, maybe I should read those
> > confluence pages.
> >
> > - Paul
> >
> >
> >
> > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <[hidden email]>
> > wrote:
> >
> > > yes, git is really ubiquitous now and nowadays could perhaps help some
> > > contributions
> > > here is our tracking of git migration [1]
> > >
> > > there are a few entries that we could move if someone takes the job:
> > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> > >
> > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch)
> to
> > > many
> > > git repos that are documented but not solved yet
> > > Plugins and shared components are the 2 big repos, with respectively 41
> > > and 26
> > > parts if we switch to git that look hard to manage if we don't have a
> > plan.
> > > Perphaps Jenkins pipelines could provide some solutions on the Jenkins
> > > side.
> > >
> > > Skins is perhaps not an issue any more now that we deprecated 3 old
> > skins,
> > > then only 2 skins remain. Pom would be feasible now that I reworked
> Maven
> > > parent poms to be only in one global release: just the history
> migration
> > > could
> > > be tricky given this exact rework :)
> > >
> > >
> > > Then we can move forward:
> > > - just do it for some svn repos
> > > - a plan, particularly on Jenkins side, has to be found for plugins and
> > > shared
> > >
> > > any taker for some of the work?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> > >
> > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > >
> > +Migration#GitMigration-Migratinganaggregatortreeintoa
> collectionofgitrepos
> > >
> > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > > In order to be able to build a composite 'trunk' for all components
> > of
> > > > > maven (that are org.apache.*) can we move the remaining things left
> > in
> > > > > Subversion to Git, and mirror them to Github?
> > > > >
> > > > > `git submodule` (etc) would be how we'd recreate a developer
> > experience
> > > > > that felt like a single trunk that would be cloneable in a single
> > > command.
> > > >
> > > > This have been discussed, afaik, for the plugins already. That would
> > > > result in an explosion of repositories. It wasn't worthwhile.
> > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> --
> Sent from my phone
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Paul Hammant
They're always very polite for things that I ask for, but I can't claim to
have suggested anything that got implemented. I've a better hit-rate with
JetBrains and their IDEs.

- Paul

On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly <
[hidden email]> wrote:

> Liable to get an answer like:
>
> > We don't comment our roadmap publicly I'm afraid
>
> (I've gotten that a couple of times for different things... you'd think
> given that I'm the maintainer of the GitHub Branch Source plugin for
> Jenkins they might - you know - want to help... but alas)
>
> On 18 June 2017 at 10:12, Paul Hammant <[hidden email]> wrote:
>
> > Good thought. We could ask about a timeline.
> >
> > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > [hidden email]> wrote:
> >
> > > They are now adding user grouping... I wonder how long before repo
> > grouping
> > > too
> > >
> > > On Sun 18 Jun 2017 at 17:12, Paul Hammant <[hidden email]> wrote:
> > >
> > > > Choose one to start with, is what I would do.
> > > >
> > > > git svn clone of a trunk only, then make that master. branch/tag
> > history
> > > > can be retained in Subversion but also up on MavenCentral as
> > > > foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> > > > operation by specifying the first Svn commit for the module in
> > question,
> > > > it'll need many hours to iterate over all commits to pluck out the
> ones
> > > > pertinent to the trunk of that module.
> > > >
> > > > GitHub only allows a single effective 'parent directory' for repos,
> so
> > > > instead of the general github.com/apache org (and in lieu of
> > > > github.com/apache/maven/<repo-name> which is what you'd actually
> > want),
> > > we
> > > > could do github.com/apache-maven/<repo-name>.
> > > >
> > > > I volunteer for some of the work.  Err, maybe I should read those
> > > > confluence pages.
> > > >
> > > > - Paul
> > > >
> > > >
> > > >
> > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > yes, git is really ubiquitous now and nowadays could perhaps help
> > some
> > > > > contributions
> > > > > here is our tracking of git migration [1]
> > > > >
> > > > > there are a few entries that we could move if someone takes the
> job:
> > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> > > > >
> > > > > there are issues to fix when migrating 1 svn repo
> (trunk/tags/branch)
> > > to
> > > > > many
> > > > > git repos that are documented but not solved yet
> > > > > Plugins and shared components are the 2 big repos, with
> respectively
> > 41
> > > > > and 26
> > > > > parts if we switch to git that look hard to manage if we don't
> have a
> > > > plan.
> > > > > Perphaps Jenkins pipelines could provide some solutions on the
> > Jenkins
> > > > > side.
> > > > >
> > > > > Skins is perhaps not an issue any more now that we deprecated 3 old
> > > > skins,
> > > > > then only 2 skins remain. Pom would be feasible now that I reworked
> > > Maven
> > > > > parent poms to be only in one global release: just the history
> > > migration
> > > > > could
> > > > > be tricky given this exact rework :)
> > > > >
> > > > >
> > > > > Then we can move forward:
> > > > > - just do it for some svn repos
> > > > > - a plan, particularly on Jenkins side, has to be found for plugins
> > and
> > > > > shared
> > > > >
> > > > > any taker for some of the work?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > >
> > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+
> Migration
> > > > >
> > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > > > >
> > > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> > > collectionofgitrepos
> > > > >
> > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > > > > In order to be able to build a composite 'trunk' for all
> > components
> > > > of
> > > > > > > maven (that are org.apache.*) can we move the remaining things
> > left
> > > > in
> > > > > > > Subversion to Git, and mirror them to Github?
> > > > > > >
> > > > > > > `git submodule` (etc) would be how we'd recreate a developer
> > > > experience
> > > > > > > that felt like a single trunk that would be cloneable in a
> single
> > > > > command.
> > > > > >
> > > > > > This have been discussed, afaik, for the plugins already. That
> > would
> > > > > > result in an explosion of repositories. It wasn't worthwhile.
> > > > > >
> > > > > >
> > > > > > ------------------------------------------------------------
> > > ---------
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------------------------------
> > ---------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > >
> > > --
> > > Sent from my phone
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Paul Hammant
I think the plugins are descoped for a while.

How about  https://github.com/apache-maven/<module-name> ?

Luckily GitHub does 302s just find if things get renamed or moved between
orgs.

- Paul

On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik <[hidden email]>
wrote:

> Paul,
>
> On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant <[hidden email]> wrote:
> > Back from Github's suggestions team: "Currently, we don't have the
> ability
> > to group repos beyond the organization level, but I'll definitely
> consider
> > this a feature request."
>
> Until such time, how about grouping the repositories by name, like
> https://github.com/apache/maven-plugin-<plugin_name>
>
> A number of other projects in Apache have done this, for example
> https://git-wip-us.apache.org/repos/asf?a=project_list&s=
> incubator-predictionio
> or https://gitbox.apache.org/repos/asf?a=project_list&s=
> incubator-openwhisk
>
> - Bindul
>
> >
> > - Paul
> >
> > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant <[hidden email]> wrote:
> >>
> >> I met Chris Wanstrath at a meetup in Cincinatti about four years ago,
> and
> >> bent his ear about how fantastic Github-Pages (and Jekyll) was as a
> CMS. I
> >> suggested that if they could add themes for "high school", "community
> >> group", etc they could pull in another category of user of the
> platform, and
> >> that the themes that are available for gh-pages are not that useful as
> they
> >> are.
> >>
> >>
> >>
> >> ^ screencap from today: unchanged :(
> >>
> >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly
> >> <[hidden email]> wrote:
> >>>
> >>> Polite, yes, just non commital ;-)
> >>>
> >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant <[hidden email]> wrote:
> >>>
> >>> > They're always very polite for things that I ask for, but I can't
> claim
> >>> > to
> >>> > have suggested anything that got implemented. I've a better hit-rate
> >>> > with
> >>> > JetBrains and their IDEs.
> >>> >
> >>> > - Paul
> >>> >
> >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly <
> >>> > [hidden email]> wrote:
> >>> >
> >>> > > Liable to get an answer like:
> >>> > >
> >>> > > > We don't comment our roadmap publicly I'm afraid
> >>> > >
> >>> > > (I've gotten that a couple of times for different things... you'd
> >>> > > think
> >>> > > given that I'm the maintainer of the GitHub Branch Source plugin
> for
> >>> > > Jenkins they might - you know - want to help... but alas)
> >>> > >
> >>> > > On 18 June 2017 at 10:12, Paul Hammant <[hidden email]> wrote:
> >>> > >
> >>> > > > Good thought. We could ask about a timeline.
> >>> > > >
> >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> >>> > > > [hidden email]> wrote:
> >>> > > >
> >>> > > > > They are now adding user grouping... I wonder how long before
> >>> > > > > repo
> >>> > > > grouping
> >>> > > > > too
> >>> > > > >
> >>> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant <[hidden email]>
> >>> > > > > wrote:
> >>> > > > >
> >>> > > > > > Choose one to start with, is what I would do.
> >>> > > > > >
> >>> > > > > > git svn clone of a trunk only, then make that master.
> >>> > > > > > branch/tag
> >>> > > > history
> >>> > > > > > can be retained in Subversion but also up on MavenCentral as
> >>> > > > > > foo-x.y-sources.jar files.  Unless you optimize that
> >>> > > > > > git-svn-clone
> >>> > > > > > operation by specifying the first Svn commit for the module
> in
> >>> > > > question,
> >>> > > > > > it'll need many hours to iterate over all commits to pluck
> out
> >>> > > > > > the
> >>> > > ones
> >>> > > > > > pertinent to the trunk of that module.
> >>> > > > > >
> >>> > > > > > GitHub only allows a single effective 'parent directory' for
> >>> > > > > > repos,
> >>> > > so
> >>> > > > > > instead of the general github.com/apache org (and in lieu of
> >>> > > > > > github.com/apache/maven/<repo-name> which is what you'd
> >>> > > > > > actually
> >>> > > > want),
> >>> > > > > we
> >>> > > > > > could do github.com/apache-maven/<repo-name>.
> >>> > > > > >
> >>> > > > > > I volunteer for some of the work.  Err, maybe I should read
> >>> > > > > > those
> >>> > > > > > confluence pages.
> >>> > > > > >
> >>> > > > > > - Paul
> >>> > > > > >
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <
> >>> > > [hidden email]
> >>> > > > >
> >>> > > > > > wrote:
> >>> > > > > >
> >>> > > > > > > yes, git is really ubiquitous now and nowadays could
> perhaps
> >>> > > > > > > help
> >>> > > > some
> >>> > > > > > > contributions
> >>> > > > > > > here is our tracking of git migration [1]
> >>> > > > > > >
> >>> > > > > > > there are a few entries that we could move if someone takes
> >>> > > > > > > the
> >>> > > job:
> >>> > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools,
> >>> > Release
> >>> > > > > > >
> >>> > > > > > > there are issues to fix when migrating 1 svn repo
> >>> > > (trunk/tags/branch)
> >>> > > > > to
> >>> > > > > > > many
> >>> > > > > > > git repos that are documented but not solved yet
> >>> > > > > > > Plugins and shared components are the 2 big repos, with
> >>> > > respectively
> >>> > > > 41
> >>> > > > > > > and 26
> >>> > > > > > > parts if we switch to git that look hard to manage if we
> >>> > > > > > > don't
> >>> > > have a
> >>> > > > > > plan.
> >>> > > > > > > Perphaps Jenkins pipelines could provide some solutions on
> >>> > > > > > > the
> >>> > > > Jenkins
> >>> > > > > > > side.
> >>> > > > > > >
> >>> > > > > > > Skins is perhaps not an issue any more now that we
> deprecated
> >>> > > > > > > 3
> >>> > old
> >>> > > > > > skins,
> >>> > > > > > > then only 2 skins remain. Pom would be feasible now that I
> >>> > reworked
> >>> > > > > Maven
> >>> > > > > > > parent poms to be only in one global release: just the
> >>> > > > > > > history
> >>> > > > > migration
> >>> > > > > > > could
> >>> > > > > > > be tricky given this exact rework :)
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > Then we can move forward:
> >>> > > > > > > - just do it for some svn repos
> >>> > > > > > > - a plan, particularly on Jenkins side, has to be found for
> >>> > plugins
> >>> > > > and
> >>> > > > > > > shared
> >>> > > > > > >
> >>> > > > > > > any taker for some of the work?
> >>> > > > > > >
> >>> > > > > > > Regards,
> >>> > > > > > >
> >>> > > > > > > Hervé
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+
> >>> > > Migration
> >>> > > > > > >
> >>> > > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> >>> > > > > > >
> >>> > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> >>> > > > > collectionofgitrepos
> >>> > > > > > >
> >>> > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a
> >>> > > > > > > écrit :
> >>> > > > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> >>> > > > > > > > > In order to be able to build a composite 'trunk' for
> all
> >>> > > > components
> >>> > > > > > of
> >>> > > > > > > > > maven (that are org.apache.*) can we move the remaining
> >>> > things
> >>> > > > left
> >>> > > > > > in
> >>> > > > > > > > > Subversion to Git, and mirror them to Github?
> >>> > > > > > > > >
> >>> > > > > > > > > `git submodule` (etc) would be how we'd recreate a
> >>> > > > > > > > > developer
> >>> > > > > > experience
> >>> > > > > > > > > that felt like a single trunk that would be cloneable
> in
> >>> > > > > > > > > a
> >>> > > single
> >>> > > > > > > command.
> >>> > > > > > > >
> >>> > > > > > > > This have been discussed, afaik, for the plugins already.
> >>> > > > > > > > That
> >>> > > > would
> >>> > > > > > > > result in an explosion of repositories. It wasn't
> >>> > > > > > > > worthwhile.
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > > ------------------------------
> ------------------------------
> >>> > > > > ---------
> >>> > > > > > > > To unsubscribe, e-mail: [hidden email]
> >>> > > > > > > > For additional commands, e-mail:
> [hidden email]
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > ------------------------------
> ------------------------------
> >>> > > > ---------
> >>> > > > > > > To unsubscribe, e-mail: [hidden email]
> >>> > > > > > > For additional commands, e-mail: [hidden email]
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > >
> >>> > > > > --
> >>> > > > > Sent from my phone
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>> --
> >>> Sent from my phone
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Arnaud Héritier
+1 for me

On Wed, Jun 21, 2017 at 12:02 AM, Stephen Connolly <
[hidden email]> wrote:

> On Tue 20 Jun 2017 at 20:29, Arnaud Héritier <[hidden email]> wrote:
>
> > Stephen knows more the ASF infra than me to tell if it is possible but in
> > Jenkins we have the notion of organization folder for GitHub which allow
> to
> > automatically browse an org in GitHub and create/update/delete
> > multibranches jobs for each repo. If we can also create shared libraries
> in
> > Jenkins our JenkinsFile could just be a line: buildPlugin() like we do in
> > jenkins project.
> >
>
> Now that I have landed JENKINS-43507 it should be relatively easy for me to
> write a SCMNavigator for the ASF hosted repositories.
>
> That would give us a folder where all jobs for plugins etc would be
> auto-created based on the presence of a Jenkinsfile.
>
> With a shared library we can then give them all a standard build with a
> nice simple Jenkinsfile that is just one line.
>
> If people are interested I can prototype the SCMNavigator
>
>
> > Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY <[hidden email]> a
> > écrit :
> >
> > > as explained in the git migration status [1], the biggest issue with
> > > plugins 1
> > > svn repo to 41 git repo migration is the maintenance of Jenkins job
> > files,
> > > with
> > > their java + maven version matrix.
> > > With Jenkinsfile as worked out in Mavne core, same type of
> configuration
> > > could
> > > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs
> > >
> > > Would it be possible to create an aggregator Jenkins job that would
> > create
> > > the
> > > 41 plugins jobs?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > >
> > +Migration#GitMigration-Migratinganaggregatortreeintoa
> collectionofgitrepos
> > >
> > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit :
> > > > I think the plugins are descoped for a while.
> > > >
> > > > How about  https://github.com/apache-maven/<module-name> ?
> > > >
> > > > Luckily GitHub does 302s just find if things get renamed or moved
> > between
> > > > orgs.
> > > >
> > > > - Paul
> > > >
> > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik <
> > [hidden email]
> > > >
> > > >
> > > > wrote:
> > > > > Paul,
> > > > >
> > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant <[hidden email]>
> > > wrote:
> > > > > > Back from Github's suggestions team: "Currently, we don't have
> the
> > > > >
> > > > > ability
> > > > >
> > > > > > to group repos beyond the organization level, but I'll definitely
> > > > >
> > > > > consider
> > > > >
> > > > > > this a feature request."
> > > > >
> > > > > Until such time, how about grouping the repositories by name, like
> > > > > https://github.com/apache/maven-plugin-<plugin_name>
> > > > >
> > > > > A number of other projects in Apache have done this, for example
> > > > > https://git-wip-us.apache.org/repos/asf?a=project_list&s=
> > > > > incubator-predictionio
> > > > > or https://gitbox.apache.org/repos/asf?a=project_list&s=
> > > > > incubator-openwhisk
> > > > >
> > > > > - Bindul
> > > > >
> > > > > > - Paul
> > > > > >
> > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant <[hidden email]>
> > > wrote:
> > > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four years
> > > ago,
> > > > >
> > > > > and
> > > > >
> > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) was
> as
> > a
> > > > >
> > > > > CMS. I
> > > > >
> > > > > >> suggested that if they could add themes for "high school",
> > > "community
> > > > > >> group", etc they could pull in another category of user of the
> > > > >
> > > > > platform, and
> > > > >
> > > > > >> that the themes that are available for gh-pages are not that
> > useful
> > > as
> > > > >
> > > > > they
> > > > >
> > > > > >> are.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> ^ screencap from today: unchanged :(
> > > > > >>
> > > > > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly
> > > > > >>
> > > > > >> <[hidden email]> wrote:
> > > > > >>> Polite, yes, just non commital ;-)
> > > > > >>>
> > > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant <[hidden email]>
> > > wrote:
> > > > > >>> > They're always very polite for things that I ask for, but I
> > can't
> > > > >
> > > > > claim
> > > > >
> > > > > >>> > to
> > > > > >>> > have suggested anything that got implemented. I've a better
> > > hit-rate
> > > > > >>> > with
> > > > > >>> > JetBrains and their IDEs.
> > > > > >>> >
> > > > > >>> > - Paul
> > > > > >>> >
> > > > > >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly <
> > > > > >>> >
> > > > > >>> > [hidden email]> wrote:
> > > > > >>> > > Liable to get an answer like:
> > > > > >>> > > > We don't comment our roadmap publicly I'm afraid
> > > > > >>> > >
> > > > > >>> > > (I've gotten that a couple of times for different things...
> > > you'd
> > > > > >>> > > think
> > > > > >>> > > given that I'm the maintainer of the GitHub Branch Source
> > > plugin
> > > > >
> > > > > for
> > > > >
> > > > > >>> > > Jenkins they might - you know - want to help... but alas)
> > > > > >>> > >
> > > > > >>> > > On 18 June 2017 at 10:12, Paul Hammant <[hidden email]>
> > > wrote:
> > > > > >>> > > > Good thought. We could ask about a timeline.
> > > > > >>> > > >
> > > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > > > > >>> > > >
> > > > > >>> > > > [hidden email]> wrote:
> > > > > >>> > > > > They are now adding user grouping... I wonder how long
> > > before
> > > > > >>> > > > > repo
> > > > > >>> > > >
> > > > > >>> > > > grouping
> > > > > >>> > > >
> > > > > >>> > > > > too
> > > > > >>> > > > >
> > > > > >>> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant <
> > > [hidden email]>
> > > > > >>> > > > >
> > > > > >>> > > > > wrote:
> > > > > >>> > > > > > Choose one to start with, is what I would do.
> > > > > >>> > > > > >
> > > > > >>> > > > > > git svn clone of a trunk only, then make that master.
> > > > > >>> > > > > > branch/tag
> > > > > >>> > > >
> > > > > >>> > > > history
> > > > > >>> > > >
> > > > > >>> > > > > > can be retained in Subversion but also up on
> > > MavenCentral as
> > > > > >>> > > > > > foo-x.y-sources.jar files.  Unless you optimize that
> > > > > >>> > > > > > git-svn-clone
> > > > > >>> > > > > > operation by specifying the first Svn commit for the
> > > module
> > > > >
> > > > > in
> > > > >
> > > > > >>> > > > question,
> > > > > >>> > > >
> > > > > >>> > > > > > it'll need many hours to iterate over all commits to
> > > pluck
> > > > >
> > > > > out
> > > > >
> > > > > >>> > > > > > the
> > > > > >>> > >
> > > > > >>> > > ones
> > > > > >>> > >
> > > > > >>> > > > > > pertinent to the trunk of that module.
> > > > > >>> > > > > >
> > > > > >>> > > > > > GitHub only allows a single effective 'parent
> > directory'
> > > for
> > > > > >>> > > > > > repos,
> > > > > >>> > >
> > > > > >>> > > so
> > > > > >>> > >
> > > > > >>> > > > > > instead of the general github.com/apache org (and in
> > > lieu of
> > > > > >>> > > > > > github.com/apache/maven/<repo-name> which is what
> > you'd
> > > > > >>> > > > > > actually
> > > > > >>> > > >
> > > > > >>> > > > want),
> > > > > >>> > > >
> > > > > >>> > > > > we
> > > > > >>> > > > >
> > > > > >>> > > > > > could do github.com/apache-maven/<repo-name>.
> > > > > >>> > > > > >
> > > > > >>> > > > > > I volunteer for some of the work.  Err, maybe I
> should
> > > read
> > > > > >>> > > > > > those
> > > > > >>> > > > > > confluence pages.
> > > > > >>> > > > > >
> > > > > >>> > > > > > - Paul
> > > > > >>> > > > > >
> > > > > >>> > > > > >
> > > > > >>> > > > > >
> > > > > >>> > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <
> > > > > >>> > >
> > > > > >>> > > [hidden email]
> > > > > >>> > >
> > > > > >>> > > > > > wrote:
> > > > > >>> > > > > > > yes, git is really ubiquitous now and nowadays
> could
> > > > >
> > > > > perhaps
> > > > >
> > > > > >>> > > > > > > help
> > > > > >>> > > >
> > > > > >>> > > > some
> > > > > >>> > > >
> > > > > >>> > > > > > > contributions
> > > > > >>> > > > > > > here is our tracking of git migration [1]
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > there are a few entries that we could move if
> someone
> > > > > >>> > > > > > > takes
> > > > > >>> > > > > > > the
> > > > > >>> > >
> > > > > >>> > > job:
> > > > > >>> > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin
> > > Tools,
> > > > > >>> >
> > > > > >>> > Release
> > > > > >>> >
> > > > > >>> > > > > > > there are issues to fix when migrating 1 svn repo
> > > > > >>> > >
> > > > > >>> > > (trunk/tags/branch)
> > > > > >>> > >
> > > > > >>> > > > > to
> > > > > >>> > > > >
> > > > > >>> > > > > > > many
> > > > > >>> > > > > > > git repos that are documented but not solved yet
> > > > > >>> > > > > > > Plugins and shared components are the 2 big repos,
> > with
> > > > > >>> > >
> > > > > >>> > > respectively
> > > > > >>> > >
> > > > > >>> > > > 41
> > > > > >>> > > >
> > > > > >>> > > > > > > and 26
> > > > > >>> > > > > > > parts if we switch to git that look hard to manage
> if
> > > we
> > > > > >>> > > > > > > don't
> > > > > >>> > >
> > > > > >>> > > have a
> > > > > >>> > >
> > > > > >>> > > > > > plan.
> > > > > >>> > > > > >
> > > > > >>> > > > > > > Perphaps Jenkins pipelines could provide some
> > > solutions on
> > > > > >>> > > > > > > the
> > > > > >>> > > >
> > > > > >>> > > > Jenkins
> > > > > >>> > > >
> > > > > >>> > > > > > > side.
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > Skins is perhaps not an issue any more now that we
> > > > >
> > > > > deprecated
> > > > >
> > > > > >>> > > > > > > 3
> > > > > >>> >
> > > > > >>> > old
> > > > > >>> >
> > > > > >>> > > > > > skins,
> > > > > >>> > > > > >
> > > > > >>> > > > > > > then only 2 skins remain. Pom would be feasible now
> > > that I
> > > > > >>> >
> > > > > >>> > reworked
> > > > > >>> >
> > > > > >>> > > > > Maven
> > > > > >>> > > > >
> > > > > >>> > > > > > > parent poms to be only in one global release: just
> > the
> > > > > >>> > > > > > > history
> > > > > >>> > > > >
> > > > > >>> > > > > migration
> > > > > >>> > > > >
> > > > > >>> > > > > > > could
> > > > > >>> > > > > > > be tricky given this exact rework :)
> > > > > >>> > > > > > >
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > Then we can move forward:
> > > > > >>> > > > > > > - just do it for some svn repos
> > > > > >>> > > > > > > - a plan, particularly on Jenkins side, has to be
> > found
> > > > > >>> > > > > > > for
> > > > > >>> >
> > > > > >>> > plugins
> > > > > >>> >
> > > > > >>> > > > and
> > > > > >>> > > >
> > > > > >>> > > > > > > shared
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > any taker for some of the work?
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > Regards,
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > Hervé
> > > > > >>> > > > > > >
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > [1]
> > > https://cwiki.apache.org/confluence/display/MAVEN/Git+
> > > > > >>> > >
> > > > > >>> > > Migration
> > > > > >>> > >
> > > > > >>> > > > > > > [2]
> > > https://cwiki.apache.org/confluence/display/MAVEN/Git
> > > > > >>> > > > > >
> > > > > >>> > > > > > +Migration#GitMigration-
> Migratinganaggregatortreeintoa
> > > > > >>> > > > >
> > > > > >>> > > > > collectionofgitrepos
> > > > > >>> > > > >
> > > > > >>> > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael
> > Osipov
> > > a
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > écrit :
> > > > > >>> > > > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > > >>> > > > > > > > > In order to be able to build a composite
> 'trunk'
> > > for
> > > > >
> > > > > all
> > > > >
> > > > > >>> > > > components
> > > > > >>> > > >
> > > > > >>> > > > > > of
> > > > > >>> > > > > >
> > > > > >>> > > > > > > > > maven (that are org.apache.*) can we move the
> > > > > >>> > > > > > > > > remaining
> > > > > >>> >
> > > > > >>> > things
> > > > > >>> >
> > > > > >>> > > > left
> > > > > >>> > > >
> > > > > >>> > > > > > in
> > > > > >>> > > > > >
> > > > > >>> > > > > > > > > Subversion to Git, and mirror them to Github?
> > > > > >>> > > > > > > > >
> > > > > >>> > > > > > > > > `git submodule` (etc) would be how we'd
> recreate
> > a
> > > > > >>> > > > > > > > > developer
> > > > > >>> > > > > >
> > > > > >>> > > > > > experience
> > > > > >>> > > > > >
> > > > > >>> > > > > > > > > that felt like a single trunk that would be
> > > cloneable
> > > > >
> > > > > in
> > > > >
> > > > > >>> > > > > > > > > a
> > > > > >>> > >
> > > > > >>> > > single
> > > > > >>> > >
> > > > > >>> > > > > > > command.
> > > > > >>> > > > > > >
> > > > > >>> > > > > > > > This have been discussed, afaik, for the plugins
> > > > > >>> > > > > > > > already.
> > > > > >>> > > > > > > > That
> > > > > >>> > > >
> > > > > >>> > > > would
> > > > > >>> > > >
> > > > > >>> > > > > > > > result in an explosion of repositories. It wasn't
> > > > > >>> > > > > > > > worthwhile.
> > > > > >>> > > > > > > >
> > > > > >>> > > > > > > >
> > > > > >>> > > > > > > >
> > > > > >>> > > > > > > > ------------------------------
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > >>> > > > > ---------
> > > > > >>> > > > >
> > > > > >>> > > > > > > > To unsubscribe, e-mail:
> > > [hidden email]
> > > > >
> > > > > >>> > > > > > > > For additional commands, e-mail:
> > > > > [hidden email]
> > > > >
> > > > > >>> > > > > > > ------------------------------
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > >>> > > > ---------
> > > > > >>> > > >
> > > > > >>> > > > > > > To unsubscribe, e-mail:
> > > [hidden email]
> > > > > >>> > > > > > > For additional commands, e-mail:
> > > [hidden email]
> > > > > >>> > > > >
> > > > > >>> > > > > --
> > > > > >>> > > > > Sent from my phone
> > > > > >>>
> > > > > >>> --
> > > > > >>> Sent from my phone
> > > > >
> > > > > ------------------------------------------------------------
> ---------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
> --
> Sent from my phone
>



--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Loading...