[DISCUSS] Component/Plugin repository

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Component/Plugin repository

jbertram
With the impending support for metrics plugins [1] as well as other
pluggable components which have been discussed in the past (e.g. Kafka
bridge [2] proposed by Mike Pearce) I think it would great to have an
official place where these things could be hosted and potentially included
as part of a broker release. Does anybody have any opinion on this?


Justin

[1] https://github.com/apache/activemq-artemis/pull/2681
[2] https://issues.apache.org/jira/browse/ARTEMIS-1478
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

christopher.l.shannon
This sounds good to me, I think it would be good to have some way to keep a
collection of plugins that is easy for people to find.  I guess they could
either go into a new directory under the current Artemis build and each
have their own sub module/ jar or they could live by themselves in a new
sub project.

I'm not really sure which approach would be best. Having new sub modules
makes it easy to keep the plugins in sync with the broker but can bloat the
release with things that may not belong in the main release (which is why
we didn't want the Kafka Bridge to be included as part of the main release)

Having a new sub project could be nice so people can optionally grab
plugins only if they want them and this would allow the plugins could be
updated and released on their own schedule.  The main downside I see with
the sub project approach is trying to keep plugins in sync with the broker
version. If we don't end up bundling the plugins with the broker itself
then we need to figure out how to handle compatibility across releases.

On Tue, May 28, 2019 at 10:50 PM Justin Bertram <[hidden email]> wrote:

> With the impending support for metrics plugins [1] as well as other
> pluggable components which have been discussed in the past (e.g. Kafka
> bridge [2] proposed by Mike Pearce) I think it would great to have an
> official place where these things could be hosted and potentially included
> as part of a broker release. Does anybody have any opinion on this?
>
>
> Justin
>
> [1] https://github.com/apache/activemq-artemis/pull/2681
> [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
We could have a separate repository for these plugins...

They could be part of our binary distribution (as being consumed), and
we could have special CLI options to activate them.


e.g.: ./artemis create /folder --plugin prometheus


The prometheus plugin would be only applied if such option was applied.

On Wed, May 29, 2019 at 6:54 AM Christopher Shannon
<[hidden email]> wrote:

>
> This sounds good to me, I think it would be good to have some way to keep a
> collection of plugins that is easy for people to find.  I guess they could
> either go into a new directory under the current Artemis build and each
> have their own sub module/ jar or they could live by themselves in a new
> sub project.
>
> I'm not really sure which approach would be best. Having new sub modules
> makes it easy to keep the plugins in sync with the broker but can bloat the
> release with things that may not belong in the main release (which is why
> we didn't want the Kafka Bridge to be included as part of the main release)
>
> Having a new sub project could be nice so people can optionally grab
> plugins only if they want them and this would allow the plugins could be
> updated and released on their own schedule.  The main downside I see with
> the sub project approach is trying to keep plugins in sync with the broker
> version. If we don't end up bundling the plugins with the broker itself
> then we need to figure out how to handle compatibility across releases.
>
> On Tue, May 28, 2019 at 10:50 PM Justin Bertram <[hidden email]> wrote:
>
> > With the impending support for metrics plugins [1] as well as other
> > pluggable components which have been discussed in the past (e.g. Kafka
> > bridge [2] proposed by Mike Pearce) I think it would great to have an
> > official place where these things could be hosted and potentially included
> > as part of a broker release. Does anybody have any opinion on this?
> >
> >
> > Justin
> >
> > [1] https://github.com/apache/activemq-artemis/pull/2681
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
> >



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

michael.andre.pearce
What ever the agreed place is i would want to see the same rules being applied across the board as noted this isnt the first time this has cropped up.




That said. If we go seperate repo route. We could move other bits like docker and operator sub modules to sub repos there so they can have possibly a different lifecycle.




In particular comment to Prometheus plugin. Would it be worth while also providing some base grafana dashboard people can just import to complement the metrics so end users have an even quicker onboarding journey.








Get Outlook for Android







On Wed, May 29, 2019 at 2:09 PM +0100, "Clebert Suconic" <[hidden email]> wrote:










We could have a separate repository for these plugins...

They could be part of our binary distribution (as being consumed), and
we could have special CLI options to activate them.


e.g.: ./artemis create /folder --plugin prometheus


The prometheus plugin would be only applied if such option was applied.

On Wed, May 29, 2019 at 6:54 AM Christopher Shannon
 wrote:

>
> This sounds good to me, I think it would be good to have some way to keep a
> collection of plugins that is easy for people to find.  I guess they could
> either go into a new directory under the current Artemis build and each
> have their own sub module/ jar or they could live by themselves in a new
> sub project.
>
> I'm not really sure which approach would be best. Having new sub modules
> makes it easy to keep the plugins in sync with the broker but can bloat the
> release with things that may not belong in the main release (which is why
> we didn't want the Kafka Bridge to be included as part of the main release)
>
> Having a new sub project could be nice so people can optionally grab
> plugins only if they want them and this would allow the plugins could be
> updated and released on their own schedule.  The main downside I see with
> the sub project approach is trying to keep plugins in sync with the broker
> version. If we don't end up bundling the plugins with the broker itself
> then we need to figure out how to handle compatibility across releases.
>
> On Tue, May 28, 2019 at 10:50 PM Justin Bertram  wrote:
>
> > With the impending support for metrics plugins [1] as well as other
> > pluggable components which have been discussed in the past (e.g. Kafka
> > bridge [2] proposed by Mike Pearce) I think it would great to have an
> > official place where these things could be hosted and potentially included
> > as part of a broker release. Does anybody have any opinion on this?
> >
> >
> > Justin
> >
> > [1] https://github.com/apache/activemq-artemis/pull/2681
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
> >



--
Clebert Suconic





Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
On Thu, May 30, 2019 at 12:50 AM <[hidden email]> wrote:
>
> What ever the agreed place is i would want to see the same rules being applied across the board as noted this isnt the first time this has cropped up.

It's simple... if the integration is soft, make it a plugin.

We could have a framework defined on how plugins are consumed. That
would allow a whole set of features to be implemented.


>
> That said. If we go seperate repo route. We could move other bits like docker and operator sub modules to sub repos there so they can have possibly a different lifecycle.

We could.. however Docker is a bit dependent on the release. if we go
to the apache infra docker support, it would need to be part of the
repository. (not a good example on this case)

>
> In particular comment to Prometheus plugin. Would it be worth while also providing some base grafana dashboard people can just import to complement the metrics so end users have an even quicker onboarding journey.

It could be part of such external repository I think.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

Robbie Gemmell
In reply to this post by christopher.l.shannon
I would put them outwith the broker repository. Not really because of
bloat, which was only a very small part of why I didnt think the
proposed Kafka Bridge should live inside the broker repo+package for
example, but thats certainly also something to keep in mind given the
build is pretty large/slow already.

I wouldnt say a single plugin repository is necessarily a great idea,
it can tend to become a bit of a dumping ground for idea-of-the-week,
but the main thing for me would be that components should be
independently released if there were to be a bunch of optional
components with mostly unrelated functionality in the same place (e.g,
the ideas mentioned in this thread already seem mostly independent).

Robbie

On Wed, 29 May 2019 at 11:54, Christopher Shannon
<[hidden email]> wrote:

>
> This sounds good to me, I think it would be good to have some way to keep a
> collection of plugins that is easy for people to find.  I guess they could
> either go into a new directory under the current Artemis build and each
> have their own sub module/ jar or they could live by themselves in a new
> sub project.
>
> I'm not really sure which approach would be best. Having new sub modules
> makes it easy to keep the plugins in sync with the broker but can bloat the
> release with things that may not belong in the main release (which is why
> we didn't want the Kafka Bridge to be included as part of the main release)
>
> Having a new sub project could be nice so people can optionally grab
> plugins only if they want them and this would allow the plugins could be
> updated and released on their own schedule.  The main downside I see with
> the sub project approach is trying to keep plugins in sync with the broker
> version. If we don't end up bundling the plugins with the broker itself
> then we need to figure out how to handle compatibility across releases.
>
> On Tue, May 28, 2019 at 10:50 PM Justin Bertram <[hidden email]> wrote:
>
> > With the impending support for metrics plugins [1] as well as other
> > pluggable components which have been discussed in the past (e.g. Kafka
> > bridge [2] proposed by Mike Pearce) I think it would great to have an
> > official place where these things could be hosted and potentially included
> > as part of a broker release. Does anybody have any opinion on this?
> >
> >
> > Justin
> >
> > [1] https://github.com/apache/activemq-artemis/pull/2681
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
> >
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
<[hidden email]> wrote:

>
> I would put them outwith the broker repository. Not really because of
> bloat, which was only a very small part of why I didnt think the
> proposed Kafka Bridge should live inside the broker repo+package for
> example, but thats certainly also something to keep in mind given the
> build is pretty large/slow already.
>
> I wouldnt say a single plugin repository is necessarily a great idea,
> it can tend to become a bit of a dumping ground for idea-of-the-week,
> but the main thing for me would be that components should be
> independently released if there were to be a bunch of optional
> components with mostly unrelated functionality in the same place (e.g,
> the ideas mentioned in this thread already seem mostly independent).

So, what do you suggest? one gitRepo per plugin?
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

michael.andre.pearce
I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.




Get Outlook for Android







On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <[hidden email]> wrote:










On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
 wrote:

>
> I would put them outwith the broker repository. Not really because of
> bloat, which was only a very small part of why I didnt think the
> proposed Kafka Bridge should live inside the broker repo+package for
> example, but thats certainly also something to keep in mind given the
> build is pretty large/slow already.
>
> I wouldnt say a single plugin repository is necessarily a great idea,
> it can tend to become a bit of a dumping ground for idea-of-the-week,
> but the main thing for me would be that components should be
> independently released if there were to be a bunch of optional
> components with mostly unrelated functionality in the same place (e.g,
> the ideas mentioned in this thread already seem mostly independent).

So, what do you suggest? one gitRepo per plugin?





Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
I agree with you, and that was my preference as well. I was trying to
understand if one git per component is what Robbie was suggesting.

Although there's an issue though, when you have one super git for many
independent components, how would you tag releases?

each fodler would be in fact an independent project, with no
correlation between the projects.

On Fri, May 31, 2019 at 8:00 AM <[hidden email]> wrote:

>
> I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <[hidden email]> wrote:
>
>
>
>
>
>
>
>
>
>
> On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
>  wrote:
> >
> > I would put them outwith the broker repository. Not really because of
> > bloat, which was only a very small part of why I didnt think the
> > proposed Kafka Bridge should live inside the broker repo+package for
> > example, but thats certainly also something to keep in mind given the
> > build is pretty large/slow already.
> >
> > I wouldnt say a single plugin repository is necessarily a great idea,
> > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > but the main thing for me would be that components should be
> > independently released if there were to be a bunch of optional
> > components with mostly unrelated functionality in the same place (e.g,
> > the ideas mentioned in this thread already seem mostly independent).
>
> So, what do you suggest? one gitRepo per plugin?
>
>
>
>
>


--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

Robbie Gemmell
I probably would do one each, yes. Its the easiest separation, keeps
things independent and focused from the start and can avoid various
hassles later.

I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
metrics), but really I dont personally see the benefits as outweighing
the other things a lot of the time. I dont think anyone is charging us
per repo.

With a shared repo I guess you would just tag everything, or else
start down the route of complications that also make individual repos
seem nice. Could use Subversion, subdir tags were easy there :)

(Aside, there is one project, ActiveMQ. These would be components).

On Fri, 31 May 2019 at 17:24, Clebert Suconic <[hidden email]> wrote:

>
> I agree with you, and that was my preference as well. I was trying to
> understand if one git per component is what Robbie was suggesting.
>
> Although there's an issue though, when you have one super git for many
> independent components, how would you tag releases?
>
> each fodler would be in fact an independent project, with no
> correlation between the projects.
>
> On Fri, May 31, 2019 at 8:00 AM <[hidden email]> wrote:
> >
> > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <[hidden email]> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> >  wrote:
> > >
> > > I would put them outwith the broker repository. Not really because of
> > > bloat, which was only a very small part of why I didnt think the
> > > proposed Kafka Bridge should live inside the broker repo+package for
> > > example, but thats certainly also something to keep in mind given the
> > > build is pretty large/slow already.
> > >
> > > I wouldnt say a single plugin repository is necessarily a great idea,
> > > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > > but the main thing for me would be that components should be
> > > independently released if there were to be a bunch of optional
> > > components with mostly unrelated functionality in the same place (e.g,
> > > the ideas mentioned in this thread already seem mostly independent).
> >
> > So, what do you suggest? one gitRepo per plugin?
> >
> >
> >
> >
> >
>
>
> --
> Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <[hidden email]> wrote:
>
> I probably would do one each, yes. Its the easiest separation, keeps
> things independent and focused from the start and can avoid various
> hassles later.
>
> I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> metrics), but really I dont personally see the benefits as outweighing
> the other things a lot of the time. I dont think anyone is charging us
> per repo.

No, but does it require a vote each time we spin a new component?


>
> With a shared repo I guess you would just tag everything, or else
> start down the route of complications that also make individual repos
> seem nice. Could use Subversion, subdir tags were easy there :)
>
> (Aside, there is one project, ActiveMQ. These would be components).
>
> On Fri, 31 May 2019 at 17:24, Clebert Suconic <[hidden email]> wrote:
> >
> > I agree with you, and that was my preference as well. I was trying to
> > understand if one git per component is what Robbie was suggesting.
> >
> > Although there's an issue though, when you have one super git for many
> > independent components, how would you tag releases?
> >
> > each fodler would be in fact an independent project, with no
> > correlation between the projects.
> >
> > On Fri, May 31, 2019 at 8:00 AM <[hidden email]> wrote:
> > >
> > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
> > >
> > >
> > >
> > >
> > > Get Outlook for Android
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <[hidden email]> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > >  wrote:
> > > >
> > > > I would put them outwith the broker repository. Not really because of
> > > > bloat, which was only a very small part of why I didnt think the
> > > > proposed Kafka Bridge should live inside the broker repo+package for
> > > > example, but thats certainly also something to keep in mind given the
> > > > build is pretty large/slow already.
> > > >
> > > > I wouldnt say a single plugin repository is necessarily a great idea,
> > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > > > but the main thing for me would be that components should be
> > > > independently released if there were to be a bunch of optional
> > > > components with mostly unrelated functionality in the same place (e.g,
> > > > the ideas mentioned in this thread already seem mostly independent).
> > >
> > > So, what do you suggest? one gitRepo per plugin?
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Clebert Suconic



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

michael.andre.pearce
Thats a concern for me. Also the setup for every repo.I think personally having a single repo will be easier for starters. We can always split out groups of modules later, or even one per module. If it gets too much.But for a first go i think having a single repo for plugins and other extensions will be better.Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Clebert Suconic <[hidden email]> Date: 31/05/2019  20:12  (GMT+00:00) To: [hidden email] Subject: Re: [DISCUSS] Component/Plugin repository On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <[hidden email]> wrote:>> I probably would do one each, yes. Its the easiest separation, keeps> things independent and focused from the start and can avoid various> hassles later.>> I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo => metrics), but really I dont personally see the benefits as outweighing> the other things a lot of the time. I dont think anyone is charging us> per repo.No, but does it require a vote each time we spin a new component?>> With a shared repo I guess you would just tag everything, or else> start down the route of complications that also make individual repos> seem nice. Could use Subversion, subdir tags were easy there :)>> (Aside, there is one project, ActiveMQ. These would be components).>> On Fri, 31 May 2019 at 17:24, Clebert Suconic <[hidden email]> wrote:> >> > I agree with you, and that was my preference as well. I was trying to> > understand if one git per component is what Robbie was suggesting.> >> > Although there's an issue though, when you have one super git for many> > independent components, how would you tag releases?> >> > each fodler would be in fact an independent project, with no> > correlation between the projects.> >> > On Fri, May 31, 2019 at 8:00 AM <[hidden email]> wrote:> > >> > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.> > >> > >> > >> > >> > > Get Outlook for Android> > >> > >> > >> > >> > >> > >> > >> > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <[hidden email]> wrote:> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell> > >  wrote:> > > >> > > > I would put them outwith the broker repository. Not really because of> > > > bloat, which was only a very small part of why I didnt think the> > > > proposed Kafka Bridge should live inside the broker repo+package for> > > > example, but thats certainly also something to keep in mind given the> > > > build is pretty large/slow already.> > > >> > > > I wouldnt say a single plugin repository is necessarily a great idea,> > > > it can tend to become a bit of a dumping ground for idea-of-the-week,> > > > but the main thing for me would be that components should be> > > > independently released if there were to be a bunch of optional> > > > components with mostly unrelated functionality in the same place (e.g,> > > > the ideas mentioned in this thread already seem mostly independent).> > >> > > So, what do you suggest? one gitRepo per plugin?> > >> > >> > >> > >> > >> >> >> > --> > Clebert Suconic-- Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

Robbie Gemmell
In reply to this post by clebertsuconic
A vote would be required for each independently released thing, yes.
That is true whether they are in specific repos or in an single repo
but still released independently, so the only difference would come if
releasing all plugins in that single repo as 'one thing'. That
probably mean less releases, but likely also more complicated ones as
grouping essentially indpendent bits into a single release tends to
add its own challenges. That can tend to make them happen less often,
and encourages them to be 'bigger' as folk stuff things in, which then
makes them more complicated again, etc...

Release votes dont need to be especially difficult. I've found the
more targetted and/or regular they are, the easier doing them tends to
become. I've run around 30 or so in the last year across a few
components, but would have preferred to do more than I actually did.

Robbie

On Fri, 31 May 2019 at 20:12, Clebert Suconic <[hidden email]> wrote:

>
> On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <[hidden email]> wrote:
> >
> > I probably would do one each, yes. Its the easiest separation, keeps
> > things independent and focused from the start and can avoid various
> > hassles later.
> >
> > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > metrics), but really I dont personally see the benefits as outweighing
> > the other things a lot of the time. I dont think anyone is charging us
> > per repo.
>
> No, but does it require a vote each time we spin a new component?
>
>
> >
> > With a shared repo I guess you would just tag everything, or else
> > start down the route of complications that also make individual repos
> > seem nice. Could use Subversion, subdir tags were easy there :)
> >
> > (Aside, there is one project, ActiveMQ. These would be components).
> >
> > On Fri, 31 May 2019 at 17:24, Clebert Suconic <[hidden email]> wrote:
> > >
> > > I agree with you, and that was my preference as well. I was trying to
> > > understand if one git per component is what Robbie was suggesting.
> > >
> > > Although there's an issue though, when you have one super git for many
> > > independent components, how would you tag releases?
> > >
> > > each fodler would be in fact an independent project, with no
> > > correlation between the projects.
> > >
> > > On Fri, May 31, 2019 at 8:00 AM <[hidden email]> wrote:
> > > >
> > > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
> > > >
> > > >
> > > >
> > > >
> > > > Get Outlook for Android
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > >  wrote:
> > > > >
> > > > > I would put them outwith the broker repository. Not really because of
> > > > > bloat, which was only a very small part of why I didnt think the
> > > > > proposed Kafka Bridge should live inside the broker repo+package for
> > > > > example, but thats certainly also something to keep in mind given the
> > > > > build is pretty large/slow already.
> > > > >
> > > > > I wouldnt say a single plugin repository is necessarily a great idea,
> > > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > > > > but the main thing for me would be that components should be
> > > > > independently released if there were to be a bunch of optional
> > > > > components with mostly unrelated functionality in the same place (e.g,
> > > > > the ideas mentioned in this thread already seem mostly independent).
> > > >
> > > > So, what do you suggest? one gitRepo per plugin?
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Clebert Suconic
>
>
>
> --
> Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
The question was in regard to spin new components? do we need a new vote to
start a new repository?

Regarding the releases... we could release them altogether. Say...
ActiveMQ-Artemis-plugin 1.0

Later on, when you add a new feature, you will have 1.1, 1.2... and
thereafter.

Say we changed something on the broker that will require update in all of
them/// we will need a lot of votes to go out.




On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <[hidden email]>
wrote:

> A vote would be required for each independently released thing, yes.
> That is true whether they are in specific repos or in an single repo
> but still released independently, so the only difference would come if
> releasing all plugins in that single repo as 'one thing'. That
> probably mean less releases, but likely also more complicated ones as
> grouping essentially indpendent bits into a single release tends to
> add its own challenges. That can tend to make them happen less often,
> and encourages them to be 'bigger' as folk stuff things in, which then
> makes them more complicated again, etc...
>
> Release votes dont need to be especially difficult. I've found the
> more targetted and/or regular they are, the easier doing them tends to
> become. I've run around 30 or so in the last year across a few
> components, but would have preferred to do more than I actually did.
>
> Robbie
>
> On Fri, 31 May 2019 at 20:12, Clebert Suconic <[hidden email]>
> wrote:
> >
> > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <[hidden email]>
> wrote:
> > >
> > > I probably would do one each, yes. Its the easiest separation, keeps
> > > things independent and focused from the start and can avoid various
> > > hassles later.
> > >
> > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > > metrics), but really I dont personally see the benefits as outweighing
> > > the other things a lot of the time. I dont think anyone is charging us
> > > per repo.
> >
> > No, but does it require a vote each time we spin a new component?
> >
> >
> > >
> > > With a shared repo I guess you would just tag everything, or else
> > > start down the route of complications that also make individual repos
> > > seem nice. Could use Subversion, subdir tags were easy there :)
> > >
> > > (Aside, there is one project, ActiveMQ. These would be components).
> > >
> > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <
> [hidden email]> wrote:
> > > >
> > > > I agree with you, and that was my preference as well. I was trying to
> > > > understand if one git per component is what Robbie was suggesting.
> > > >
> > > > Although there's an issue though, when you have one super git for
> many
> > > > independent components, how would you tag releases?
> > > >
> > > > each fodler would be in fact an independent project, with no
> > > > correlation between the projects.
> > > >
> > > > On Fri, May 31, 2019 at 8:00 AM <[hidden email]>
> wrote:
> > > > >
> > > > > I think one git repo per thing maybecome a bit too scattery. Id go
> for one repo with multiple modules.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Get Outlook for Android
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <
> [hidden email]> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > > >  wrote:
> > > > > >
> > > > > > I would put them outwith the broker repository. Not really
> because of
> > > > > > bloat, which was only a very small part of why I didnt think the
> > > > > > proposed Kafka Bridge should live inside the broker repo+package
> for
> > > > > > example, but thats certainly also something to keep in mind
> given the
> > > > > > build is pretty large/slow already.
> > > > > >
> > > > > > I wouldnt say a single plugin repository is necessarily a great
> idea,
> > > > > > it can tend to become a bit of a dumping ground for
> idea-of-the-week,
> > > > > > but the main thing for me would be that components should be
> > > > > > independently released if there were to be a bunch of optional
> > > > > > components with mostly unrelated functionality in the same place
> (e.g,
> > > > > > the ideas mentioned in this thread already seem mostly
> independent).
> > > > >
> > > > > So, what do you suggest? one gitRepo per plugin?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
there's also another technical issue when we create / separate these components.
They will likely depend on the broker...



And how are we going to consume these components on the broker? Have
the users picking them and installing them manually?


idea:
We could have the CLI doing such thing for users, with an optional CLI
on the create:


./artemis create --plugin Prometheus


But then this would create a circular dependency between the
repositories, what makes it difficult.


How would it be consumed? Just having the user copying it ?



On Mon, Jun 3, 2019 at 9:24 AM Clebert Suconic
<[hidden email]> wrote:

>
> The question was in regard to spin new components? do we need a new vote to start a new repository?
>
> Regarding the releases... we could release them altogether. Say... ActiveMQ-Artemis-plugin 1.0
>
> Later on, when you add a new feature, you will have 1.1, 1.2... and thereafter.
>
> Say we changed something on the broker that will require update in all of them/// we will need a lot of votes to go out.
>
>
>
>
> On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <[hidden email]> wrote:
>>
>> A vote would be required for each independently released thing, yes.
>> That is true whether they are in specific repos or in an single repo
>> but still released independently, so the only difference would come if
>> releasing all plugins in that single repo as 'one thing'. That
>> probably mean less releases, but likely also more complicated ones as
>> grouping essentially indpendent bits into a single release tends to
>> add its own challenges. That can tend to make them happen less often,
>> and encourages them to be 'bigger' as folk stuff things in, which then
>> makes them more complicated again, etc...
>>
>> Release votes dont need to be especially difficult. I've found the
>> more targetted and/or regular they are, the easier doing them tends to
>> become. I've run around 30 or so in the last year across a few
>> components, but would have preferred to do more than I actually did.
>>
>> Robbie
>>
>> On Fri, 31 May 2019 at 20:12, Clebert Suconic <[hidden email]> wrote:
>> >
>> > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <[hidden email]> wrote:
>> > >
>> > > I probably would do one each, yes. Its the easiest separation, keeps
>> > > things independent and focused from the start and can avoid various
>> > > hassles later.
>> > >
>> > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
>> > > metrics), but really I dont personally see the benefits as outweighing
>> > > the other things a lot of the time. I dont think anyone is charging us
>> > > per repo.
>> >
>> > No, but does it require a vote each time we spin a new component?
>> >
>> >
>> > >
>> > > With a shared repo I guess you would just tag everything, or else
>> > > start down the route of complications that also make individual repos
>> > > seem nice. Could use Subversion, subdir tags were easy there :)
>> > >
>> > > (Aside, there is one project, ActiveMQ. These would be components).
>> > >
>> > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <[hidden email]> wrote:
>> > > >
>> > > > I agree with you, and that was my preference as well. I was trying to
>> > > > understand if one git per component is what Robbie was suggesting.
>> > > >
>> > > > Although there's an issue though, when you have one super git for many
>> > > > independent components, how would you tag releases?
>> > > >
>> > > > each fodler would be in fact an independent project, with no
>> > > > correlation between the projects.
>> > > >
>> > > > On Fri, May 31, 2019 at 8:00 AM <[hidden email]> wrote:
>> > > > >
>> > > > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > Get Outlook for Android
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <[hidden email]> wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
>> > > > >  wrote:
>> > > > > >
>> > > > > > I would put them outwith the broker repository. Not really because of
>> > > > > > bloat, which was only a very small part of why I didnt think the
>> > > > > > proposed Kafka Bridge should live inside the broker repo+package for
>> > > > > > example, but thats certainly also something to keep in mind given the
>> > > > > > build is pretty large/slow already.
>> > > > > >
>> > > > > > I wouldnt say a single plugin repository is necessarily a great idea,
>> > > > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
>> > > > > > but the main thing for me would be that components should be
>> > > > > > independently released if there were to be a bunch of optional
>> > > > > > components with mostly unrelated functionality in the same place (e.g,
>> > > > > > the ideas mentioned in this thread already seem mostly independent).
>> > > > >
>> > > > > So, what do you suggest? one gitRepo per plugin?
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Clebert Suconic
>> >
>> >
>> >
>> > --
>> > Clebert Suconic



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

michael.andre.pearce
What about the kafka plugin, or influx plugin...




All questions need to be same




Get Outlook for Android







On Mon, Jun 3, 2019 at 2:27 PM +0100, "Clebert Suconic" <[hidden email]> wrote:










there's also another technical issue when we create / separate these components.
They will likely depend on the broker...



And how are we going to consume these components on the broker? Have
the users picking them and installing them manually?


idea:
We could have the CLI doing such thing for users, with an optional CLI
on the create:


./artemis create --plugin Prometheus


But then this would create a circular dependency between the
repositories, what makes it difficult.


How would it be consumed? Just having the user copying it ?



On Mon, Jun 3, 2019 at 9:24 AM Clebert Suconic
 wrote:

>
> The question was in regard to spin new components? do we need a new vote to start a new repository?
>
> Regarding the releases... we could release them altogether. Say... ActiveMQ-Artemis-plugin 1.0
>
> Later on, when you add a new feature, you will have 1.1, 1.2... and thereafter.
>
> Say we changed something on the broker that will require update in all of them/// we will need a lot of votes to go out.
>
>
>
>
> On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell  wrote:
>>
>> A vote would be required for each independently released thing, yes.
>> That is true whether they are in specific repos or in an single repo
>> but still released independently, so the only difference would come if
>> releasing all plugins in that single repo as 'one thing'. That
>> probably mean less releases, but likely also more complicated ones as
>> grouping essentially indpendent bits into a single release tends to
>> add its own challenges. That can tend to make them happen less often,
>> and encourages them to be 'bigger' as folk stuff things in, which then
>> makes them more complicated again, etc...
>>
>> Release votes dont need to be especially difficult. I've found the
>> more targetted and/or regular they are, the easier doing them tends to
>> become. I've run around 30 or so in the last year across a few
>> components, but would have preferred to do more than I actually did.
>>
>> Robbie
>>
>> On Fri, 31 May 2019 at 20:12, Clebert Suconic  wrote:
>> >
>> > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell  wrote:
>> > >
>> > > I probably would do one each, yes. Its the easiest separation, keeps
>> > > things independent and focused from the start and can avoid various
>> > > hassles later.
>> > >
>> > > I'd perhaps consider 'all  stuff' aggregation (e.g foo =
>> > > metrics), but really I dont personally see the benefits as outweighing
>> > > the other things a lot of the time. I dont think anyone is charging us
>> > > per repo.
>> >
>> > No, but does it require a vote each time we spin a new component?
>> >
>> >
>> > >
>> > > With a shared repo I guess you would just tag everything, or else
>> > > start down the route of complications that also make individual repos
>> > > seem nice. Could use Subversion, subdir tags were easy there :)
>> > >
>> > > (Aside, there is one project, ActiveMQ. These would be components).
>> > >
>> > > On Fri, 31 May 2019 at 17:24, Clebert Suconic  wrote:
>> > > >
>> > > > I agree with you, and that was my preference as well. I was trying to
>> > > > understand if one git per component is what Robbie was suggesting.
>> > > >
>> > > > Although there's an issue though, when you have one super git for many
>> > > > independent components, how would you tag releases?
>> > > >
>> > > > each fodler would be in fact an independent project, with no
>> > > > correlation between the projects.
>> > > >
>> > > > On Fri, May 31, 2019 at 8:00 AM  wrote:
>> > > > >
>> > > > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > Get Outlook for Android
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic"  wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
>> > > > >  wrote:
>> > > > > >
>> > > > > > I would put them outwith the broker repository. Not really because of
>> > > > > > bloat, which was only a very small part of why I didnt think the
>> > > > > > proposed Kafka Bridge should live inside the broker repo+package for
>> > > > > > example, but thats certainly also something to keep in mind given the
>> > > > > > build is pretty large/slow already.
>> > > > > >
>> > > > > > I wouldnt say a single plugin repository is necessarily a great idea,
>> > > > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
>> > > > > > but the main thing for me would be that components should be
>> > > > > > independently released if there were to be a bunch of optional
>> > > > > > components with mostly unrelated functionality in the same place (e.g,
>> > > > > > the ideas mentioned in this thread already seem mostly independent).
>> > > > >
>> > > > > So, what do you suggest? one gitRepo per plugin?
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Clebert Suconic
>> >
>> >
>> >
>> > --
>> > Clebert Suconic



--
Clebert Suconic





Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

Robbie Gemmell
In reply to this post by clebertsuconic
On Mon, 3 Jun 2019 at 14:24, Clebert Suconic <[hidden email]> wrote:
>
> The question was in regard to spin new components? do we need a new vote to
> start a new repository?
>

I dont believe we actually do need a vote, a lot of stuff doesn't,
just establishing consensus on what is being done. Votes are one way
of doing that so sometimes thats used all the time. Lazy concensus is
another way. Making people clearly aware and giving chance to discuss
things and agree a path is the important bit in most cases.

I wouldnt expect a new component to pop up in a shared repo much
differently than I'd expect a new specific repo to be established for
it..i.e not without discussion and agreement on it occurring, ensuring
its not a surprise to folks etc...likely stuff which cant happen any
faster than the time to take a vote if folks feel that is actually
needed.

> Regarding the releases... we could release them altogether. Say...
> ActiveMQ-Artemis-plugin 1.0
>
> Later on, when you add a new feature, you will have 1.1, 1.2... and
> thereafter.

Yep, and when one thing requires making a major/breaking change, then
they all have to say that even though its not true (if the versions
reflect that), and/or when most of the things havent changed at all
folks get to wonder what changed in each bit. Made worse if a
particular plugin ever wanted to support multiple streams, e.g support
different major versions of <foo> being plugged in, or work with
different major versions of Artemis. All of them have to be in a
releasable state at exactly the same time. The build takes longer as
more and more [unrelated] things are added. Etc.

Less releases isnt necessarily an advantage.

>
> Say we changed something on the broker that will require update in all of
> them/// we will need a lot of votes to go out.
>

Possibly, or that might be reason to do facilitate something more
transitional so as to not to break them, which should maybe happen if
its considered a supported plugin API. Presumably breaking them all
'deliberately' would be most likely to occur in a major broker
release.

Also worth considering that not everything need be part of the
project. Not requiring that can even a good reason to have certain
plugin points in the first place.

>
>
>
> On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <[hidden email]>
> wrote:
>
> > A vote would be required for each independently released thing, yes.
> > That is true whether they are in specific repos or in an single repo
> > but still released independently, so the only difference would come if
> > releasing all plugins in that single repo as 'one thing'. That
> > probably mean less releases, but likely also more complicated ones as
> > grouping essentially indpendent bits into a single release tends to
> > add its own challenges. That can tend to make them happen less often,
> > and encourages them to be 'bigger' as folk stuff things in, which then
> > makes them more complicated again, etc...
> >
> > Release votes dont need to be especially difficult. I've found the
> > more targetted and/or regular they are, the easier doing them tends to
> > become. I've run around 30 or so in the last year across a few
> > components, but would have preferred to do more than I actually did.
> >
> > Robbie
> >
> > On Fri, 31 May 2019 at 20:12, Clebert Suconic <[hidden email]>
> > wrote:
> > >
> > > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <[hidden email]>
> > wrote:
> > > >
> > > > I probably would do one each, yes. Its the easiest separation, keeps
> > > > things independent and focused from the start and can avoid various
> > > > hassles later.
> > > >
> > > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > > > metrics), but really I dont personally see the benefits as outweighing
> > > > the other things a lot of the time. I dont think anyone is charging us
> > > > per repo.
> > >
> > > No, but does it require a vote each time we spin a new component?
> > >
> > >
> > > >
> > > > With a shared repo I guess you would just tag everything, or else
> > > > start down the route of complications that also make individual repos
> > > > seem nice. Could use Subversion, subdir tags were easy there :)
> > > >
> > > > (Aside, there is one project, ActiveMQ. These would be components).
> > > >
> > > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <
> > [hidden email]> wrote:
> > > > >
> > > > > I agree with you, and that was my preference as well. I was trying to
> > > > > understand if one git per component is what Robbie was suggesting.
> > > > >
> > > > > Although there's an issue though, when you have one super git for
> > many
> > > > > independent components, how would you tag releases?
> > > > >
> > > > > each fodler would be in fact an independent project, with no
> > > > > correlation between the projects.
> > > > >
> > > > > On Fri, May 31, 2019 at 8:00 AM <[hidden email]>
> > wrote:
> > > > > >
> > > > > > I think one git repo per thing maybecome a bit too scattery. Id go
> > for one repo with multiple modules.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Get Outlook for Android
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <
> > [hidden email]> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > > > >  wrote:
> > > > > > >
> > > > > > > I would put them outwith the broker repository. Not really
> > because of
> > > > > > > bloat, which was only a very small part of why I didnt think the
> > > > > > > proposed Kafka Bridge should live inside the broker repo+package
> > for
> > > > > > > example, but thats certainly also something to keep in mind
> > given the
> > > > > > > build is pretty large/slow already.
> > > > > > >
> > > > > > > I wouldnt say a single plugin repository is necessarily a great
> > idea,
> > > > > > > it can tend to become a bit of a dumping ground for
> > idea-of-the-week,
> > > > > > > but the main thing for me would be that components should be
> > > > > > > independently released if there were to be a bunch of optional
> > > > > > > components with mostly unrelated functionality in the same place
> > (e.g,
> > > > > > > the ideas mentioned in this thread already seem mostly
> > independent).
> > > > > >
> > > > > > So, what do you suggest? one gitRepo per plugin?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
I would start with a single repo for all the plugins we can add.
The way we are set now, a single git repo is a good way to start.
We can always revist and move a component out to its own repo later.

As for the day to day dev, discussions and adding components, this is
no different than what we have now.. Pull Requests will have
discussions associated with them.

On Mon, Jun 3, 2019 at 10:05 AM Robbie Gemmell <[hidden email]> wrote:

>
> On Mon, 3 Jun 2019 at 14:24, Clebert Suconic <[hidden email]> wrote:
> >
> > The question was in regard to spin new components? do we need a new vote to
> > start a new repository?
> >
>
> I dont believe we actually do need a vote, a lot of stuff doesn't,
> just establishing consensus on what is being done. Votes are one way
> of doing that so sometimes thats used all the time. Lazy concensus is
> another way. Making people clearly aware and giving chance to discuss
> things and agree a path is the important bit in most cases.
>
> I wouldnt expect a new component to pop up in a shared repo much
> differently than I'd expect a new specific repo to be established for
> it..i.e not without discussion and agreement on it occurring, ensuring
> its not a surprise to folks etc...likely stuff which cant happen any
> faster than the time to take a vote if folks feel that is actually
> needed.
>
> > Regarding the releases... we could release them altogether. Say...
> > ActiveMQ-Artemis-plugin 1.0
> >
> > Later on, when you add a new feature, you will have 1.1, 1.2... and
> > thereafter.
>
> Yep, and when one thing requires making a major/breaking change, then
> they all have to say that even though its not true (if the versions
> reflect that), and/or when most of the things havent changed at all
> folks get to wonder what changed in each bit. Made worse if a
> particular plugin ever wanted to support multiple streams, e.g support
> different major versions of <foo> being plugged in, or work with
> different major versions of Artemis. All of them have to be in a
> releasable state at exactly the same time. The build takes longer as
> more and more [unrelated] things are added. Etc.
>
> Less releases isnt necessarily an advantage.
>
> >
> > Say we changed something on the broker that will require update in all of
> > them/// we will need a lot of votes to go out.
> >
>
> Possibly, or that might be reason to do facilitate something more
> transitional so as to not to break them, which should maybe happen if
> its considered a supported plugin API. Presumably breaking them all
> 'deliberately' would be most likely to occur in a major broker
> release.
>
> Also worth considering that not everything need be part of the
> project. Not requiring that can even a good reason to have certain
> plugin points in the first place.
>
> >
> >
> >
> > On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <[hidden email]>
> > wrote:
> >
> > > A vote would be required for each independently released thing, yes.
> > > That is true whether they are in specific repos or in an single repo
> > > but still released independently, so the only difference would come if
> > > releasing all plugins in that single repo as 'one thing'. That
> > > probably mean less releases, but likely also more complicated ones as
> > > grouping essentially indpendent bits into a single release tends to
> > > add its own challenges. That can tend to make them happen less often,
> > > and encourages them to be 'bigger' as folk stuff things in, which then
> > > makes them more complicated again, etc...
> > >
> > > Release votes dont need to be especially difficult. I've found the
> > > more targetted and/or regular they are, the easier doing them tends to
> > > become. I've run around 30 or so in the last year across a few
> > > components, but would have preferred to do more than I actually did.
> > >
> > > Robbie
> > >
> > > On Fri, 31 May 2019 at 20:12, Clebert Suconic <[hidden email]>
> > > wrote:
> > > >
> > > > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <[hidden email]>
> > > wrote:
> > > > >
> > > > > I probably would do one each, yes. Its the easiest separation, keeps
> > > > > things independent and focused from the start and can avoid various
> > > > > hassles later.
> > > > >
> > > > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > > > > metrics), but really I dont personally see the benefits as outweighing
> > > > > the other things a lot of the time. I dont think anyone is charging us
> > > > > per repo.
> > > >
> > > > No, but does it require a vote each time we spin a new component?
> > > >
> > > >
> > > > >
> > > > > With a shared repo I guess you would just tag everything, or else
> > > > > start down the route of complications that also make individual repos
> > > > > seem nice. Could use Subversion, subdir tags were easy there :)
> > > > >
> > > > > (Aside, there is one project, ActiveMQ. These would be components).
> > > > >
> > > > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <
> > > [hidden email]> wrote:
> > > > > >
> > > > > > I agree with you, and that was my preference as well. I was trying to
> > > > > > understand if one git per component is what Robbie was suggesting.
> > > > > >
> > > > > > Although there's an issue though, when you have one super git for
> > > many
> > > > > > independent components, how would you tag releases?
> > > > > >
> > > > > > each fodler would be in fact an independent project, with no
> > > > > > correlation between the projects.
> > > > > >
> > > > > > On Fri, May 31, 2019 at 8:00 AM <[hidden email]>
> > > wrote:
> > > > > > >
> > > > > > > I think one git repo per thing maybecome a bit too scattery. Id go
> > > for one repo with multiple modules.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Get Outlook for Android
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <
> > > [hidden email]> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > I would put them outwith the broker repository. Not really
> > > because of
> > > > > > > > bloat, which was only a very small part of why I didnt think the
> > > > > > > > proposed Kafka Bridge should live inside the broker repo+package
> > > for
> > > > > > > > example, but thats certainly also something to keep in mind
> > > given the
> > > > > > > > build is pretty large/slow already.
> > > > > > > >
> > > > > > > > I wouldnt say a single plugin repository is necessarily a great
> > > idea,
> > > > > > > > it can tend to become a bit of a dumping ground for
> > > idea-of-the-week,
> > > > > > > > but the main thing for me would be that components should be
> > > > > > > > independently released if there were to be a bunch of optional
> > > > > > > > components with mostly unrelated functionality in the same place
> > > (e.g,
> > > > > > > > the ideas mentioned in this thread already seem mostly
> > > independent).
> > > > > > >
> > > > > > > So, what do you suggest? one gitRepo per plugin?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Clebert Suconic
> > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> > >



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

clebertsuconic
In reply to this post by michael.andre.pearce
> All questions need to be same

@Michael Pearce perhaps it's my english as second language here, but
this to me sounded like "All your basis are belong to us" :)

Can you explain what you meant here?
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Component/Plugin repository

michael.andre.pearce
I just want it clarified what will be the rules of adopting a new plugin or extension. Likewise the rule for archiving/killing off dead ones.




And that is applied generically.




E.g.




At least one pmc member needs to sponsor (doesnt have to be the committer or contributor)




Any third party dependency plugin including dependency to third party client jar must be apache license approved. (E.g. we can have plugin or extension for a closed source commerical tool)






Just want the criteria decides agreed and documented up front to avoid less issues later on what can go in and what cant




Get Outlook for Android







On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <[hidden email]> wrote:










> All questions need to be same

@Michael Pearce perhaps it's my english as second language here, but
this to me sounded like "All your basis are belong to us" :)

Can you explain what you meant here?





12