I think there is an element of difficulty in documenting precise criteria for plugins, as to a certain extent what the plugin is (and to smaller degree perhaps even what its implementation entails) could influence how necessary or appropriate people think it is to be part of this project, and might weigh against particular choices depending on views on certain matters such as licensing (more below). I guess thats precisely the type of uncertainty you are seeking to avoid, but I'm not sure I see an easy path to do that in advance in an entirely generic way.
The main things would seem to be general consensus from the PMC that the plugin is something they think should be a component part of this project as opposed to its own, and that there is clear support both for maintaining and releasing it going forward. At least 3 binding votes would be needed for it being released, so I'd expect that many or preferably more to be in obvious support before it is established as a plugin. On plugins being shuffled off, I think with it now seeming individual repositories is the preferred route this becomes even more similar to any of the existing components such as the brokers or clients themselves. If at some point it seems there is a lack of support needed to continue maintaining and releasing a plugin, and releases seem/are necessary but arent happening, then a discussion can be had on their future. Maybe that prompts a revival of interest which is good, or maybe its established that the plugin goes away at some chosen point if things havent changed by then, or maybe that time has been and gone an its shuffled off there and then. On "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)", am I right to think the "we can have" was meant to be 'we cant have' or 'can we have'? In general I'd say keeping things ASLv2 compatible is a good idea, though per the recent "LICENSE ISSUE" thread optional functionality can have Category X dependencies, and such plugins would usually seem to fit that categorisation of optional. This would be a choice for the PMC on what they want to permit, but is perhaps even a bit of a 'is this particular plugin of benefit warranting that hassle' balance, which per my opening can be hard to define up front - unless for this specific case everything agrees now the answer is always that its never warranted and those things must live elsewhere. Robbie On Mon, 3 Jun 2019 at 22:58, <michael.andre.pea...@me.com.invalid> wrote: > > 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" > <clebert.suco...@gmail.com> 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? > > > > >
