So already it seems we have issues handling and maintaining rights for users on the few jira projects we have.
E.g. atm whilst Christopher S, sorted my activemq rights as pmc memebrt, it seems no one has been able to sort the others artemis amqnet and amqcpp. As such it shows atm managing too many will just get worse. I think we should avoid too much per project setup. Get Outlook for Android On Fri, Jun 7, 2019 at 12:36 PM +0100, "Robbie Gemmell" <robbie.gemm...@gmail.com> wrote: 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 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 wrote: > > > > Fair enough... one component per repo. > > > > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish 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, 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 >
