Nabble - Bugzilla - Dev

Re: Fwd: REST APIs, and Tags

2009-11-27T05:07:24Z

On 11/27/2009 02:32 AM, Gervase Markham wrote:
> But one of the problems with keywords is the frozen-in-time-list thing
> that David Ascher proposed. Under this new plan, would keywords get
> unrestricted?

I'm not sure that they would. Remember, right now you could make
"editbugs" a member of "editkeywords" if you wanted. Why don't you? (The
answer to that question has nearly the same answer as "why not let
everybody make global tags?")

This is open for debate, but it's something that I'd want more data
from a broad set of organizations on before we really go and make a (for
us) radical decision about it. I'd also be interested to know if other
trackers have implemented a tag system, and what the developers of those
systems think about whether or not their implementation was successful.

> Because if we don't make that split, bugs will start growing enormous
> lists of tags, and people will be disincentivised from adding new ones
> to help them track stuff the way they want to.

Mmm, I'm not entirely sure that's the case. Everybody can edit the
status whiteboard now, and bugs don't have tremendous numbers of tags in
the Whiteboard. Of course, right now only a small number of people
actually put tags in the status whiteboard, so it may not be the same
once we have a field actually called "tags".

> In particular, if I search for "tag=wibble", then it should show me all
> bugs with either the personal or the global tag "wibble". Search should
> not care about the distinction.

It won't, but that doesn't require all personal tags to be publicly
visible.

> And yes, it should be possible for someone else to do that search too.
> tag=wibble&taguser=gerv@..., or some better UI. So that searches
> can be shared by just sending or posting a URL, without needing any
> complicated internal Bugzilla system.

That's accomplished most easily, with the present system, by allowing
Bugzilla to have public shared searches.

> Why do the idea of "tags" and the idea of "saved search" have to be
> connected? I've never understood that. How are the currently connected,
> and what was the rationale?

They don't have to be connected. I think that it was just convenient to
piggyback tags on to Saved Searches, because they essentially do the
same thing, in a way--they list bugs. It would be more database-like to
store a many-to-many mapping of a bug_id and tag_id column for each tag
instead, but shared searches give us footer listing, sharing with a
limited group, etc. for free. I don't think the backend matters as much
as the UI, for this.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Fwd: REST APIs, and Tags

2009-11-27T02:32:53Z

On 26/11/09 14:42, Max Kanat-Alexander wrote:
> Actually, we'd be mostly continuing an old discussion, one that at
> least *I* think has actually been resolved, we just don't have anybody
> to implement the resolution.

OK :-)

>
>> For example, can we merge keywords and what we now call
>> tags into one tag implementation (incorporating both public and private
>> tags) which has these desirable properties?
>
> That's basically the resolution. :-) Except they won't be one
> implementation, they will just look similar or identical in the UI. For
> example, we call Keywords "global tags" and we call our current tags
> "personal tags" and we just style them differently in a list of tags.

But one of the problems with keywords is the frozen-in-time-list thing
that David Ascher proposed. Under this new plan, would keywords get
unrestricted?

I agree it's good to have two classes of tags, because we need "tags
that show up when other people view the bug" and "tags which don't".
Because if we don't make that split, bugs will start growing enormous
lists of tags, and people will be disincentivised from adding new ones
to help them track stuff the way they want to.

So I'm all for "global tags" and "personal tags". But other than that
difference, they should work identically. Because any difference is
going to cause confusion.

In particular, if I search for "tag=wibble", then it should show me all
bugs with either the personal or the global tag "wibble". Search should
not care about the distinction.

And yes, it should be possible for someone else to do that search too.
tag=wibble&taguser=gerv@..., or some better UI. So that searches
can be shared by just sending or posting a URL, without needing any
complicated internal Bugzilla system.

> https://bugzilla.mozilla.org/show_bug.cgi?id=372023

Great :-)

> An additional component to this would be adding the ability to share
> searches publicly, so that one could share one's personal tags publicly.
> There might already be a bug filed for that, but I'm not sure.

Why do the idea of "tags" and the idea of "saved search" have to be
connected? I've never understood that. How are the currently connected,
and what was the rationale?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Fwd: REST APIs, and Tags

2009-11-26T06:42:30Z

On 11/26/2009 06:19 AM, Gervase Markham wrote:
> It would be great to start a discussion on our future plans for this
> sort of thing.

Actually, we'd be mostly continuing an old discussion, one that at
least *I* think has actually been resolved, we just don't have anybody
to implement the resolution.

> For example, can we merge keywords and what we now call
> tags into one tag implementation (incorporating both public and private
> tags) which has these desirable properties?

That's basically the resolution. :-) Except they won't be one
implementation, they will just look similar or identical in the UI. For
example, we call Keywords "global tags" and we call our current tags
"personal tags" and we just style them differently in a list of tags.

The reason for the separation of personal and global tags (which
doesn't exist in most web apps) is that the structure of global tags is
necessary for something like a bug-tracker, which has strict data
conformity and management requirements (whereas something like Flickr is
not used in that sort of circumstance).

Some (or all) of this redesign is this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=372023

You don't have to pay attention to the blockers if you don't want to.
The keynote of that bug is "make tagging good".

An additional component to this would be adding the ability to share
searches publicly, so that one could share one's personal tags publicly.
There might already be a bug filed for that, but I'm not sure.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Fwd: REST APIs, and Tags

2009-11-26T06:19:59Z

Here are David Ascher's thoughts on tagging and Bugzilla usability,
which I thought might be good food for thought. (He gave them to me in
the context of the REST API.)

I definitely think that over the ten+ years of Bugzilla's life, we've
had about five goes at the "tag" thing (status whiteboard, keywords,
flags, saved searches, and now the tag system in the footer) and each
time we've missed the simplicity and ease of what seems to have evolved
as the standard way to set and search for tags (a freeform,
comma-separated list anyone can search on a la Flickr and del.icio.us).
keywords are too bondage-and-discipline and centrally controlled, the
whiteboard is too freeform and is a (slower) text search, and the footer
tag system seems really complicated in its UI and hard to share with others.

It would be great to start a discussion on our future plans for this
sort of thing. For example, can we merge keywords and what we now call
tags into one tag implementation (incorporating both public and private
tags) which has these desirable properties?

Gerv

-------- Original Message --------
Subject: REST APIs, and Tags
Date: Thu, 02 Jul 2009 15:17:56 -0700
From: David Ascher <dascher@...>
To: Gervase Markham <gerv@...>
CC: Mark Surman <mark@...>, Dan Mosedale
<dmose@...>, Aza Raskin <araskin@...>

In both of these areas, I think that Flickr has set a role model that's
worthy of emulation:

http://www.flickr.com/services/api/

(with some humor even:
http://www.flickr.com/services/api/misc.encoding.html)

see e.g. http://www.flickr.com/services/api/flickr.favorites.add.html

and the explorer tool:
http://www.flickr.com/services/api/explore/?method=flickr.favorites.add

The key bits here is that by looking at these pages, people can
understand the API model for flickr w/o having to dig any deeper. The
RESTful thing makes it easier to approach than an RPC-model, easier to
see how it could scale, etc.

---

On tags, the usual challenge is how to give people structure (e.g.
official milestones, operating systems) that is needed for aggregation
queries ('show me all mac blockers'), while decentralizing the locus of
that structure, so that different groups can come up with different
structures. It's also critical to distinguish the
structure-by-convention from the structure-imposed-by-the-database. In
particular, one could argue that bugzilla should just have one "tags"
field for a bug, but let different bits of the UI rely on different
"schemas" for tags.

You asked for problems w/ the current scheme:

1) there's no rationale for whether something goes in the status
whiteboard or a keyword, except that keywords are tightly controlled and
some bizarre, frozen-in-time list which which mostly doesn't change
because it applies to _all products_, and status whiteboard is
freeform-but-laden-with-conventions.

2) user tags are too hard to share, hence pointless IMO -- tags worked
in flickr and delicious because they became fast and easy ways to share
sets of URIs. In Bugzilla, it's the horrible thing called a saved
search, which is way, way too hard to work with, and requires that
people be logged in for no good reasons. If I could just post
http://bugs.mozilla.org/bugs/davidascher/tags/tb3+student_project to the
world, i'd be much happier.

I can imagine a version of bugzilla with a tags field which on disk
looked like one big json blob which encoded components, products,
milestones, keywords, status whiteboard. (per-user tags probably don't
belong on the same table). A lot of the current _structure_ of each bug
is not particularly useful per se, and could be implemented with
rss/atom feeds on tag-based searches.

Let me give an example -- in a previous version of the ActiveState
bugzilla DB, we "suffered" from the problem that each product team had a
different culture, a different way of dealing w/ QA, regressions, bug
triaging, etc. The Komodo team wanted to use "tags" like "on-radar",
"off-radar", but the Perl team didn't. Bugzilla didn't allow for the
right kind of per-product separation, so we put those distinctions
strictly in the UI, and from the DB's point of view we just used the
status whiteboard field.

-david
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

The new Bugzilla::Extension system

2009-11-25T02:53:56Z

I spent the last several days re-writing Bugzilla's extensions system.
The old system suffered from a few problems, many of which I encountered
personally while writing several large extensions:

* Template hooks went in a strange location that was partially
inexplicable from looking at the code. (Did they go in template/en/hook,
or template/en/default/hook, or template/en/extension, or what?)

* Code was in individual .pl files that had to be compiled every time
they were run, and couldn't really have subroutines in them (because
Bugzilla would complain you were redefining the subroutine if the hook
was called more than once in the same request).

There were other things that were strange about them, but those were
the two big points.

The new system is pretty neat. It's mostly documented in the POD of the
new Bugzilla::Extension module:

<http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/Extension.html>

Here are some of the highlights:

* Extensions are a directory which contain templates, libraries, and
two special files: Config.pm and Extension.pm. Config.pm contains
information about the extension's requirements. Extension.pm contains
all the code hooks the extension implements, as subroutines.

* Extensions can also be all in one file, so you could just have
extensions/Foo.pm for an extension named "Foo" that does nothing but add
code hooks.

* The Extension module is named like Bugzilla::Extension::Foo, where
"Foo" is the "name" of the extension.

* An extension loads its libraries like Bugzilla::Extension::Foo::Bar.
The extensions system magically maps that to extensions/Foo/lib/Bar.pm,
with no extra effort required by the extension developer. Once the
Bugzilla::Extension::Foo package is loaded, *any* part of Bugzilla can
load Bugzilla::Extension::Foo::Bar directly, if it wants to, just like
"use Bugzilla::Extension::Foo::Bar;". This means, also, that these
libraries could be installed globally in Perl (as
Bugzilla/Extension/Foo/Bar.pm in /usr/lib/perl5/) and still be loaded
properly.

Note that the old magic @INC behavior of extensions is gone--they
*must* name their packages like Bugzilla::Extension::Foo::Bar. (This is
much better than the strange mix of Foo::Bar and
extensions::foo::lib::Bar that we had before.)

* Template hooks now live in template/en/default/hook, both in an
extensions directory (extensions/Foo/template/en/default/hook), and in
the base Bugzilla template directory. Templates in extensions (including
hooks) are now precompiled by checksetup.pl. Additionally, template
hooks are cached by Bugzilla the first time they're run, so running them
over and over should just just as fast as (or faster than) processing a
normal template.

* For new extension authors, there is a script called
extensions/create.pl. You just give it a name of a new extension, as a
single argument, and it creates a whole default layout for an extension
in the extensions/<Name>/ directory.

* There is support for loading extensions that are not installed in the
extensions/ directory at all, but are installed globally in Perl
instead. This means that extensions could be packaged and distributed
via CPAN, and various code has already been written to make this
possible in Bugzilla itself (though no code has yet been written to make
it easy to make an extension into a CPAN package--this is something that
could still be done).

* Under mod_perl, extension code will be compiled exactly once, when
the web server starts up. This should make extensions lightning-fast
under mod_perl. (It does mean that to add new extensions, a server
restart is required, though.)

* To help people who have already written extensions, there is a file,
contrib/extension-convert.pl, which will do a lot of the work of
converting your extension from the pre-3.6 format to the 3.6 format.

I think extensions should generally be a lot better now, and should
only be getting even better in the future. :-) Please let me know if you
encounter any problems with the new system, or have any suggestions
about it! I'd love to hear from extension authors about their thoughts
on it, particularly if it's after working with it.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Soft Serve

2009-11-24T23:55:30Z

We're soft frozen for Bugzilla 3.6. That means that if you have a patch
going through the review process right now, you have exactly two weeks
to get it in to Bugzilla if you want it to be part of Bugzilla 3.6.

Enhancements without patches on them currently will not be accepted for
Bugzilla 3.6, as of now.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-24T17:44:24Z

On 11/24/2009 12:52 PM, David Miller wrote:
> Include the TZ offset in the dropdown select in parentheses after the TZ
> name. Sort the select box by the TZ offset. Autoselect the first one
> that matches. Let the user change it to one of the ones right after if
> it was the wrong one.

Yeah, that would work. We wouldn't even need JS for that, if the user's
browser sends any header containing a time with a timestamp.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-24T12:52:16Z

Max Kanat-Alexander wrote on 11/24/09 7:04 AM:
> On 11/24/2009 03:41 AM, David Balažic wrote:
>> About storing the timezone in users preferences for other purposes, I saw on
>> some web forums, that the user registration page uses JS to autodetect
>> the timezone (but the user can still change it, it is a regular drop down list,
>> it is just initialized by JS).
>
> Yeah, that's kind of what I was saying--I don't know how to reliably
> translate the JS timezone into an Olson timezone.

Include the TZ offset in the dropdown select in parentheses after the TZ
name. Sort the select box by the TZ offset. Autoselect the first one
that matches. Let the user change it to one of the ones right after if
it was the wrong one.

--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-24T04:04:09Z

On 11/24/2009 03:41 AM, David Balažic wrote:
> About storing the timezone in users preferences for other purposes, I saw on
> some web forums, that the user registration page uses JS to autodetect
> the timezone (but the user can still change it, it is a regular drop down list,
> it is just initialized by JS).

Yeah, that's kind of what I was saying--I don't know how to reliably
translate the JS timezone into an Olson timezone.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-24T03:41:19Z

2009/11/24 Max Kanat-Alexander <mkanat@...>:
> Yeah, but we still need to know the Olson timezone on the server-side
> for the various things that can't use JS, like bugmail. We can't just
> store the last offset the user had when he logged in, because that
> doesn't account for DST changes or the fact that the user might be
> traveling.

Yes, the proposal works for the web pages displayed in the users web browser
and not for other purposes.

About storing the timezone in users preferences for other purposes, I saw on
some web forums, that the user registration page uses JS to autodetect
the timezone (but the user can still change it, it is a regular drop down list,
it is just initialized by JS).

Regards,
David
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-24T01:50:13Z

On 11/23/2009 11:19 PM, David Miller wrote:

> Max Kanat-Alexander wrote on 11/23/09 7:37 PM:
>> Yeah, we'd have to store it on the server still, which would probably
>> confuse people. I don't think we can get Olson timezone names (like
>> America/Los_Angeles) from JS.
>
> But that's the beauty of it, you wouldn't need to. All the JS cares is
> the local timezone of the browser that's accessing it. The only reason
> the server needs to know is the fallback timezone to use for the
> noscript block. The JS block he gave asks the browser to use its own
> timezone in the conversion.

Yeah, but we still need to know the Olson timezone on the server-side
for the various things that can't use JS, like bugmail. We can't just
store the last offset the user had when he logged in, because that
doesn't account for DST changes or the fact that the user might be
traveling.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-23T23:19:42Z

Max Kanat-Alexander wrote on 11/23/09 7:37 PM:
> Yeah, we'd have to store it on the server still, which would probably
> confuse people. I don't think we can get Olson timezone names (like
> America/Los_Angeles) from JS.

But that's the beauty of it, you wouldn't need to. All the JS cares is
the local timezone of the browser that's accessing it. The only reason
the server needs to know is the fallback timezone to use for the
noscript block. The JS block he gave asks the browser to use its own
timezone in the conversion.

--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-23T16:37:06Z

On 11/23/2009 06:14 AM, Frédéric Buclin wrote:
> Le 23. 11. 09 13:26, David Balažic a écrit :
>> That's it. No user action required.
>>
>> This solution also automatically handles daylight saving time changes.
>
> This won't work. Your suggestion only works when viewing bugs from a web
> browser *and* having JS turned on.

Well, it does work for that case, though. And it works for logged-out
users, which is nice.

> And I'm
> pretty sure you still have to store the timezone somewhere to do the
> conversion correctly.

Yeah, we'd have to store it on the server still, which would probably
confuse people. I don't think we can get Olson timezone names (like
America/Los_Angeles) from JS.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Configuration object

2009-11-23T16:35:54Z

On 11/23/2009 08:34 AM, Gervase Markham wrote:
> I'm just quoting something I thought I heard you say a while back - that
> group names of groups a person is not a member of are considered
> confidential. Isn't that right?

That's right.

> If that is true, it seems to make sense that sometimes a user will have
> an ID and not a name, and so we should make IDs primary.

That makes sense.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Configuration object

2009-11-23T08:34:38Z

On 16/11/09 20:31, Max Kanat-Alexander wrote:
> On 11/16/2009 01:55 AM, Gervase Markham wrote:
>> Surely they are more likely to have the ID? After all, isn't it true
>> that group names can in some cases be confidential, and that's why the
>> IDs are exposed and used on the process_bug edit interface?
>
> To be honest, I've never interacted with groups via the API, so I think
> you would know better than me.

I'm just quoting something I thought I heard you say a while back - that
group names of groups a person is not a member of are considered
confidential. Isn't that right?

If that is true, it seems to make sense that sometimes a user will have
an ID and not a name, and so we should make IDs primary.

> I'd like to make things work based on how Bugzilla should ideally be
> working (that is, as it will be working in the future) because that way
> we don't have to change things or aren't left around with legacy cruft
> when Bugzilla does "catch up" in some areas. This is, of course, as long
> as this strategy doesn't interfere with making certain features work now.

Absolutely :-)

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Simplified users Timezone handling

2009-11-23T06:14:24Z

Le 23. 11. 09 13:26, David Balažic a écrit :
> That's it. No user action required.
>
> This solution also automatically handles daylight saving time changes.

This won't work. Your suggestion only works when viewing bugs from a web
browser *and* having JS turned on. This won't work for bugmails. And I'm
pretty sure you still have to store the timezone somewhere to do the
conversion correctly.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Simplified users Timezone handling

2009-11-23T04:26:38Z

(originally posted on nntp mozilla.support.bugzilla :
http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread/c36721d5ec8f8820/cfcdad7d5af3405d
posting here on suggestion from Max Kanat-Alexander <mkanat@...>)

Hi!

In version 3.4.3 for the displaying times and dates in users timezone,
currently this is required:
- a bunch of code on the server (bugzilla)
- user must login (on each visit, unless "cookied")
- user must set timezone in preferences

I suggest a much simpler solution:
- a few lines of code in the server

That's it. No user action required.

This solution also automatically handles daylight saving time changes.

It puzzles me why (web) server software writers go through all this
trouble when a few lines of code does it all ;-)

The code (as sent to users web browser):

Time of action (in your local tz !): <script type="text/javascript">

</script><noscript>2002-11-27 08:09 PDT**</noscript>

* - the time as miliseconds since epoch inserted by server
** - regular time inserted by server, as it is done now (or before,
when it was always in servers TZ)

It needs Java/ECMAScript, obviously, so the NOSCRIPT fallback.
JS is already used so while many (me included) think JS is evil, this
is no change in that regard.
If user happens to have no JS (or have disabled it), a fallback to old
behavior is done, so no harm.

Regards,
David
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Freeze Reminder: November 24

2009-11-20T20:16:16Z

We have our soft freeze for Bugzilla 3.6 on November 24. That means
that, after that point, no enhancements will be accepted that do not
already have a patch under review. Two weeks after that (December 8)
will be the "hard freeze", when no new enhancements will be accepted at
all (shortly after that we will branch for 3.6).

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Raindrop, mailing lists and Majordomo

2009-11-20T02:27:34Z

http://www.melez.com/mykzilla/2009/11/skinny-on-raindrops-mailing-list.html
says that:

"Majordomo2 (used by the Bugzilla and OpenBSD projects, among others) is
not supported, because it doesn't send List-* headers (alhough
supposedly it can be configured to do so)."

Is ours configured to do so? If not, can it be?

Also, the bugzilla-dev list is gatewayed to mozilla.dev.apps.bugzilla,
which is a Mailman list, and therefore supported, right?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: The timezone problem

2009-11-17T06:45:10Z

On 13/10/09 17:14, Gervase Markham wrote:
> So I'm looking at trying to solve (as best I can) the timezone problem
> for my API.

OK, I think I've cracked this. Every timezone on the API is now output
in the following form:
YYYY-MM-DDTHH:MM:SSZ
(literal T and Z), which is ISO 8601 extended format. And assuming you
tell the API what the timezone of the target Bugzilla is, all the
timestamps are correct.

(Yes, I could have determined this programmatically at every startup,
but it seemed easier to just have it as a config.)

I _think_ this will work even if the user changes their TZ preferences,
because the stamps output still have TZ info attached, which means I can
convert back to UTC.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Configuration object

2009-11-16T12:31:22Z

On 11/16/2009 01:55 AM, Gervase Markham wrote:
> Surely they are more likely to have the ID? After all, isn't it true
> that group names can in some cases be confidential, and that's why the
> IDs are exposed and used on the process_bug edit interface?

To be honest, I've never interacted with groups via the API, so I think
you would know better than me.

I'd like to make things work based on how Bugzilla should ideally be
working (that is, as it will be working in the future) because that way
we don't have to change things or aren't left around with legacy cruft
when Bugzilla does "catch up" in some areas. This is, of course, as long
as this strategy doesn't interfere with making certain features work now.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Mass influx of old emial

2009-11-16T08:25:18Z

Gregary Hendricks wrote:
> Oh good, I was wondering how it was that we could time warp back to the next
> Bugzilla meeting scheduled for two weeks ago.
> ;-)
>

And here I thought Mozilla Foundation was working on an Open Source Time Machine... Darn.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Bugzilla on FOSDEM CeBIt and on Perl events

2009-11-16T01:57:18Z

On 15/11/09 13:36, Gabor Szabo wrote:
> So I would like to get these things moving in both directions.
>
> FOSDEM http://www.fosdem.org/2010/ is 6-7 February 2010 in Brussels, Belgium.

I am at FOSDEM every year, and plan to attend next year.

> So I would like to know if anyone from the Bugzilla community is interested in
> participating either of these events?

I am happy to give a talk on Bugzilla at FOSDEM, but given my Mozilla
responsibilities, I would not be able to help man a stand.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Bugzilla on FOSDEM CeBIt and on Perl events

2009-11-16T01:56:22Z

On 15/11/09 16:10, Frédéric Buclin wrote:
> Looks like Bugzilla is already something they have in mind, from what I
> can read at http://www.fosdem.org/2010/distrominiconf
>
> In the "Community Infrastructure" section, I can read "Bugzilla extensions".
>
> Does someone know which languages are used in these talks? English only?

Pretty much everything that happens at FOSDEM is in English, yes.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>

Re: Configuration object

2009-11-16T01:55:24Z

On 13/11/09 20:39, Max Kanat-Alexander wrote:
> That would be entirely reasonable. There are no major sites that I know
> of that haven't converted, unless they're running a very old Bugzilla
> version.

OK, I'll document that restriction.

>> I'm returning both, as an object.
>> https://wiki.mozilla.org/Bugzilla:REST_API:Objects#Group
>
> Okay. If you return both everywhere, then I'd say that the name is a
> better key, as that's what clients will know and have, yes?

Surely they are more likely to have the ID? After all, isn't it true
that group names can in some cases be confidential, and that's why the
IDs are exposed and used on the process_bug edit interface?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Getting more data from inside a template

2009-11-16T01:53:46Z

On 12/11/09 06:29, Bradley Baetz wrote:
> Is that exposed in Bugzilla.pm? If so then Bugzilla.foo() will work.

I'll look; thanks.

> PS I just got a bunch of messages from late october that I hadn't seen
> before - was something mailman-related stuck?

Apparently so, according to justdave.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Pre 3.4.3 upgrade question

2009-11-15T11:59:14Z

On 11/15/2009 09:09 AM, JoeS wrote:
> I use a bookmarklet to copy bug data into bbs format for a forum.
> Just wondering if it will have to be modified for 3.4.3

Probably the best place to ask this would be the support-bugzilla
mailing list, described here:

http://www.bugzilla.org/support/

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Pre 3.4.3 upgrade question

2009-11-15T09:09:35Z

I use a bookmarklet to copy bug data into bbs format for a forum.
Just wondering if it will have to be modified for 3.4.3
Here's the code:
javascript:(function()%20{%20var%20title%20=%20document.title;%20function%20htmlEscape(s){return%20s;};%20var%20OS=document.getElementById(%22op_sys%22).value.substring(0,3)%20;var%20PR=document.getElementById(%22product%22).value%20;var%20comp=document.getElementById(%22component%22).value;if(comp==%22XSLT%22||comp==%22MathML%22||%20comp==%22XForms%22||comp==%22SVG%22||comp==%22Layout:%20Canvas%22||comp==%22Editor%22||comp==%22Build%20Config%22)%20PR=PR+%22:%22+comp;textToCopy=%22[*][url=%22%20+%20location.href%20+%20%22]#%20%22%20+%20/\d+/(title)[0]%20+%20%22[/url]%20[%22%20+%20PR%20+%22]%20-%20%22+htmlEscape(/%E2%80%93.*/(title)[0].slice(2))%20+%22%20[%22+OS%20+%22]%22+%20%22%22;document.write(%22<form%20name=f>%20<textarea%20name=ta%20cols=120%20rows=5></textarea></form>%22);%20document.close();%20document.f.ta.value%20=%20textToCopy;%20document.f.ta.select();%20})()

If someone could look through that could see if there are problems for the new version, that would be much appreciated.

--
JoeS
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Bugzilla on FOSDEM CeBIt and on Perl events

2009-11-15T08:10:55Z

Le 15. 11. 09 14:36, Gabor Szabo a écrit :
> In addition there are going to be developer rooms
> with talks
> probably grouped by fields but it is still not clear to me. I'd like
> to make sure
> many such rooms will have at least one Perl related talk.

Looks like Bugzilla is already something they have in mind, from what I
can read at http://www.fosdem.org/2010/distrominiconf

In the "Community Infrastructure" section, I can read "Bugzilla extensions".

Does someone know which languages are used in these talks? English only?

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Bugzilla on FOSDEM CeBIt and on Perl events

2009-11-15T05:36:10Z

On the wiki meeting
https://wiki.mozilla.org/Bugzilla:Meetings:2009-10-27 I mentioned
that I am trying to get some Perl action on various events. In
addition I think I never seen
a Bugzilla talk on any of the YAPC::EU events I participated.

So I would like to get these things moving in both directions.

FOSDEM http://www.fosdem.org/2010/ is 6-7 February 2010 in Brussels, Belgium.
CeBIT is http://www.cebit.de/opensource_e 206 March 2010 in Hannover, Germany

On FOSDEM I am going to apply for a stand for Perl where I would like to have
representatives of several Perl related projects. We will have to man the stand
during the two days. In addition there are going to be developer rooms
with talks
probably grouped by fields but it is still not clear to me. I'd like
to make sure
many such rooms will have at least one Perl related talk.

I might propose a room for "development tools" where we can showcase things such
as bug tracking system, editors (I am running a project called Padre)
and other things.

On CeBit I think we might get a booth that we will have to man during
the whole show.
I don't think there are talks involved there.

So I would like to know if anyone from the Bugzilla community is interested in
participating either of these events?

regards
Gabor
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Configuration object

2009-11-13T12:39:23Z

On 11/13/2009 02:03 AM, Gervase Markham wrote:
> 129k -> 18k with gzip. So no. I guess that could be a solution. Does
> Apache magically gzip stuff as a transport-encoding or do you have to
> tell it to in some way?

I believe you have to tell it to, although I'm not certain.

> Rather than exposing the utf8 parameter, I would prefer that all
> interactions with the API were in utf8, and if Bugzilla was not using
> utf8, the API proxy did conversions.

Um, you can't do that, because unless utf8 is on, you have no idea what
the encoding you're receiving is.

> In fact, I would rather just make utf8 being on a pre-requisite for
> using the proxy with a particular Bugzilla ;-) How unreasonable would
> that be? Are there still significant sites which haven't converted?

That would be entirely reasonable. There are no major sites that I know
of that haven't converted, unless they're running a very old Bugzilla
version.

>>> 4) Should we index the "group" hash by "id" or "name"? Both are unique.
>>
>> Depends on how the rest of the API uses them. If you return ids
>> elsewhere, then ids should be the key, and should generally be used
>> everywhere. If you return names, then names should be the key.
>
> I'm returning both, as an object.
> https://wiki.mozilla.org/Bugzilla:REST_API:Objects#Group

Okay. If you return both everywhere, then I'd say that the name is a
better key, as that's what clients will know and have, yes?

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Configuration object

2009-11-13T02:03:19Z

On 12/11/09 18:50, Max Kanat-Alexander wrote:
> Hmm. Yeah, that's quite a bit. Is it still very large with gzip or deflate?

129k -> 18k with gzip. So no. I guess that could be a solution. Does
Apache magically gzip stuff as a transport-encoding or do you have to
tell it to in some way?

> Some people might want to only request specific products, which
> config.cgi already supports. That helps a bit.

I could certainly add that.

>> 3) Can you think of any more params we should obviously expose?
>
> utf8, and the data returned by Bugzilla.time from the WebService. Maybe
> others, would have to go through the list and think about it.

Rather than exposing the utf8 parameter, I would prefer that all
interactions with the API were in utf8, and if Bugzilla was not using
utf8, the API proxy did conversions.

In fact, I would rather just make utf8 being on a pre-requisite for
using the proxy with a particular Bugzilla ;-) How unreasonable would
that be? Are there still significant sites which haven't converted?

>> 4) Should we index the "group" hash by "id" or "name"? Both are unique.
>
> Depends on how the rest of the API uses them. If you return ids
> elsewhere, then ids should be the key, and should generally be used
> everywhere. If you return names, then names should be the key.

I'm returning both, as an object.
https://wiki.mozilla.org/Bugzilla:REST_API:Objects#Group

>> 5) Are there any plans to make request_group and grant_group multi-valued?
>
> No, I don't think so, because there's group inheritance.

OK. I'll stop worrying about that, then.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Configuration object

2009-11-12T10:50:19Z

On 11/12/2009 03:48 AM, Gervase Markham wrote:
> 1) This data in JSON form is 157k for bugzilla.mozilla.org[0], and is
> likely to be more for Bugzillas with more products, components or flags.
> In particular, as flags are valid per-component, 2/3 of that 157k is
> saying which flags are valid for every component.

Hmm. Yeah, that's quite a bit. Is it still very large with gzip or deflate?

> It could be that people don't always want all the data. So I'd like to
> add an option or two that they can add as parameters to not include some
> stuff. The question is, what? I've added "flags=0" to remove all flags
> stuff. You could still use the resulting data for anything except adding
> flags to bugs or attachments. Are there other slices and dices which
> might still be useful but of lower volume?

Some people might want to only request specific products, which
config.cgi already supports. That helps a bit.

> 2) Does my reasoning for not wrapping Classifications around Products
> make sense?

Yeah, seems reasonable.

> 3) Can you think of any more params we should obviously expose?

utf8, and the data returned by Bugzilla.time from the WebService. Maybe
others, would have to go through the list and think about it.

> 4) Should we index the "group" hash by "id" or "name"? Both are unique.

Depends on how the rest of the API uses them. If you return ids
elsewhere, then ids should be the key, and should generally be used
everywhere. If you return names, then names should be the key.

> 5) Are there any plans to make request_group and grant_group multi-valued?

No, I don't think so, because there's group inheritance.

> [0] https://bugzilla-stage-tip.mozilla.org/config.cgi?ctype=json
> (note: this is down as I write but should be back soon)
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla@...
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=mkanat@...>

--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: The timezone problem

2009-11-12T10:44:45Z

On 11/12/2009 04:42 AM, Bradley Baetz wrote:
> Yeah, the DST thing is a common issue. I'd like for us to say that all
> times are UTC, always, and the front ends do the conversion, but I'm
> not 100% sure that stuff won't break.

I think the UTC thing should still be done. It's something that we'd
have to think about quite a bit and start on early in a development
cycle--maybe for 3.8.

> I'm pretty sure that we require
> the DB server and the web server to be in the same timezone because of
> these issues (do we still?), so if you're doing any client-side
> conversion there may be issues.

Yeah, we do still require that.

> Long term it'd be best to do UTC and fix what breaks, rather than
> encode a local timestamp into a brand new interface, though.

Agreed.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

Re: Mass influx of old emial

2009-11-12T09:07:18Z

>>> On 11/12/2009 at 12:35 AM, in message <4AFBBAB1.2070600@...>, David
Miller <justdave@...> wrote:
> Colin Ogilvie wrote on 11/12/09 2:29 AM:
> > Not strictly on topic... but am I the only one to have suddenly received
> > a load of CVS commit messages, review requests and a few messages from
> > this list that have been stuck on Mozilla servers for more than a week
> > or so?
>
> Nope, the inbound queue in majordomo was jammed because a logfile filled
> up. I rotated the logs and gave it a kick a couple hours ago.

Oh good, I was wondering how it was that we could time warp back to the next Bugzilla meeting scheduled for two weeks ago. ;-)

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>