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
