On JIRA handling 3 main choices jump out for me, which I would do in this order (1 first) personally: 1) Create an individual JIRA project per plugin (e.g as Maven do: https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=10510&selectedProjectType=all) 2) Create a new 'artemis plugins' style agregate JIRA project, with 'component' per plugin and 'releases' for each separate plugin release. 3) Create a 'component' per plugin and add 'releases' for each separate plugin release, within the existing ARTEMIS JIRA project.
Robbie On Thu, 6 Jun 2019 at 22:25, Michael André Pearce <michael.andre.pea...@me.com.invalid> wrote: > > If we are going down the route of separate repos, are we going to have > separate jira projects then for every plugin? > > Also just to be clear here we are talking about the > > promethius-plugin > kafka-plugin > > currently? Or any others also? > > > On 4 Jun 2019, at 17:47, Clebert Suconic <clebert.suco...@gmail.com> wrote: > > > > Fair enough... one component per repo. > > > > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish <tabish...@gmail.com> wrote: > >> > >> 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, <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? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> -- > >> Tim Bish > >> > > > > > > -- > > Clebert Suconic >
