Ben told me that officially it is Brett who is responsible to create Mojo projects. Brett, are you always monitoring these tasks ?
On Fri, Sep 5, 2014 at 11:18 AM, Arnaud Héritier <aherit...@codehaus.org> wrote: > I just checked and there are very few admins around Ben Walding to manage > administrative tasks > * Bob McWhirter > * Brett Porter > * Olivier Gaudin > * Stephen Connolly > * and me > > Perhaps this is something to discuss with Ben about Codehaus systems > management ? > Perhaps he may need some help if we consider that the process delay is too > long ... > > > > > On Thu, Sep 4, 2014 at 9:24 PM, Robert Scholte <codeh...@sourcegrounds.com > > wrote: > >> Hi, >> >> If you compare the differences between Apaches PMC and teammembers, then >> the difference between a Codehaus despot and teammember is much smaller. >> Teammembers already have a lot of rights for the infrastructure[1], >> there's no such thing as binding votes. Main difference between a despot >> and a teammember is that Xircles gives you extra options to manage users >> for the project. So actually you become your own secretary ;) >> >> The problem Dan was facing won't disappear when we have more despots. So >> if we want a new Jira-project, we still depend on Jira Admins. >> >> Robert >> >> [1] http://mojo.codehaus.org/development/codehaus-support.html >> >> Op Wed, 03 Sep 2014 18:37:25 +0200 schreef Arnaud Héritier < >> aherit...@codehaus.org>: >> >> >> There is something to take care. Being despot doesn't give us the jira >>> administration privilege required to create new projects. >>> The thing to do is to ask to Ben if we could have more Jira admins to >>> create these projects. >>> >>> (And yes +1 to have more despots too) >>> >>> >>> On Wed, Sep 3, 2014 at 6:20 PM, Dan Tran <dant...@gmail.com> wrote: >>> >>> +1 for more Depots >>>> >>>> I have been with this project since beginning, will be glad helping out >>>> >>>> Thanks >>>> >>>> -D >>>> >>>> >>>> On Wed, Sep 3, 2014 at 9:16 AM, Baptiste Mathus <bapti...@codehaus.org> >>>> wrote: >>>> >>>> I think that if this discussion is raised only because it's difficult >>>>> to >>>>> have a despot create the project in jira, then we may just want to have >>>>> more despots. Changing the release process not because it's having an >>>>> issue >>>>> in itself seems wrong to me. >>>>> >>>>> Like Arnaud, I also think it's a wee bit better to have a dedicated >>>>> project when out of pre-release state. >>>>> >>>>> My 2 cents >>>>> Le 3 sept. 2014 10:00, "Arnaud Héritier" <aherit...@codehaus.org> a >>>>> écrit : >>>>> >>>>> I would prefer to have a jira project per mojo when they are stable >>>>> >>>>>> AFAIK I'm always despot + jira administrator and can create projects >>>>>> if >>>>>> you need but don't hesitate to ping me directly because I'm not >>>>>> reading all >>>>>> mojo MLs threads >>>>>> >>>>>> >>>>>> On Wed, Sep 3, 2014 at 9:39 AM, Anders Hammar <and...@hammar.net> >>>>>> wrote: >>>>>> >>>>>> One problem is that the JIRA URL is on the produced mojo site, so >>>>>>> creating the JIRA project after the release requires a new release to >>>>>>> update the site. >>>>>>> >>>>>>> /Anders >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 3, 2014 at 9:31 AM, Dan Tran <dant...@gmail.com> wrote: >>>>>>> >>>>>>> Correct >>>>>>>> >>>>>>>> -Dan >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, September 2, 2014, Anders Hammar <and...@hammar.net> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Not sure what you mean. Do you want to make a 1.0 release without a >>>>>>>>> mojo specific JIRA project? >>>>>>>>> >>>>>>>>> /Anders >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Sep 3, 2014 at 8:29 AM, Dan Tran <dant...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Currently in order for a component to become 1.0, it just have a >>>>>>>>>> Jira project. So far we have a hard time getting depot to manage >>>>>>>>>> this >>>>>>>>>> procedure. >>>>>>>>>> >>>>>>>>>> Could we just mangen it like the way Jenkins does with plugin? a >>>>>>>>>> component id is just good enough >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> -Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
