you're confident that it can scale to the size we're expecting when
we're
splitting the current aggregator svn to many small git repos
that's it?
Regards,
Hervé
Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:
> > TLDR; =
> > Perhaps we can start with 2 proofs of concept:
> > 1. full git clone + Jenkins jobs for the 7 existing git repos (with
6
> > additional ones in 2 days)
> > 2. git split of one of the aggregator svn trunk: skins or
doxia-tools
can
> > be
> > easy choices since they are light, where plugins or shared are
perhaps
too
> > heavy. The one working on this PoC will make his choice
> >
> > then more detailed answer inline that lead to this PoCs proposal
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit :
> > > I don't think the devs would work on all artifacts(projects) a
time.
> >
> > sure, I think I'm one of the few people working on near everything
(with
> > rare
> > exceptions like Surefire, as you noticed :) )
> > but for usual contributor, there is no issue
> >
> > I'm not a git expert, then I don't know if easy "full Maven clone"
is
> > better
> > done with a shell script or some git modules
> >
> > > If the naming convention of repo for a plugin would be artifactId,
like
> > > /maven-clean-plugin, then even easy to figure out which one to
clone.
> > > The most likely the dev would just clone one repo she/he is
interested
> > > in
> > > at the moment, i.e. repository /maven-clean-plugin, let's say.
> > > It's good to avoid any shared files across them, even I don't
think
devs
> > > share some in svn today. The release process would be quite usual,
i.e.
> >
> > one
> >
> > > repo = one project, and new devs already have these experiences
which
> >
> > will
> >
> > > be simple for them to adapt faster.
> >
> > +1
> > the only drawback I see currently is that there is no natural
grouping,
> > then
> > we have a flat lit of near 100 git repos without the current
structure
> > (plugins, shared components, skins, ...): I think components
structure
is
> > useful for maintenability
> > but not really a complete showstopper
> > and perhaps the "Maven full clone" tooling can re-create some
grouping
to
> > keep
> > visible structure
> >
> > Now, someone has to know how to create per-component git repo with
tags
> > (either by reworking exiting git mirrors, either by restarting from
svn),
> > and
> > that's not me :)
> >
> > given the volume (adding 70 git repos for Maven), we'll have to tell
infra
> > about it.
> >
> > Then there is the Jenkins jobs configuration:
> > - we need easy Jenkinsfile in each repo
>
> so we create a shared Groovy library like the Jenkins project does and
the
> Jenkinsfile becomes `buildPlugin` for all except core
>
> > - we need easy 80 jobs creation (no, I won't manually create 80 jobs
> > personally)
>
> So I will add SCMNavigator functionality to the ASF git-Jenkins plugin
and
> we just define an org-folder for Maven and all git repos with a
Jenkinsfile
> will be auto-maintained.
>
> > And once again, infra will have to be in the loop (at Jenkins side
this
> > time),
> > since I fear the load on Jenkins master node won't be light: perhaps
> > that's
> > where Jenkins folders will be useful, but I'm not a Jenkins expert
either.
>
> If we use an org folder integrated with GitPubSub I do not think they
will
> be overly concerned
>
> > If everything seems feasible to split our svn code into 1 git repo
per-
> > component, which will bring us to "full Maven code" being near 100
repos,
> > I'm
> > ok with it.
> > We'll need the help of misc experts on Jenkins and git to prepare
things
> > at
> > this scale.
>
> I think one repo per release root is the way to go.
>
> We should start by drawing up a list and amalgamation where
appropriate:
>
> Eg
>
> * does it make sense to release maven-deploy-plugin and
> maven-install-plugin independently? Seems we most often make mirroring
> changes to both, and perhaps it would be better if we forced that
model?
> (Don’t answer in this thread, just pointing out an example)
>
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
>
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
