[prev in list] [next in list] [prev in thread] [next in thread]
List: activemq-dev
Subject: Re: [DISCUSS] Component/Plugin repository
From: Robbie Gemmell <robbie.gemmell () gmail ! com>
Date: 2019-06-10 10:45:38
Message-ID: CAFitrpSctYN__GQ-2L1_YBe7DTCCg+B53ZGNYKrO1gnAT_Ektg () mail ! gmail ! com
[Download RAW message or body]
There are groups that could be used to ease such things (though again,
its not difficult without) but infra seemed to explicitly move away
from using them in the past, I think as they needed to administer them
centrally with they didnt have bandwidth for. Perhaps some of that
might have changed.
On Mon, 10 Jun 2019 at 11:37, Christopher Shannon
<christopher.l.shannon@gmail.com> wrote:
>
> 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.gemmell@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.pearce@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.gemmell@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.suconic@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
> > > >
> > >
> > >
> > >
> > >
> > >
> >
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic