Re: The Future of Bug Buddy



Maciej Stachowiak <mjs eazel com> writes:

> > Since some people are still using GNOME from sources rather than
> > packages, bug buddy should work around this nicely.  What I am
> > thinking of doing is having every module supply a bug buddy file which
> > includes things like the list of binaries it provides, a list of
> > things to check for, and where the email should be sent.  Also, a
> > mapping of which packages come from the module would be provided,
> > since bug buddy needs to know that and I haven't thought of anywhere
> > else it could get this.
> 
> If building from source still provides all the needed dependency and
> version info, why involve the packaging system at all? Why not just
> install these bug-buddy files with the packages?

Because the source stuff doesn't actually provide everything, just the
gnome-level stuff.

For example, it probably won't be able to say which libpng or other
non-gnome libs you have.

The thing is that it is much easier, and actually more informative to
query the rpm / dpkg databases if you are using package based gnome
than to just check the version of the module (ie, libgnome32 1.2.8-5
is more informative than just gnome-libs 1.2.8, as the package may
have changed).

So yeah, the duplication here sucks, but is really not all that big
and I think makes sense.

> Also, I assume libredcarpet will be available in source form by the
> time this version of bug buddy is released. Will it also be available
> on a publicly accessible cvs server (for instance cvs.gnome.org) by
> then?

Yeah, I won't be releasing or putting this version of bug buddy into
the CVS until libredcarpet has been released in some form.  I don't
know what this schedule is, but it probably won't delay the releasing
of bug buddy as there is still quite a bit of stuff left to code.

Jacob
-- 
"I've got nothing to say but that's ok." -- John Lennon





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]