Re: [boost] Slow Bugs Tracker
Olaf van der Spek
A few months ago there seemed to be plans to improve Trac. What's the
status of those plans?
Trac is still slow as hell.
http://lists.boost.org/Archives/boost/2011/12/188639.php
http://lists.boost.org/Archives/boost/2011/12/188937.php
--
Olaf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Olaf van der Spek
> Hi,
>
> A few months ago there seemed to be plans to improve Trac. What's the
> status of those plans?
> Trac is still slow as hell.
>
> http://lists.boost.org/Archives/boost/2011/12/188639.php
> http://lists.boost.org/Archives/boost/2011/12/188937.php
Somebody?
Who's responsible for Boost infrastructure?
Olaf van der Spek
> On Sun, Feb 12, 2012 at 1:49 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>> Hi,
>>
>> A few months ago there seemed to be plans to improve Trac. What's the
>> status of those plans?
>> Trac is still slow as hell.
>>
>> http://lists.boost.org/Archives/boost/2011/12/188639.php
>> http://lists.boost.org/Archives/boost/2011/12/188937.php
>
> Somebody?
> Who's responsible for Boost infrastructure?
Nobody?
I'm sure I'm not the only one that's affected by Trac's slowness.
Dave Abrahams
on Wed Feb 29 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Thu, Feb 16, 2012 at 4:22 PM, Olaf van der Spek <m...@vdspek.org> wrote:
>> On Sun, Feb 12, 2012 at 1:49 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>>> Hi,
>>>
>>> A few months ago there seemed to be plans to improve Trac. What's the
>>> status of those plans?
>>> Trac is still slow as hell.
>>>
>>> http://lists.boost.org/Archives/boost/2011/12/188639.php
>>> http://lists.boost.org/Archives/boost/2011/12/188937.php
>>
>> Somebody?
>> Who's responsible for Boost infrastructure?
>
> Nobody?
>
> I'm sure I'm not the only one that's affected by Trac's slowness.
We *were* in communication with OSUOSL about providing more powerful
hosting resources for Boost, but since our last communication with them
was in December and we still haven't gotten a reply, I wonder if we
should consider them a reliable resource. Indiana has been good to us,
and maybe it's just a question of asking them to allocate more
resources...
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
>
> on Wed Feb 29 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>
>> On Thu, Feb 16, 2012 at 4:22 PM, Olaf van der Spek <m...@vdspek.org> wrote:
>>> On Sun, Feb 12, 2012 at 1:49 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>>>> Hi,
>>>>
>>>> A few months ago there seemed to be plans to improve Trac. What's the
>>>> status of those plans?
>>>> Trac is still slow as hell.
>>>>
>>>> http://lists.boost.org/Archives/boost/2011/12/188639.php
>>>> http://lists.boost.org/Archives/boost/2011/12/188937.php
>>>
>>> Somebody?
>>> Who's responsible for Boost infrastructure?
>>
>> Nobody?
>>
>> I'm sure I'm not the only one that's affected by Trac's slowness.
>
> We *were* in communication with OSUOSL about providing more powerful
> hosting resources for Boost, but since our last communication with them
> was in December and we still haven't gotten a reply, I wonder if we
> should consider them a reliable resource. Indiana has been good to us,
> and maybe it's just a question of asking them to allocate more
> resources...
Somebody?
--
Olaf
Rene Rivera
> On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <da...@boostpro.com> wrote:
> > We *were* in communication with OSUOSL about providing more powerful
>
> Somebody?
>
We are, slowly, working to get the OSUOSL system set up. But we at lest
have the Boost VM running in their cluster.
--
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Robert Ramey
> On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <m...@vdspek.org>
> wrote:
>
>> On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <da...@boostpro.com>
>> wrote:
>>> We *were* in communication with OSUOSL about providing more powerful
>>
>> Somebody?
>>
>
> We are, slowly, working to get the OSUOSL system set up. But we at
> lest have the Boost VM running in their cluster.
>
>
> --
There is a large selection of hosting (cheap or free) services for bug
tracking services
including track. WHen I log in to trac I think I remember that typically
there
are only 1 or 2 other users on line at the same time. So I wouldn't expect
we'd need more than the simplest solution.
SourceForge also provides this service (free) on request. So there are lots
of options.
Robert Ramey
Olaf van der Spek
> On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>
>> On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <da...@boostpro.com> wrote:
>> > We *were* in communication with OSUOSL about providing more powerful
>>
>> Somebody?
>>
>
> We are, slowly, working to get the OSUOSL system set up. But we at lest
> have the Boost VM running in their cluster.
Good to hear. Who is we though?
And why slowly?
--
Olaf
Olaf van der Spek
> On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafi...@gmail.com> wrote:
>> On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>>
>>> On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <da...@boostpro.com> wrote:
>>> > We *were* in communication with OSUOSL about providing more powerful
>>>
>>> Somebody?
>>>
>>
>> We are, slowly, working to get the OSUOSL system set up. But we at lest
>> have the Boost VM running in their cluster.
>
> Good to hear. Who is we though?
> And why slowly?
^
Dave Abrahams
on Thu Mar 08 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafi...@gmail.com> wrote:
>> On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>>
>>> On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <da...@boostpro.com> wrote:
>>> > We *were* in communication with OSUOSL about providing more powerful
>>>
>>> Somebody?
>>>
>>
>> We are, slowly, working to get the OSUOSL system set up. But we at lest
>> have the Boost VM running in their cluster.
>
> Good to hear. Who is we though?
> And why slowly?
These are good questions. Rene and I have been the primary
points-of-contact with OSUOSL, and we're busy. It would be wonderful if
some other qualified person wanted to take over pushing this transition
forward.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
>
> on Thu Mar 08 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>
>> On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafi...@gmail.com> wrote:
>>> On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>>>
>>>> On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <da...@boostpro.com> wrote:
>>>> > We *were* in communication with OSUOSL about providing more powerful
>>>>
>>>> Somebody?
>>>>
>>>
>>> We are, slowly, working to get the OSUOSL system set up. But we at lest
>>> have the Boost VM running in their cluster.
>>
>> Good to hear. Who is we though?
>> And why slowly?
>
> These are good questions. Rene and I have been the primary
> points-of-contact with OSUOSL, and we're busy. It would be wonderful if
> some other qualified person wanted to take over pushing this transition
> forward.
I'd be happy to help out.
Is there a concrete plan?
--
Olaf
Dave Abrahams
on Thu Mar 15 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Wed, Mar 14, 2012 at 11:30 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>
>> on Thu Mar 08 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>>
>>> On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafi...@gmail.com> wrote:
>>>> On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <m...@vdspek.org> wrote:
>
>>>>
>>>>> On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <da...@boostpro.com> wrote:
>>>>> > We *were* in communication with OSUOSL about providing more powerful
>>>>>
>>>>> Somebody?
>>>>>
>>>>
>>>> We are, slowly, working to get the OSUOSL system set up. But we at lest
>>>> have the Boost VM running in their cluster.
>>>
>>> Good to hear. Who is we though?
>>> And why slowly?
>>
>> These are good questions. Rene and I have been the primary
>> points-of-contact with OSUOSL, and we're busy. It would be wonderful if
>> some other qualified person wanted to take over pushing this transition
>> forward.
>
> I'd be happy to help out.
>
> Is there a concrete plan?
Not a very concrete one. Someone needs to do some planning, too. IMHO,
we should set up Redmine at OSUOSL and make a transition to that almost
immediately, because the conversion can be pretty much automatic.
Beman is on the warpath (with my support) to transition us to Git in the
near future. It's not clear whether we will end up with a monolithic
transition (https://github.com/ryppl/boost-history) as a first step, or
whether we will go directly to a modularized setup
(https://github.com/boost-lib/boost/tree/master/libs).
That will require some work on the Redmine end, I expect. OSUOSL can
probably help us with some of the Redmine database rewrites that will be
required, but I am not sure of that.
At that point we should probably also give each library its own Redmine
project, or, if we are modularized at that point, possibly give library
maintainers the option to use the GitHub issue tracker associated with
the library's repository there.
As far as I'm concerned, anyone around here who expresses willingness to
make this transition happen (with help from others) and confidence in
his/her abilities to do it has my blessing. We may want to take a quick
vote in the steering committee to make sure the plan is "officially
blessed."
-Dave
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
>>
>> Is there a concrete plan?
>
> Not a very concrete one. Someone needs to do some planning, too. IMHO,
> we should set up Redmine at OSUOSL and make a transition to that almost
> immediately, because the conversion can be pretty much automatic.
Has the decision to move to Redmine been made (already)? Last time
some were arguing Trac might be 'fine'.
> That will require some work on the Redmine end, I expect. OSUOSL can
> probably help us with some of the Redmine database rewrites that will be
> required, but I am not sure of that.
>
> At that point we should probably also give each library its own Redmine
> project, or, if we are modularized at that point, possibly give library
> maintainers the option to use the GitHub issue tracker associated with
> the library's repository there.
Why not move to a GH tracker right away?
Olaf
Dave Abrahams
on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>>> I'd be happy to help out.
>>>
>>> Is there a concrete plan?
>>
>> Not a very concrete one. Someone needs to do some planning, too. IMHO,
>> we should set up Redmine at OSUOSL and make a transition to that almost
>> immediately, because the conversion can be pretty much automatic.
>
> Has the decision to move to Redmine been made (already)? Last time
> some were arguing Trac might be 'fine'.
We've also heard from people who say that they've never used a large
Trac installation that wasn't slow. I guess the steering committee
hasn't voted on this. If you want a formal decision before proceeding,
please request that Beman take a vote in the steering committee.
>> That will require some work on the Redmine end, I expect. OSUOSL can
>> probably help us with some of the Redmine database rewrites that will be
>> required, but I am not sure of that.
>>
>> At that point we should probably also give each library its own Redmine
>> project, or, if we are modularized at that point, possibly give library
>> maintainers the option to use the GitHub issue tracker associated with
>> the library's repository there.
>
> Why not move to a GH tracker right away?
The main reasons:
1. We don't know that it's possible to preserve all the information from
Trac in such a conversion.
2. GH trackers are not well-suited to multi-project repositories. Until
we are modularized IMO it doesn't make sense.
3. Redmine (with the appropriate plugin) supports code review, whereas
GitHub only supports change review. That's a significant and
problematic difference where the formal review process is concerned.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
> We've also heard from people who say that they've never used a large
> Trac installation that wasn't slow. I guess the steering committee
> hasn't voted on this. If you want a formal decision before proceeding,
> please request that Beman take a vote in the steering committee.
I don't mind. Can the move be completed without formal decision?
If not, now seems like the right time to make that decision.
How should I proceed?
Who manages Trac?
IIRC there was also talk about moving to a new VM?
Olaf
Dave Abrahams
on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Mon, Mar 19, 2012 at 6:14 PM, Dave Abrahams <da...@boostpro.com> wrote:
>> We've also heard from people who say that they've never used a large
>> Trac installation that wasn't slow. I guess the steering committee
>> hasn't voted on this. If you want a formal decision before proceeding,
>> please request that Beman take a vote in the steering committee.
>
> I don't mind. Can the move be completed without formal decision?
Probably, but to know that I think the steering committee would have to
say "we decline to decide"... which is about the same as making a
decision.
> If not, now seems like the right time to make that decision.
>
> How should I proceed?
Request that Beman take a vote in the steering committee, I guess.
> Who manages Trac?
Dong-inn Kim at IU's OSL (Cc'd) holds the sysadmin keys. We have lots
of people with admin privileges on the trac site itself.
> IIRC there was also talk about moving to a new VM?
Yes; what's the question?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Rene Rivera
>
> on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>
> > On Mon, Mar 19, 2012 at 6:14 PM, Dave Abrahams <da...@boostpro.com>
> wrote:
> > Who manages Trac?
>
> Dong-inn Kim at IU's OSL (Cc'd) holds the sysadmin keys. We have lots
> of people with admin privileges on the trac site itself.
>
I can also do admin/root tasks on the web site. Not that I will have time
this week.. But I might a little more next week onward.
--
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Olaf van der Spek
>
> on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>
>> On Mon, Mar 19, 2012 at 6:14 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>> We've also heard from people who say that they've never used a large
>>> Trac installation that wasn't slow. I guess the steering committee
>>> hasn't voted on this. If you want a formal decision before proceeding,
>>> please request that Beman take a vote in the steering committee.
>>
>> I don't mind. Can the move be completed without formal decision?
>
> Probably, but to know that I think the steering committee would have to
> say "we decline to decide"... which is about the same as making a
> decision.
>> If not, now seems like the right time to make that decision.
>>
>> How should I proceed?
>
> Request that Beman take a vote in the steering committee, I guess.
Hi Beman,
Trac (performance) isn't good, we'd like to replace it with Redmine.
Is the steering committe ok with this?
--
Olaf
Beman Dawes
> Hi Beman,
>
> Trac (performance) isn't good, we'd like to replace it with Redmine.
> Is the steering committe ok with this?
The steering committee would need a short proposal document that lays
out the motivation for a change, the pros and cons of Redmine vs Trac,
and how the transition would be accomplished. Plus a few links to
relevant info. That will give the SC something specific to vote on.
Personally, Redmine seems a good choice, but I've a couple of concerns:
IIUC, performance is a major motivation. A quick try with google found
many assertions that Redmine was faster than Trac, but no actual
performance measurements. Has performance actually been measured?
I also came across a case where someone moved from Trac to Redmine,
then moved back again a year later because they weren't familiar
enough with Ruby on Rails, and that caused them admin problems. Is
that also a likely problem for Boost?
--Beman
Olaf van der Spek
> On Thu, Mar 22, 2012 at 12:44 PM, Olaf van der Spek <m...@vdspek.org> wrote:
>> Hi Beman,
>>
>> Trac (performance) isn't good, we'd like to replace it with Redmine.
>> Is the steering committe ok with this?
>
> The steering committee would need a short proposal document that lays
> out the motivation for a change, the pros and cons of Redmine vs Trac,
> and how the transition would be accomplished. Plus a few links to
> relevant info. That will give the SC something specific to vote on.
>
> Personally, Redmine seems a good choice, but I've a couple of concerns:
>
> IIUC, performance is a major motivation. A quick try with google found
> many assertions that Redmine was faster than Trac, but no actual
> performance measurements. Has performance actually been measured?
>
> I also came across a case where someone moved from Trac to Redmine,
> then moved back again a year later because they weren't familiar
> enough with Ruby on Rails, and that caused them admin problems. Is
> that also a likely problem for Boost?
Dave, Rene,
What has been done already?
Performance analysis of current situation?
What other issue tracker improvement requests exist?
IIRC Dave came up with Redmine. Was this discussed already? Might
another tracker / solution be better?
--
Olaf
Dave Abrahams
on Fri Mar 23 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
> On Thu, Mar 22, 2012 at 12:44 PM, Olaf van der Spek <m...@vdspek.org> wrote:
>> Hi Beman,
>>
>> Trac (performance) isn't good, we'd like to replace it with Redmine.
>> Is the steering committe ok with this?
>
> The steering committee would need a short proposal document that lays
> out the motivation for a change, the pros and cons of Redmine vs Trac,
> and how the transition would be accomplished. Plus a few links to
> relevant info. That will give the SC something specific to vote on.
>
> Personally, Redmine seems a good choice, but I've a couple of concerns:
>
> IIUC, performance is a major motivation. A quick try with google found
> many assertions that Redmine was faster than Trac, but no actual
> performance measurements. Has performance actually been measured?
Unlikely. I'm guessing the best way to know whether the speed works for
us is to attempt the migration and see how it goes.
> I also came across a case where someone moved from Trac to Redmine,
> then moved back again a year later because they weren't familiar
> enough with Ruby on Rails, and that caused them admin problems. Is
> that also a likely problem for Boost?
No. I don't know jack about RoR and have been administering a Redmine
installation for a few years with great success.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
I don't mind working on this, but I do need some starting pointers. Please...
Olaf van der Spek
> On Mon, Apr 9, 2012 at 9:46 PM, Dave Abrahams <da...@boostpro.com> wrote:
>> Oh my! I hadn't heard about that at all. It does complicate things
>> quite a bit. On first inspection it looks like ChiliProject has more
>> energy than Redmine but of course it's hard to know if these things will
>> sustain themselves. I guess under these circumstances I'd be inclined
>> to suggest that we first try a Trac instance hosted at OSUOSL and see if
>> that changes anything, to give us a little more time to see if
>> ChiliProject looks like it's going to win. Getting off Trac makes sense
>> in the long run for various reasons, but that can wait if we can get a
>> speedup in some other way.
>>
>>> Also, Redmine being faster looks true for my experience, BUT the scale of
>>> boost project and the fact that a lot of people can access it makes me
>>> think that maybe Redmine will be as slow as TRAC for this project with the
>>> same hardware
>>
>> We wouldn't be constrained to the same hardware; it would be hosted by
>> OSUOSL, which has more resources.
>
> Who will perform the move?
...
Dave Abrahams
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Thu, Apr 12, 2012 at 9:08 PM, Olaf van der Spek <m...@vdspek.org> wrote:
>> On Mon, Apr 9, 2012 at 9:46 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>> Oh my! I hadn't heard about that at all. It does complicate things
>>> quite a bit. On first inspection it looks like ChiliProject has more
>>> energy than Redmine but of course it's hard to know if these things will
>>> sustain themselves. I guess under these circumstances I'd be inclined
>
>>> to suggest that we first try a Trac instance hosted at OSUOSL and see if
>>> that changes anything, to give us a little more time to see if
>>> ChiliProject looks like it's going to win. Getting off Trac makes sense
>>> in the long run for various reasons, but that can wait if we can get a
>>> speedup in some other way.
>>>
>>>> Also, Redmine being faster looks true for my experience, BUT the scale of
>>>> boost project and the fact that a lot of people can access it makes me
>>>> think that maybe Redmine will be as slow as TRAC for this project with the
>>>> same hardware
>>>
>>> We wouldn't be constrained to the same hardware; it would be hosted by
>>> OSUOSL, which has more resources.
>>
>> Who will perform the move?
>
> ...
I don't think anyone understands the question. What do you mean by
"perform the move?"
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
>>>> We wouldn't be constrained to the same hardware; it would be hosted by
>>>> OSUOSL, which has more resources.
>>>
>>> Who will perform the move?
>>
>> ...
>
> I don't think anyone understands the question. What do you mean by
> "perform the move?"
Moving Trac from it's current host to OSUOSL.
What's the plan? Who's going to execute it?
> I guess under these circumstances I'd be inclined
to suggest that we first try a Trac instance hosted at OSUOSL and see if
that changes anything, to give us a little more time to see if
ChiliProject looks like it's going to win. Getting off Trac makes sense
in the long run for various reasons, but that can wait if we can get a
speedup in some other way.
--
Olaf
Dave Abrahams
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Thu, Apr 19, 2012 at 8:36 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>>>> We wouldn't be constrained to the same hardware; it would be hosted by
>>>>> OSUOSL, which has more resources.
>>>>
>>>> Who will perform the move?
>>>
>>> ...
>>
>> I don't think anyone understands the question. What do you mean by
>> "perform the move?"
>
> Moving Trac from it's current host to OSUOSL. What's the plan? Who's
> going to execute it?
I don't understand; didn't you volunteer to make this happen?
Presumably it would take cooperation between a Booster and sysadmins at
both IUOSL and OSUOSL.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
>>> I don't think anyone understands the question. What do you mean by
>>> "perform the move?"
>>
>> Moving Trac from it's current host to OSUOSL. What's the plan? Who's
>> going to execute it?
>
> I don't understand; didn't you volunteer to make this happen?
> Presumably it would take cooperation between a Booster and sysadmins at
> both IUOSL and OSUOSL.
I did and still do.
But I don't know what to do. Who (from Boost) is dealing with IUOSL
and OSUOSL? Who is managing the website and existing Trac instance?
--
Olaf
Dave Abrahams
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>>> I don't think anyone understands the question. What do you mean by
>>>> "perform the move?"
>>>
>>> Moving Trac from it's current host to OSUOSL. What's the plan? Who's
>>> going to execute it?
>>
>> I don't understand; didn't you volunteer to make this happen?
>> Presumably it would take cooperation between a Booster and sysadmins at
>> both IUOSL and OSUOSL.
>
> I did and still do.
> But I don't know what to do.
I can put you in touch with the IUOSL and OSUOSL people. A big part of this
job consists of "figuring out what to do," so you not knowing what to do
is part of the game, so to speak.
> Who (from Boost) is dealing with IUOSL and OSUOSL?
A number of us deal with IUOSL from time to time. I think the OSUOSL
interaction has mostly been me and Renée.
> Who is managing the website
The website, meaning http://boost.org? It probably depends what you
mean by "managing..." but in any case I don't think I know who's doing
it, and I'm not sure it's relevant to the bug tracker migration.
> and existing Trac instance?
The moderators and maybe a few others have admin privileges on the Trac
instance via its web interface. For lower-level control, you have to
deal with Dong-Inn Kim, the IUOSL sysadmin.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
>
> on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>
>> On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>>>> I don't think anyone understands the question. What do you mean by
>>>>> "perform the move?"
>>>>
>>>> Moving Trac from it's current host to OSUOSL. What's the plan? Who's
>>>> going to execute it?
>>>
>>> I don't understand; didn't you volunteer to make this happen?
>>> Presumably it would take cooperation between a Booster and sysadmins at
>>> both IUOSL and OSUOSL.
>>
>> I did and still do.
>> But I don't know what to do.
>
> I can put you in touch with the IUOSL and OSUOSL people. A big part of this
Please do, let's get started.
> job consists of "figuring out what to do," so you not knowing what to do
> is part of the game, so to speak.
I understand, but I need some starting pointers.
>> Who (from Boost) is dealing with IUOSL and OSUOSL?
>
> A number of us deal with IUOSL from time to time. I think the OSUOSL
> interaction has mostly been me and Renée.
>
>> Who is managing the website
>
> The website, meaning http://boost.org? It probably depends what you
> mean by "managing..." but in any case I don't think I know who's doing
> it, and I'm not sure it's relevant to the bug tracker migration.
Maybe not, I don't know whether the two are integrated or entirely separate.
>> and existing Trac instance?
>
> The moderators and maybe a few others have admin privileges on the Trac
> instance via its web interface. For lower-level control, you have to
> deal with Dong-Inn Kim, the IUOSL sysadmin.
OK
--
Olaf
Olaf van der Spek
Dave Abrahams
Hi Olaf,
If you have a specific question, please ask it. I have answered all the
direct questions you've asked so far, AFAIK.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Olaf van der Spek
> If you have a specific question, please ask it. I have answered all the
> direct questions you've asked so far, AFAIK.
>>>> I can put you in touch with the IUOSL and OSUOSL people. A big part of this
>>>
>>> Please do, let's get started.
Olaf
Dave Abrahams
on Sun Apr 29 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Sun, Apr 29, 2012 at 4:26 AM, Dave Abrahams <da...@boostpro.com> wrote:
>> If you have a specific question, please ask it. I have answered all the
>> direct questions you've asked so far, AFAIK.
>
> I'm confused. Did you miss my in-line responses?
Perhaps. Let me try again.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Dave Abrahams
on Fri Apr 20 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> On Fri, Apr 20, 2012 at 1:30 AM, Dave Abrahams <da...@boostpro.com> wrote:
>>
>> on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
>>
>>> On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <da...@boostpro.com> wrote:
>>>>>> I don't think anyone understands the question. What do you mean by
>
>>>>>> "perform the move?"
>>>>>
>>>>> Moving Trac from it's current host to OSUOSL. What's the plan? Who's
>>>>> going to execute it?
>>>>
>>>> I don't understand; didn't you volunteer to make this happen?
>>>> Presumably it would take cooperation between a Booster and sysadmins at
>>>> both IUOSL and OSUOSL.
>>>
>>> I did and still do.
>>> But I don't know what to do.
>>
>> I can put you in touch with the IUOSL and OSUOSL people. A big part of this
>
> Please do, let's get started.
OK, will do.
>> The website, meaning http://boost.org? It probably depends what you
>> mean by "managing..." but in any case I don't think I know who's doing
>> it, and I'm not sure it's relevant to the bug tracker migration.
>
> Maybe not, I don't know whether the two are integrated or entirely separate.
They are entirely separate AFAIK.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com