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.

[image: Inline image 1]

^ screencap from today: unchanged :(

On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

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

Reply via email to