On 6/4/19 8:14 AM, Andy Taylor wrote:
Id personally pefer a single repo per plugin, some plugins will develop
quicker than others and with a single repo you would end up tagging and
releasing plugins that havent changed. I dont think there is an overhead
with using maven etc.
Agreed, having each in its own repository running on its own release
cycle would be my preferred option as well. A single large repository
will tend to become harder to release as more things get dumped into it
but not actively maintained. It is easier for the release validation if
each is on its own as well, testing a release for a dozen different semi
related components will likely drive down the quality of the review
being done.
I also think there should be no tight coupling between the plugin and the
broker apart from implementing a specific API that should be set in stone.
Even better would be the ability to just to drop a war or jar into the lib
dir and have it deployed automagically via annotations on the class or
method perhaps.
On Mon, 3 Jun 2019 at 22:58, <[email protected]> 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" <
[email protected]> 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?
--
Tim Bish
