Re: Proposed: evolution: bugzilla issue
- From: Christian Rose <menthos gnome org>
- To: Andrew Sobala <aes gnome org>
- Cc: GNOME Desktop Development List <desktop-devel-list gnome org>
- Subject: Re: Proposed: evolution: bugzilla issue
- Date: Thu, 22 Jul 2004 21:32:20 +0200
ons 2004-07-21 klockan 22.16 skrev Andrew Sobala:
> On Wed, 2004-07-21 at 17:53, Christian Rose wrote:
> > ons 2004-07-21 klockan 05.13 skrev Elijah Newren:
> > > Pardon my ignorance, but I had a hard time finding the requirements for
> > > inclusion in Gnome. I found http://developer.gnome.org/gep/gep-10.html
> > > via a Google search (I couldn't find any direct links to it from various
> > > gnome.org sites that I could think of), but I don't know if this
> > > document has since been followed by later revisions.
> > >
> > > However, if that document still stands then usage of bugzilla.gnome.org
> > > is not an actual requirement. Yes it is encouraged, but considering
> > > that one of the bugmasters, namely Andrew of the Pants, has already
> > > stated that he's cool with the current situation, I see no reason for this
> > > issue to block inclusion of Evolution.
> >
> > It's not only an issue for the bugmasters -- Evolution using a different
> > Bugzilla than everything else in the GNOME D&DP release affects many
> > other contributors aswell.
> >
> > As an example, translators want to keep track of all bugs in the release
> > needing string changes. For the rest of the GNOME D&DP this is simple:
> > Search for bugs matching the fields "Is part of GNOME D&DP", GNOME
> > Version "2.7/2.8", and keyword "string" in GNOME Bugzilla. Do the same
> > in bugzilla.ximian.com? Sorry, out of luck, since there are no such
> > fields and keywords with any similar meaning to use there.
> >
> > So not only does one have to go to two seperate places to get the same
> > information as before, it's even impossible sometimes, since sometimes
> > there is no equivalent to special keywords and fields.
> >
> > This can be a real problem for other contributors aswell who work with
> > issues that span over the whole release, instead of just focusing on one
> > or a few particular applications; like the docs people, accessibility
> > people, usability etc, who want to track release-wide problems.
> >
> > Not to mention the confusion for testers who want to report or search
> > for bugs.
> >
> > So saying that it's ok just because the bugmasters are fine with it is
> > missing the point.
> >
> > But whether this should be a blocker or not is a seperate issue.
>
> However, even if we moved bugzillas today (which we can't do) the
> problem would still be there - it's a case of missing metadata. Getting
> all the metadata like the "string" keyword and correct versioning into
> every bug would require the sort of triage effort we're unlikely to
> manage before GNOME 2.8.
Good point. I guess this is more of an expression of wanting to have
this done before the next GNOME development cycle starts for real. So
it's most likely not a blocker for the inclusion itself.
However I'd really like to see a firm commitment in wanting to do this
according to some sort of time schedule connected to the GNOME release
schedule, not just "we'll do it [eventually]".
> How much of an issue do you think this realistically is for the
> translation teams?
Probably (sadly) not much of an issue at all for most translators.
However, we do at least try to encourage all of them to report problems
with original strings that they find during their normal translation
work, and also if possible track such issues and help getting them fixed
if they can (though translators usually prefer translating and are best
at doing that, so other contributors shouldn't take this as an excuse
for not doing any string reviews, mind you).
For those who do this we should encourage them by making it as easy as
possible to do so, and not add unnecessary steps in the way.
Also, it obviously gets difficult to get an informed opinion about the
overall picture and amount of string issues before a string freeze, for
example. We need that now, and we'll need it again during the next
cycle.
Christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]