Re: Migration of remaining plugins to Git

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Migration of remaining plugins to Git

Paul Hammant
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

Reply | Threaded
Open this post in threaded view
|

Re: Migration of remaining plugins to Git

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

Re: Migration of remaining plugins to Git

Hervé BOUTEMY
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]

Reply | Threaded
Open this post in threaded view
|

Re: Migration of remaining plugins to Git

Arnaud Héritier
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.

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