multiple instance of bugzilla
Boris Baldassari
boris at apinc.org
Mon Mar 29 12:42:09 UTC 2004
hi;
> We've already frozen for 2.18. Based on current progress at getting
> past the freeze, it'll likely be about a month or a little more before
> it's actually released, but it's coming soon.
it may be too long. hum. i could work on cvs and upgrade when 2.18 will
come out. ok, thanks.
> You'll need to explain a little more of what you have in mind before I
> can give a really good answer, but it's usually more headache than it's
it's not an user problem. we have several types of record (eg. cr and pr),
each with a specific lifecycle. the point is that they all have to
interact: a cr record may generate (dependency) a pr record, and we need
to track them up and down.
since only one lifecycle can be used with an instance of bugzilla (or may
i misunderstood something?), i thought about running several instances of
bugzilla, each with a specific (customized) lifecycle, and allow them to
send updates for dependencies. in such a system, dependency graph would
typically span accross several database and/or bugzilla instances.
> As for inter-Bugzilla dependencies, I'm working on that currently for my
> employer. Initial implementation (I'd give it at least a month yet, and
> probably won't be in upstream Bugzilla until 2.19.1 or so) will allow
> you to have a bug "watch" a bug on another bug system and, via a cron
> job, will post status changes to the upstream bug as comments in the
> local bug. It's basically a one-way dependency - the upstream system
> wouldn't get any notification of changes to your bug.
that would partially fullfill my requirements (i need bidirectionnal
dependencies, just like in one bugzilla). i could eventually (if my
managers allow it, to be confirmed) work on this feature; in this case may
i ask you some questions on your experience of this implementation ?
tia,
--
Boris Baldassari
More information about the developers
mailing list