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 <clebert.suco...@gmail.com> 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 <robbie.gemm...@gmail.com> > 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 <clebert.suco...@gmail.com> >> wrote: >> > >> > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <robbie.gemm...@gmail.com> >> > 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 >> > > <clebert.suco...@gmail.com> 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 <michael.andre.pea...@me.com.invalid> >> > > > 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" >> > > > > <clebert.suco...@gmail.com> 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
