I went ahead and pinged Infra in the slack channel to see if there's anything we can do to control multiple project permissions together.
On Mon, Jun 10, 2019 at 5:32 AM Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > 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 > > > > > > > > > > > > > >
