Polite, yes, just non commital ;-) On Sun 18 Jun 2017 at 23:10, Paul Hammant <p...@hammant.org> 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 < > stephen.alan.conno...@gmail.com> 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 <p...@hammant.org> wrote: > > > > > Good thought. We could ask about a timeline. > > > > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> 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 <p...@hammant.org> 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 < > > herve.bout...@free.fr > > > > > > > > > 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: dev-unsubscr...@maven.apache.org > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > > > --------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > -- > > > > Sent from my phone > > > > > > > > > > -- Sent from my phone
