Installation instructions
Simon Law
installation instructions. Are there any?
Failing that, which source files do I have to look at to figure out the
fields for the INI-files?
Cheers,
--
Simon Law http://www.law.yi.org/~sfllaw/
Avery Pennarun
>
> I've looked through the source tree and I can't seem to find any
> installation instructions. Are there any?
>
> Failing that, which source files do I have to look at to figure out the
> fields for the INI-files?
Ah, documentation. How I so often forget to write it. Look at
wvdbi.cs for where it actually uses the config file. But here's a
sample wvodbc.ini:
[myfogbugz-odbc]
driver = MySQL
server = localhost
database = fogbugz
user = WHATEVER
password = WHATEVER2
Then your schedule can contain a line like:
import bug fogbugz:myfogbugz-odbc
...to activate it. All tasks imported from *that* fogbugz instance
would be tagged like "bug:1123". If you're using more than one bug
tracking system, be sure to give each one a different tag (bug, bug2,
bug3, or whatever unique string you want).
If you want to store the results in a database for postprocessing, you
can put that in the same ODBC database or create a separate one, and
add a line like this to your schedule:
import result result:myschedulator-odbc
...schedulator will create and fill the Schedule table automatically
in the database you specify.
Instead of using wvodbc.ini, you can also write an entire ODBC driver
string (driver=blah;uid=blah, etc) directly in the "import" line. But
there's no really good reason to do that (I think).
Also, in most cases you'll want all your users to pull in all your bug
tracking systems by default. To do that, create a file called
system.sched (*not* in the schedules subdir) that looks something like
this:
# Sample bug tracking systems I use
import mbug mantis:mymantis-odbc
import fb fogbugz:myfogbugz-odbc
import schedulator googlecode:schedulator
# Enable edit-in-place and summary features for all users
import log log
import result result:schedulator
Let me know how it works!
What BTS are you using?
Have fun,
Avery
Simon Law
>
> On 26/07/07, Simon Law <sfl...@gmail.com> wrote:
> >
> > I've looked through the source tree and I can't seem to find any
> > installation instructions. Are there any?
> >
> > Failing that, which source files do I have to look at to figure out the
> > fields for the INI-files?
>
> Ah, documentation. How I so often forget to write it. Look at
> wvdbi.cs for where it actually uses the config file. But here's a
> sample wvodbc.ini:
Actually, you did a good job with the documentation for everything else.
It's just the installation instructions that were missing!
> What BTS are you using?
We're using FogBugz over here.
I've yet to setup Schedulator but I've got some ideas on how to make it
more transparent to use from within FogBugz.
Avery Pennarun
> > wvdbi.cs for where it actually uses the config file. But here's a
> > sample wvodbc.ini:
>
> Actually, you did a good job with the documentation for everything else.
> It's just the installation instructions that were missing!
Oh, that's because I wrote the documentation before I wrote the
program, in order to justify writing the program :)
But don't worry, the documentation that exists is still true - that's
because it doesn't include any actual operational details.
> I've yet to setup Schedulator but I've got some ideas on how to make it
> more transparent to use from within FogBugz.
Do tell! Anything to make updating your schedule more convenient is
an automatic win, as far as I'm concerned.
I suppose we could stand to have some extra Web 2.0 goodness, too. We
have mich's edit-in-place widgets in the new version, which is great,
but there are lots of other things that would be nice to have too.
Have fun,
Avery
Simon Law
> > I've yet to setup Schedulator but I've got some ideas on how to make it
> > more transparent to use from within FogBugz.
>
> Do tell! Anything to make updating your schedule more convenient is
> an automatic win, as far as I'm concerned.
>
> I suppose we could stand to have some extra Web 2.0 goodness, too. We
> have mich's edit-in-place widgets in the new version, which is great,
> but there are lots of other things that would be nice to have too.
I suspect that the correct thing to do is to have a libschedulator.js,
which POSTs to Schedulator on the server and gets notifications when
things have changed.
Then you write a teeny, tiny script that takes notification and renders
the page when a change has occurred. This would be bug-tracking system
dependent. For FogBugz, I'd output the same thing they use for lists of
bugs. That way, I can take advantage of their CSS magic.
Then you just hack your BTS such that Schedulator looks like just
another search query.
Pop a timeline in before your own list of bugs and see how other people
are doing.
UI concepts like dragging around bugs to reschedule and splitting tasks
in place might be interesting. A FogBugz implementation may just want
to add your new split tasks to the original bug, so that your subtasks
become searchable.
Joe Mason
Then you write a teeny, tiny script that takes notification and renders
the page when a change has occurred. This would be bug-tracking system
dependent. For FogBugz, I'd output the same thing they use for lists of
bugs. That way, I can take advantage of their CSS magic.
Then you just hack your BTS such that Schedulator looks like just
another search query.
I think you've got that backwards - Schedulator should have a unified interface and the BTS's bugs should show up there. That way we don't have to repeat the "just hack your BTS" step for every BTS.
Avery Pennarun
> I suspect that the correct thing to do is to have a libschedulator.js,
> which POSTs to Schedulator on the server and gets notifications when
> things have changed.
This sounds relatively straightforward: most of the update POSTing is
already there (it's used for the edit-in-place estimate updater
widget). We'd need something for submitting a new task via POST, but
that wouldn't be too hard. Even in the worst case, we could just make
a new Schedulator plugin that stores POSTed bugs in a separate
database. Schedulator would then pull them in automatically like it
does with any other plugin.
The notifications would be a bit trickier: Schedulator currently
regenerates the entire schedule every time it changes (because the
auto-sorting and due date stuff is complicated enough as it is, and
doing it incrementally would be way too crazy). Coming up with a
notification system would be most easily done by doing a "diff"
between two arbitrary revisions of a schedule, I guess. Hmm...
Well, maybe it's not so hard either. We could just keep a log of all
schedule changes as they happen. Each time we generate a new
schedule, we compare it against the previous one (easy to do, as the
previous one is already stored in a database table) and append any
differences to a log. Then anyone who wants to know the differences
from time t1 to time t2 simply downloads the log entries between those
two times.
Meanwhile, that would open up a tonne of interesting possibilities for
visualizing how your schedule changes over time... something I've
often wanted to do but couldn't think of a good model for storing in
the database.
Wow, this sounds pretty exciting. Now if only we had people with time
to work on it :)
> Then you write a teeny, tiny script that takes notification and renders
> the page when a change has occurred. This would be bug-tracking system
> dependent. For FogBugz, I'd output the same thing they use for lists of
> bugs. That way, I can take advantage of their CSS magic.
>
> Then you just hack your BTS such that Schedulator looks like just
> another search query.
I have to admit that, like Joe, I don't exactly understand what this
would accomplish: the obvious thing to me is to have schedulator pull
in your bugs and display them in a separate UI optimized for managing
estimates and predictions. However, that has the obvious disadvantage
that you need to have two UIs (BTS and schedulator) to manage your
tasks. I wish I could picture what your idea looked like, but I'm
having trouble.
> UI concepts like dragging around bugs to reschedule and splitting tasks
> in place might be interesting. A FogBugz implementation may just want
> to add your new split tasks to the original bug, so that your subtasks
> become searchable.
Yes, all that would be good fun (of course, dragging around and
rescheduling your bugs by hand is somewhat contrary to schedulator
philosophy - I rarely want to sort my bugs by hand, I just want them
in the "right" order).
This project looks like they have the UI part down, if only they had a
powerful schedulator-like backend :)
http://macournoyer.wordpress.com/2007/07/30/me-rain-sleep-girlfriend-donebox/
Have fun,
Avery
Simon Law
Getting Schedulator to be aware of every single system sounds sort of
sketchy. I mean, you don't want to have you BTS integrated into your
schedule. Your want your schedule to be part of your BTS.
Right?
Or am I nuts here?
Of course, a sensible fallback is for Schedulator to have its own
interface that knows how to construct URLs for your BTS. But that's not
half as convenient.
Simon Law
>
> On 03/08/07, Simon Law <sfl...@gmail.com> wrote:
> > Then you write a teeny, tiny script that takes notification and renders
> > the page when a change has occurred. This would be bug-tracking system
> > dependent. For FogBugz, I'd output the same thing they use for lists of
> > bugs. That way, I can take advantage of their CSS magic.
> >
> > Then you just hack your BTS such that Schedulator looks like just
> > another search query.
>
> I have to admit that, like Joe, I don't exactly understand what this
> would accomplish: the obvious thing to me is to have schedulator pull
> in your bugs and display them in a separate UI optimized for managing
> estimates and predictions. However, that has the obvious disadvantage
> that you need to have two UIs (BTS and schedulator) to manage your
> tasks. I wish I could picture what your idea looked like, but I'm
> having trouble.
There are two views of Schedulator. The view developers use most often
is the one that shows them a priority list of their own bugs.
It just so happens that almost all bug tracking systems have one of
those too. Only they suck. So you want Schedulator to replace the "My
Bugs" query with itself.
For managing estimates and predictions, you may want to replace a "Bugs
in Release 47" page with Schedulator. You get a complete table of bugs
and also a little calendar.
The whole point is to make your bug tracking system your scheduling
system, by incrementally adopting Schedulator. It just shows up when
people do their normal work.
> > UI concepts like dragging around bugs to reschedule and splitting tasks
> > in place might be interesting. A FogBugz implementation may just want
> > to add your new split tasks to the original bug, so that your subtasks
> > become searchable.
>
> Yes, all that would be good fun (of course, dragging around and
> rescheduling your bugs by hand is somewhat contrary to schedulator
> philosophy - I rarely want to sort my bugs by hand, I just want them
> in the "right" order).
Right. But having to juggle priorities by hand sucks. Wouldn't it be
nice to be able to juggle release dates, reprioritize or reschedule
bugs, and then commit with a comment?
Of course it would!
> This project looks like they have the UI part down, if only they had a
> powerful schedulator-like backend :)
> http://macournoyer.wordpress.com/2007/07/30/me-rain-sleep-girlfriend-donebox/
Yeah, I heard about Donebox.
I guess you can drive it using their API.
Unfortunately, they only do polling. Which is sad.
Peter McCurdy
> On Fri, Aug 03, 2007 at 11:39:50AM -0400, Joe Mason wrote:
> > On 8/3/07, Simon Law <sfl...@gmail.com> wrote:
> > >
> > > Then you write a teeny, tiny script that takes notification and renders
> > > the page when a change has occurred. This would be bug-tracking system
> > > dependent. For FogBugz, I'd output the same thing they use for lists of
> > > bugs. That way, I can take advantage of their CSS magic.
> > >
> > > Then you just hack your BTS such that Schedulator looks like just
> > > another search query.
> >
> > I think you've got that backwards - Schedulator should have a unified
> > interface and the BTS's bugs should show up there. That way we don't have
> > to repeat the "just hack your BTS" step for every BTS.
>
> Getting Schedulator to be aware of every single system sounds sort of
> sketchy. I mean, you don't want to have you BTS integrated into your
> schedule. Your want your schedule to be part of your BTS.
>
> Right?
>
> Or am I nuts here?
I'm leaning a bit towards nuts. BTSes are big and complicated, and
ripping out a page therein and trying to replace it yourself seems
fraught with peril. Either way, you're looking at O(# of BTSes you
want to work with) work, but adding a list of URLs to use for each BTS
seems like a large amount less work than having to hack the crap out
of each BTS, and then maintain the patches forevermore. Not to
mention the BTSes you can't change (e.g. Google Code, Sourceforge) or
really really don't want to change (e.g. FogBugz's PHP version).
In the case where you're dealing with multiple BTSes, then you'd also
want your BTS as part of your schedule and not vice-versa.
Caterpillar, for instance, being a gigantic slightly schizophrenic
company, had several different BTSes that grew up for different
projects, and it really kind of sucked if you were working on more
than one of them at once. The more I think about it, the more it's
true - your schedule really does include your BTS and not the other
way around; your BTS is just the home of most of the data to be
scheduled.
> Of course, a sensible fallback is for Schedulator to have its own
> interface that knows how to construct URLs for your BTS. But that's not
> half as convenient.
Maybe it's a bit nicer in theory, but I also don't think it'd end up
being all that well integrated. Or at least, making the Schedulator
also look and act like each of N different BTSes just seems to pile on
the workload even higher.
Now if, after we had a nice standalone Schedulator interface, someone
went and got motivated to integrate it to their favourite BTS, then
that'd be cool and all, but I don't think we should get too far ahead
of ourselves. Basically I see the integration step as something for
the maintainers of the BTS to do (aided and abetted by us as much as
possible, of course), after they see how cool and useful it is.
Especially since they're the ones who'd best know how to integrate it
and would be willing to maintain it.
Hmm. We'd probably also have to do something about language differences.
Peter.
Peter McCurdy
[snip]
And no, if your'e wondering, I didn't read the rest of the thread
before replying, because I'm just that smart.