Re: Migration of remaining plugins to Git

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

Hervé BOUTEMY
In reply to this post by Michael Osipov-2
I was thinking at something like the Maven Jenkins Seeding experiment [1] that
was done, with its DSL code [2]

IIUC, this new Jenkins feature could provide a more generic seeding?
Looks promising.

Whether we go with first or second option will be a matter of ETA and people
wanting to work on it: I'm supportive of both approaches :)

Regards,

Hervé

[1] https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkins-seeding/

[2] http://svn.apache.org/viewvc/maven/jenkins-seeding/

Le mardi 20 juin 2017, 22:02:14 CEST Stephen Connolly a écrit :

> 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-Migratinganaggregatortreeintoacollectionofgitrepos
> >
> > > 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



---------------------------------------------------------------------
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
OK, I tried something new.

*Goal*: all the plugins in one Git repo (less CI jobs to set up - just one
recursive multi-module maven build).
*Constraint*: Plugins must be independently releasable.

*Test:* Take two modules from the Svn repo and check them in to master (the
rest were deleted - test needs two and a parent pom in master).

*Repository*: https://github.com/paul-hammant/ph_testplugins

Of the two modules checked in, maven-changes-plugin is the one I attempted
to release to my com/paulhammant/ group on 'Central. The workflow for the
release of that single module is here
https://github.com/paul-hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md

*Result of Test:* failed, but in a surprising way and at a very late stage

During the release:perform stage the maven tried to push to
https://oss.sonatype.org/content/repositories/snapshots
/com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar
which is nuts because I'm not trying to push to a SNAPSHOT, I'm trying to
do a proper release of 3.0.0 (of my renamed to an obscure name plugin).

The documentation for the <scm> part of the pom says that it honors the
name of the local branch for the sequence of commits that the release
plugin does. Which is exactly what you'd want. I've already tested it a
dozen times and it does the right thing by way of tags too.  It's only that
SNAPSHOT weirdness during the upload that ends the experiment, and that's a
fairly late stage piece. My plan was to go onto oss.sonatype.org and delete
it from staging so it would ultimately go nowhere.

Barring that bug, this would work for all of the Maven plugins in a single
repo, meaning a lot less permutations for CI, albeit with a longer build
per commit. I don't think that last is a big issue for this proposed
repository.

Any of you could clone the repo I have made, and do the same steps as
CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I got
to (a 401 error from Sonatype's DAV infra). And one of you could tell me
what I did wrong with the setup to encounter that snapshot issue :)

- Paul
Loading...