I've not personally found it a big deal to manage rights across multiple Jira projects, updates arent difficult. I do only manage 5 active Jira projects to be fair. Per the earlier link Maven look to have around 70 though, so it certainly seems feasible to do a few more. For me, not being able to get a rights update would just be another metric to consider, going back to the earlier discussion around removal for example.
Dumping them all in to one JIRA project just to ease rights updates is a tradeoff, one which I wouldnt make personally at the outset given the choice, as having independently releasable stuff in the same JIRA project can later be cumbersome in its own ways (some of the the ones I manage have that, from previously being a single release that was later split out to 2+). That why at the very least I would keep the independent plugins seperate from the ARTEMIS JIRA project, but would much prefer they just each had their own JIRA projects. Robbie On Sat, 8 Jun 2019 at 22:27, <michael.andre.pea...@me.com.invalid> wrote: > > 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 > > > > > > >
