You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2002/09/26 03:42:27 UTC
Issue tracking - Implementation
I have created modules in Scarab (scarab.werken.com/issues) for the turbine
projects thus:
Global (GLO)
Global > Turbine (TBN)
Global > Turbine > Turbine-2 (TTW)
Global > Turbine > Turbine-2 > Source (TTWS)
Global > Turbine > Turbine-2 > Documentation (TTWD)
Global > Turbine > Turbine-3 (TTH)
Global > Turbine > Turbine-3 > Source (TTHS)
Global > Turbine > Turbine-3 > Documentation (TTHD)
Global > Turbine > Turbine Site (TSIT)
Global > Turbine > Fulcrum (FUL)
Global > Turbine > Fulcrum > Source (FULS)
Global > Turbine > Fulcrum > Documentation (FULD)
Global > Turbine > TDK (TDK)
Global > Turbine > TDK > Source (TDKS)
Global > Turbine > TDK > Documentation (TDKD)
Global > JCS (JCS)
Global > JCS > Source (JCSS)
Global > JCS > Documentation (JCSD)
Global > Torque (TRQ)
Global > Torque > Source (TRQS)
Global > Torque > Documentation (TRQD)
For the codes (shown in brackets above) I have followed the standard used by
the sample projects delivered with Scarab. For those that are curious,
"TTW" is Turbine-2 and "TTH" is Turbine-3 (the codes are a maximum of 4
alpha characters).
Note that the pre-existing Global > Torque module is now known as Global >
Torque > Source and any new issues will be allocated the TRQS prefix (as
opposed to TRQ for the existing issues).
These modules are available now, but will not appear until you request a
role to access them (recommended role type is Developer as I believe
Observer does not allow you to modify any issues you create). There are a
number of container modules (basically all modules that don't end with
"Source" or "Documentation" with the exception of "Turbine Site") that are
not intended for direct use - the best thing to do is to not request roles
for these modules, that way they will not clutter up your module list.
Please recall that Maven is continuing to use the Jira instance at
werken.com and OJB is using the un-maintained Scarab instance at
issues.apache.org/scarab. I will be sending a note to the relevant dev
lists providing them with an update.
I am now proceeding with the following steps:
1. Organizing for an apache.org domain to point to the werken.com Scarab
instance.
2. Updating the project.xml files for the above projects to point to the
werken.com Scarab instance (depending on how difficult it becomes to
establish the apache.org domain name it may be necessary to point these to
the werken.com address as an interim step).
3. Organizing for bugzilla to no longer accept turbine issues.
4. If someone can provide me with the admin userid for the Scarab instance
at issues.apache.org/scarab I will flag the unused modules over there as
deleted.
Help from anyone willing to pitch in on moving the existing issues from
bugzilla over to Scarab would be most welcome.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by Rodney Schneider <ro...@actf.com.au>.
Hi all,
I just tried to register at http://nagoya.apache.org/scarab/issues
with the username "rodney" and it didn't work (stacktrace below).
I was requesting a Developer role in the following modules:
TDK > Documentation
TDK > Source
Torque > Documentation
Torque > Source
Turbine > Site
Turbine > Turbine-2 > Documentation
Turbine > Turbine-2 > Source
I also noticed that there are a few other modules that I am not
sure about:
Global > TDK
Global > Torque
Where should I be reporting TDK issues and Torque issues?
Thanks,
-- Rodney
org.apache.fulcrum.security.util.UnknownEntityException: The account '' does not exist
at org.apache.fulcrum.security.impl.db.DBSecurityService.getACL(DBSecurityService.java:157)
at org.apache.fulcrum.security.TurbineSecurity.getACL(TurbineSecurity.java:325)
at org.tigris.scarab.tools.SecurityAdminTool.getACL(SecurityAdminTool.java:323)
at org.tigris.scarab.tools.SecurityAdminTool.getNonMemberGroups(SecurityAdminTool.java:184)
at org.tigris.scarab.actions.HandleRoleRequests.doRequestroles(HandleRoleRequests.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.turbine.modules.actions.TemplateAction.executeEvents(TemplateAction.java:161)
at org.apache.turbine.modules.ActionEvent.perform(ActionEvent.java:143)
at org.apache.turbine.modules.actions.TemplateSecureAction.perform(TemplateSecureAction.java:90)
at org.apache.turbine.modules.ActionEvent.execute(ActionEvent.java:178)
at org.apache.turbine.pipeline.DefaultActionValve.executeAction(DefaultActionValve.java:139)
at org.apache.turbine.pipeline.DefaultActionValve.invoke(DefaultActionValve.java:100)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultACLCreationValve.invoke(DefaultACLCreationValve.java:120)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.FreshenUserValve.invoke(FreshenUserValve.java:160)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultSessionValidationValve.invoke(DefaultSessionValidationValve.java:123)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultLoginValve.invoke(DefaultLoginValve.java:110)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultSessionTimeoutValve.invoke(DefaultSessionTimeoutValve.java:115)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.DetermineTargetValve.invoke(DetermineTargetValve.java:98)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DetermineActionValve.invoke(DetermineActionValve.java:108)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.ResetCacheValve.invoke(ResetCacheValve.java:108)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.DetermineCharsetValve.invoke(DetermineCharsetValve.java:105)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.TurbinePipeline.invoke(TurbinePipeline.java:211)
at org.apache.turbine.Turbine.doGet(Turbine.java:293)
at org.apache.turbine.Turbine.doPost(Turbine.java:338)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:536)
rethrown as org.apache.turbine.TurbineException: The account '' does not exist
at org.apache.turbine.pipeline.DefaultActionValve.invoke(DefaultActionValve.java:105)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultACLCreationValve.invoke(DefaultACLCreationValve.java:120)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.FreshenUserValve.invoke(FreshenUserValve.java:160)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultSessionValidationValve.invoke(DefaultSessionValidationValve.java:123)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultLoginValve.invoke(DefaultLoginValve.java:110)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DefaultSessionTimeoutValve.invoke(DefaultSessionTimeoutValve.java:115)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.DetermineTargetValve.invoke(DetermineTargetValve.java:98)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.DetermineActionValve.invoke(DetermineActionValve.java:108)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.ResetCacheValve.invoke(ResetCacheValve.java:108)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.tigris.scarab.pipeline.DetermineCharsetValve.invoke(DetermineCharsetValve.java:105)
at org.apache.turbine.pipeline.TurbinePipeline.invokeNext(TurbinePipeline.java:229)
at org.apache.turbine.pipeline.TurbinePipeline.invoke(TurbinePipeline.java:211)
at org.apache.turbine.Turbine.doGet(Turbine.java:293)
at org.apache.turbine.Turbine.doPost(Turbine.java:338)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:536)
Caused by: org.apache.fulcrum.security.util.UnknownEntityException: The account '' does not exist
at org.apache.fulcrum.security.impl.db.DBSecurityService.getACL(DBSecurityService.java:157)
at org.apache.fulcrum.security.TurbineSecurity.getACL(TurbineSecurity.java:325)
at org.tigris.scarab.tools.SecurityAdminTool.getACL(SecurityAdminTool.java:323)
at org.tigris.scarab.tools.SecurityAdminTool.getNonMemberGroups(SecurityAdminTool.java:184)
at org.tigris.scarab.actions.HandleRoleRequests.doRequestroles(HandleRoleRequests.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.turbine.modules.actions.TemplateAction.executeEvents(TemplateAction.java:161)
at org.apache.turbine.modules.ActionEvent.perform(ActionEvent.java:143)
at org.apache.turbine.modules.actions.TemplateSecureAction.perform(TemplateSecureAction.java:90)
at org.apache.turbine.modules.ActionEvent.execute(ActionEvent.java:178)
at org.apache.turbine.pipeline.DefaultActionValve.executeAction(DefaultActionValve.java:139)
at org.apache.turbine.pipeline.DefaultActionValve.invoke(DefaultActionValve.java:100)
... 54 more
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Issue tracking - Implementation but...
Posted by Martin van den Bemt <ml...@mvdb.net>.
I get an exception when registring with my mvdb@apache.org account..
Alert! Sending failed; nested exception is: class
javax.mail.internet.AddressException: Missing local name
Mvgr,
Martin
On Sun, 2002-09-29 at 21:50, John McNally wrote:
> I updated the version of scarab running on nagoya and merged the
> databases previously running at nagoya and werken.com. The new url is:
>
> http://nagoya.apache.org/scarab/issues
>
> There are other urls that one could use, but they lead to css and email
> problems as we don't have same proxy configuration freedom that we had
> at werken.com. For example I recommend against using
> issues.apache.org/scarab/issues. Maybe we can work this out, but it is
> definitely a low priority for me, the above url should be good enough.
>
> Known issues with the merge of data:
>
> 1. Users that had the same username on both machines. As I don't think
> there were many users that were actually using both, instead of going
> the more complex route of combining the accounts, I renamed the username
> on the old nagoya instance from myusername to myusername1. So some
> people have two logins, but the one used on werken.com will probably be
> the one you want to use.
>
> 2. Text search on issues entered on the werken.com installation will
> not work. I will work to rectify this, but I don't think lack of text
> search is that bad, since there are ~20 open issues.
>
> 3. There are some modules which can probably be deleted. The module
> selection screen could definitely use some improvement. Though
> hopefully since most users will only have roles on one or two modules
> this will not be that big a deal.
>
> The main user of the old nagoya installation, OJB, should have all data
> intact. If one person, who is on the ojb lists, could let them know
> that the installation has been upgraded, I would be grateful.
>
> john mcnally
>
> On Fri, 2002-09-27 at 11:36, John McNally wrote:
> > I now have access to nagoya and will attempt to upgrade the instance
> > this weekend. More details will follow. Please continue using werken
> > for torque and if there is a pressing need, to add new projects there,
> > until further notice.
> >
> > john mcnally
> >
> > On Thu, 2002-09-26 at 08:15, Stephen Haberman wrote:
> > > > Bob and I have a managed host at rackspace and I think that's a much
> > > > better option. John McNally has root access as do Bob McWhirter and
> > > > myself. I think we're far better off doing it on the rackspace box.
> > >
> > > Ah, okay, that makes sense.
> > >
> > > Everyone save you, John, and Bob was out of the loop on the nagoya
> > > problems and hence didn't know the reasoning behind the move to werken.
> > >
> > > Now that we've been clued in about the move and the approval of other
> > > Apache management of werken instead of it just being some rogue box, I
> > > think most of us will abandon the 'werken is okay but nagoya is
> > > preferred' mindset.
> > >
> > > Thanks for the info plus the use of the werken box.
> > >
> > >
> > > Scott, you said you were going to look into DNS entries for werken?
> > > Besides scarab.apache.org, I think werken.apache.org would be good as
> > > then the box could potentially used for other, miscellaneous things and
> > > be easily associated with apache.
> > >
> > > (Just my naïve opinion; if there are better/other suggestions, that's
> > > fine)
> > >
> > > Thanks,
> > > Stephen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by Rodney Schneider <ro...@actf.com.au>.
On Thu, 10 Oct 2002 11:16, you wrote:
> Your registration worked. It appears you have a working account. Are
> you unable to login now? If you can login do you see any modules, or
> were you unable to request a role in any of the modules listed above?
I just logged in, but I didn't have access to the modules I requested, so I
had to click the "Request roles" link again.
> If your request really failed and you do not have a role in any of the
> above modules, please try again and email me privately if you experience
> a problem.
This time it worked :)
> > I also noticed that there are a few other modules that I am not
> > sure about:
> > Global > TDK
> > Global > Torque
>
> These are parent modules to the doc and src modules that you did request
> roles in. Don't bother asking for a role in these modules it will keep
> your list smaller and you should not add issues to these modules. They
> are really just container modules for other modules. It is possible to
> define them as such, but I don't think that ever made it into the ui.
> Still a rough area.
OK, thanks for the help John.
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by John McNally <jm...@collab.net>.
On Wed, 2002-10-09 at 18:01, Rodney Schneider wrote:
>
> Hi all,
>
> I just tried to register at http://nagoya.apache.org/scarab/issues
> with the username "rodney" and it didn't work (stacktrace below).
>
> I was requesting a Developer role in the following modules:
> TDK > Documentation
> TDK > Source
> Torque > Documentation
> Torque > Source
> Turbine > Site
> Turbine > Turbine-2 > Documentation
> Turbine > Turbine-2 > Source
Your registration worked. It appears you have a working account. Are
you unable to login now? If you can login do you see any modules, or
were you unable to request a role in any of the modules listed above?
If your request really failed and you do not have a role in any of the
above modules, please try again and email me privately if you experience
a problem.
>
> I also noticed that there are a few other modules that I am not
> sure about:
> Global > TDK
> Global > Torque
>
These are parent modules to the doc and src modules that you did request
roles in. Don't bother asking for a role in these modules it will keep
your list smaller and you should not add issues to these modules. They
are really just container modules for other modules. It is possible to
define them as such, but I don't think that ever made it into the ui.
Still a rough area.
john mcnally
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Issue tracking - Implementation but...
Posted by John McNally <jm...@collab.net>.
I updated the version of scarab running on nagoya and merged the
databases previously running at nagoya and werken.com. The new url is:
http://nagoya.apache.org/scarab/issues
There are other urls that one could use, but they lead to css and email
problems as we don't have same proxy configuration freedom that we had
at werken.com. For example I recommend against using
issues.apache.org/scarab/issues. Maybe we can work this out, but it is
definitely a low priority for me, the above url should be good enough.
Known issues with the merge of data:
1. Users that had the same username on both machines. As I don't think
there were many users that were actually using both, instead of going
the more complex route of combining the accounts, I renamed the username
on the old nagoya instance from myusername to myusername1. So some
people have two logins, but the one used on werken.com will probably be
the one you want to use.
2. Text search on issues entered on the werken.com installation will
not work. I will work to rectify this, but I don't think lack of text
search is that bad, since there are ~20 open issues.
3. There are some modules which can probably be deleted. The module
selection screen could definitely use some improvement. Though
hopefully since most users will only have roles on one or two modules
this will not be that big a deal.
The main user of the old nagoya installation, OJB, should have all data
intact. If one person, who is on the ojb lists, could let them know
that the installation has been upgraded, I would be grateful.
john mcnally
On Fri, 2002-09-27 at 11:36, John McNally wrote:
> I now have access to nagoya and will attempt to upgrade the instance
> this weekend. More details will follow. Please continue using werken
> for torque and if there is a pressing need, to add new projects there,
> until further notice.
>
> john mcnally
>
> On Thu, 2002-09-26 at 08:15, Stephen Haberman wrote:
> > > Bob and I have a managed host at rackspace and I think that's a much
> > > better option. John McNally has root access as do Bob McWhirter and
> > > myself. I think we're far better off doing it on the rackspace box.
> >
> > Ah, okay, that makes sense.
> >
> > Everyone save you, John, and Bob was out of the loop on the nagoya
> > problems and hence didn't know the reasoning behind the move to werken.
> >
> > Now that we've been clued in about the move and the approval of other
> > Apache management of werken instead of it just being some rogue box, I
> > think most of us will abandon the 'werken is okay but nagoya is
> > preferred' mindset.
> >
> > Thanks for the info plus the use of the werken box.
> >
> >
> > Scott, you said you were going to look into DNS entries for werken?
> > Besides scarab.apache.org, I think werken.apache.org would be good as
> > then the box could potentially used for other, miscellaneous things and
> > be easily associated with apache.
> >
> > (Just my naïve opinion; if there are better/other suggestions, that's
> > fine)
> >
> > Thanks,
> > Stephen
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Issue tracking - Implementation but...
Posted by John McNally <jm...@collab.net>.
I now have access to nagoya and will attempt to upgrade the instance
this weekend. More details will follow. Please continue using werken
for torque and if there is a pressing need, to add new projects there,
until further notice.
john mcnally
On Thu, 2002-09-26 at 08:15, Stephen Haberman wrote:
> > Bob and I have a managed host at rackspace and I think that's a much
> > better option. John McNally has root access as do Bob McWhirter and
> > myself. I think we're far better off doing it on the rackspace box.
>
> Ah, okay, that makes sense.
>
> Everyone save you, John, and Bob was out of the loop on the nagoya
> problems and hence didn't know the reasoning behind the move to werken.
>
> Now that we've been clued in about the move and the approval of other
> Apache management of werken instead of it just being some rogue box, I
> think most of us will abandon the 'werken is okay but nagoya is
> preferred' mindset.
>
> Thanks for the info plus the use of the werken box.
>
>
> Scott, you said you were going to look into DNS entries for werken?
> Besides scarab.apache.org, I think werken.apache.org would be good as
> then the box could potentially used for other, miscellaneous things and
> be easily associated with apache.
>
> (Just my naïve opinion; if there are better/other suggestions, that's
> fine)
>
> Thanks,
> Stephen
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Issue tracking - Implementation but...
Posted by Stephen Haberman <st...@chase3000.com>.
> Bob and I have a managed host at rackspace and I think that's a much
> better option. John McNally has root access as do Bob McWhirter and
> myself. I think we're far better off doing it on the rackspace box.
Ah, okay, that makes sense.
Everyone save you, John, and Bob was out of the loop on the nagoya
problems and hence didn't know the reasoning behind the move to werken.
Now that we've been clued in about the move and the approval of other
Apache management of werken instead of it just being some rogue box, I
think most of us will abandon the 'werken is okay but nagoya is
preferred' mindset.
Thanks for the info plus the use of the werken box.
Scott, you said you were going to look into DNS entries for werken?
Besides scarab.apache.org, I think werken.apache.org would be good as
then the box could potentially used for other, miscellaneous things and
be easily associated with apache.
(Just my naïve opinion; if there are better/other suggestions, that's
fine)
Thanks,
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2002-09-26 at 07:07, Scott Eade wrote:
>
> I published this list of steps over on general@jakarta.apache.org and
> received a response from Pier Fumagalli that indicated that if we want it we
> can get the necessary karma to maintain the Scarab instance at
> issues.apache.org/scarab (this is actually the nagoya box).
>
> I think we would all prefer to have only a single scarab install, but which
> one will it be and which project will suffer. Here is the choice:
>
> Either:
> 1: Stick to the migration plan outlined above and try and convince the OJB
> guys to join the other turbine projects over at scarab.werken.com.
> Or
> 2: Update the issues.apache.org/scarab instance and migrate the torque
> issues over from werken.com.
>
> While opinions from everyone are most welcome, I think this decision really
> lies in the hands of Stephen Haberman and John McNally - the people that
> volunteered to maintain the scarab install. I'll just sit on my hands until
> I hear from these two.
We can put the install wherever we like. I've already discussed this
with Brian Behlendorf. I've not had many pleasant experiences using
Nagoya. The combination of it being a Sun box, which I hate working
with, and Pier being somewhat difficult to get a hold of makes Nagoya a
last resort option in my opinion.
Bob and I have a managed host at rackspace and I think that's a much
better option. John McNally has root access as do Bob McWhirter and
myself. I think we're far better off doing it on the rackspace box.
> Cheers,
>
> Scott
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by Martin Poeschl <mp...@marmot.at>.
Jason van Zyl wrote:
> On Thu, 2002-09-26 at 10:13, Martin Poeschl wrote:
>
>
>>>I published this list of steps over on general@jakarta.apache.org and
>>>received a response from Pier Fumagalli that indicated that if we want it we
>>>can get the necessary karma to maintain the Scarab instance at
>>>issues.apache.org/scarab (this is actually the nagoya box).
>>>
>>>I think we would all prefer to have only a single scarab install, but which
>>>one will it be and which project will suffer. Here is the choice:
>>>
>>>Either:
>>>1: Stick to the migration plan outlined above and try and convince the OJB
>>>guys to join the other turbine projects over at scarab.werken.com.
>>
>>-0
>>
>>
>>>Or
>>>2: Update the issues.apache.org/scarab instance and migrate the torque
>>>issues over from werken.com.
>>
>>+1
>>
>>we should use nagoya if possible ...
>
>
> Why? I don't think you know anything about trying to work on Nagoya. If
> you want to manage the install on Nagoya have fun pulling your hair out.
ok, if handling the scarab installation on nagoya is a pain ... and the istallation on werken.com is
open for all apache projects
+1
but there should be only one installation!!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2002-09-26 at 10:13, Martin Poeschl wrote:
> > I published this list of steps over on general@jakarta.apache.org and
> > received a response from Pier Fumagalli that indicated that if we want it we
> > can get the necessary karma to maintain the Scarab instance at
> > issues.apache.org/scarab (this is actually the nagoya box).
> >
> > I think we would all prefer to have only a single scarab install, but which
> > one will it be and which project will suffer. Here is the choice:
> >
> > Either:
> > 1: Stick to the migration plan outlined above and try and convince the OJB
> > guys to join the other turbine projects over at scarab.werken.com.
>
> -0
>
> > Or
> > 2: Update the issues.apache.org/scarab instance and migrate the torque
> > issues over from werken.com.
>
> +1
>
> we should use nagoya if possible ...
Why? I don't think you know anything about trying to work on Nagoya. If
you want to manage the install on Nagoya have fun pulling your hair out.
> martin
>
> >
> > While opinions from everyone are most welcome, I think this decision really
> > lies in the hands of Stephen Haberman and John McNally - the people that
> > volunteered to maintain the scarab install. I'll just sit on my hands until
> > I hear from these two.
> >
> > Cheers,
> >
> > Scott
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by Martin Poeschl <mp...@marmot.at>.
Scott Eade wrote:
>>From: Scott Eade <se...@backstagetech.com.au>
>>
>>I am now proceeding with the following steps:
>>1. Organizing for an apache.org domain to point to the werken.com Scarab
>>instance.
>>2. Updating the project.xml files for the above projects to point to the
>>werken.com Scarab instance (depending on how difficult it becomes to
>>establish the apache.org domain name it may be necessary to point these to
>>the werken.com address as an interim step).
>>3. Organizing for bugzilla to no longer accept turbine issues.
>>4. If someone can provide me with the admin userid for the Scarab instance
>>at issues.apache.org/scarab I will flag the unused modules over there as
>>deleted.
>
>
> I published this list of steps over on general@jakarta.apache.org and
> received a response from Pier Fumagalli that indicated that if we want it we
> can get the necessary karma to maintain the Scarab instance at
> issues.apache.org/scarab (this is actually the nagoya box).
>
> I think we would all prefer to have only a single scarab install, but which
> one will it be and which project will suffer. Here is the choice:
>
> Either:
> 1: Stick to the migration plan outlined above and try and convince the OJB
> guys to join the other turbine projects over at scarab.werken.com.
-0
> Or
> 2: Update the issues.apache.org/scarab instance and migrate the torque
> issues over from werken.com.
+1
we should use nagoya if possible ...
martin
>
> While opinions from everyone are most welcome, I think this decision really
> lies in the hands of Stephen Haberman and John McNally - the people that
> volunteered to maintain the scarab install. I'll just sit on my hands until
> I hear from these two.
>
> Cheers,
>
> Scott
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Issue tracking - Implementation but...
Posted by Stephen Haberman <st...@chase3000.com>.
> 2: Update the issues.apache.org/scarab instance and migrate the torque
> issues over from werken.com.
+0 with either an update or (preferably to me, though an upgrade for the
OJB people would be nice) clean install. This what John and I had
initially wanted, but from what I gathered, John never heard back from
Pier, so he finally gave up and installed Scarab on the werken box.
I'll defer to John on this one; if he's willing to upgrade/install
Scarab on nagoya, I'll help move the issues over.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Issue tracking - Implementation but...
Posted by Scott Eade <se...@backstagetech.com.au>.
> From: Scott Eade <se...@backstagetech.com.au>
>
> I am now proceeding with the following steps:
> 1. Organizing for an apache.org domain to point to the werken.com Scarab
> instance.
> 2. Updating the project.xml files for the above projects to point to the
> werken.com Scarab instance (depending on how difficult it becomes to
> establish the apache.org domain name it may be necessary to point these to
> the werken.com address as an interim step).
> 3. Organizing for bugzilla to no longer accept turbine issues.
> 4. If someone can provide me with the admin userid for the Scarab instance
> at issues.apache.org/scarab I will flag the unused modules over there as
> deleted.
I published this list of steps over on general@jakarta.apache.org and
received a response from Pier Fumagalli that indicated that if we want it we
can get the necessary karma to maintain the Scarab instance at
issues.apache.org/scarab (this is actually the nagoya box).
I think we would all prefer to have only a single scarab install, but which
one will it be and which project will suffer. Here is the choice:
Either:
1: Stick to the migration plan outlined above and try and convince the OJB
guys to join the other turbine projects over at scarab.werken.com.
Or
2: Update the issues.apache.org/scarab instance and migrate the torque
issues over from werken.com.
While opinions from everyone are most welcome, I think this decision really
lies in the hands of Stephen Haberman and John McNally - the people that
volunteered to maintain the scarab install. I'll just sit on my hands until
I hear from these two.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>