If we worry about breaking somethings along with our users/consumers/distributors, picking one of less used/updated connector as experiment makes more sense to me. It's OK if we want to pick one of most active and widely used connector intentionally to accelerate experiment.
Decoupling connectors and moving to other repo. like Bahir will make it clear who are having interest of which connectors. storm-eventhubs for example, major code contributions were done from MS developers. Now they are gone, and I don't know even storm-eventhubs are compatible with recent Azure Eventhub. That's just a one of them. I've seen many connectors in same, or similar, or possible (say truck number 1) situation. -Jungtaek Lim (HeartSaVioR) 2018년 1월 30일 (화) 오후 1:30, P. Taylor Goetz <ptgo...@gmail.com>님이 작성: > > On Jan 29, 2018, at 8:03 PM, Jungtaek Lim <kabh...@gmail.com> wrote: > > > > - Do we ensure they're all maintained? > -- Did we exclude inactive committers/PMCs for connector's committer > > sponsors, and do they have enough committer sponsors after that? > > > Good point. We’ve had some sponsors go silent recently. Maybe ping > sponsors and ask if they wish to maintain sponsorship? > > As a sponsor for a number of connectors, I’ll check on the ones I’ve > sponsored. > > - Do they all worth to keep maintaining in Storm main repository? > > > Again, that’s a question of whether there is user/dev interest. > > > -- Should we trigger release if we find and resolve critical/blocker issue > from them? If not, why we allow to leave the thing which is in main > repository as inconsistent state? > > > Some are tied to fairly well established protocols, some target really > volatile APIs. Bug reports and mailing list activity may not be a good > status indicator. > > Storm’s Kafka integration was the initial model for the “batteries > included” impetus behind `external`. If we want to evolve how that works, > why not start there, see what works/doesn’t work, and adapt. > > I don’t want to shock our users/consumers/distributors. > > > -Taylor > > > > > >
