Bugzilla

Bugzilla

[Jean Delvare]

Hi Axel, Philip & all,

Any news about the new bugzilla installation for lm_sensors support
management? I'd like it to be in place as soon as possible. Ideally we
would switch to it before the old system reaches ticket #2000.

Would it be possible to tell Bugzilla to start at ticket #2000? That way
the new tickets wouldn't overlap with the older ones.

If possible, we could later import older tickets into the new base, but I
admit I have no idea how to do that and it's not my priority at the
moment.

We will also need to prevent the creation of new tickets on the old base
as soon as the switching is done.

Thanks.

PS: Any objection to me deleting doc/developers/readticket and editticket
from lm_sensors CVS? Seems to be made obsolete by the new search page on
the website, and will not work anymore once we have moved to Bugzilla
anyway. (As a side question, does anyone really still use netscape??)

--
Jean Delvare

Bugzilla

[Philip Edelbrock]

Axel Thimm wrote:
> 
> Phil had made some thinking on that, as long as there is a semantic
> mapping, this should be possible. It would become a problem if some
> mandatory fields of the new system (like component) would have to be
> derived from the bug's contents.

I'd be happy to take a stab at the mappings.

> 
> Let me know what to do. I'll be leaving for the CeBIT tomorrow, and
> won't be able to do much until its end (mid next week).
> 

CeBIT?  Sounds like fun!


Phil

Bugzilla

[Axel Thimm]

Hi,

On Mon, Mar 07, 2005 at 05:49:25PM +0100, Jean Delvare wrote:
> Any news about the new bugzilla installation for lm_sensors support
> management? I'd like it to be in place as soon as possible. Ideally we
> would switch to it before the old system reaches ticket #2000.
> 
> Would it be possible to tell Bugzilla to start at ticket #2000? That way
> the new tickets wouldn't overlap with the older ones.

Yes, that's possible.

Is other than that the bugzilla instance OK?

> If possible, we could later import older tickets into the new base, but I
> admit I have no idea how to do that and it's not my priority at the
> moment.

Phil had made some thinking on that, as long as there is a semantic
mapping, this should be possible. It would become a problem if some
mandatory fields of the new system (like component) would have to be
derived from the bug's contents.

Let me know what to do. I'll be leaving for the CeBIT tomorrow, and
won't be able to do much until its end (mid next week).

> We will also need to prevent the creation of new tickets on the old base
> as soon as the switching is done.
> 
> Thanks.
> 
> PS: Any objection to me deleting doc/developers/readticket and editticket
> from lm_sensors CVS? Seems to be made obsolete by the new search page on
> the website, and will not work anymore once we have moved to Bugzilla
> anyway. (As a side question, does anyone really still use netscape??)
> 

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050307/ced182d0/attachment.bin

Bugzilla

[Jean Delvare]

Hi all,

> > Would it be possible to tell Bugzilla to start at ticket #2000? That
> > way the new tickets wouldn't overlap with the older ones.
> 
> Yes, that's possible.
> 
> Is other than that the bugzilla instance OK?

Just taking a closer look to make sure, and in fact I don't think so. In
the current setup, we still have different versions for each "product",
were products are "bus drivers", "chip drivers", "i2c core drivers" and
"user-space". It makes very little sense to me. All these are parts of
the same product, and versions are common to all these parts. Isn't it
possible to do that? I think I remember this was discussed already but I
cannot remember the outcome.

Other than that, I would ask for:

* Less priorities. 7 priorities is too much. I think we could get rid of
blocker (critical will do), trivial and enhancement (minor will do).

* No target milestone. I see little use for these in our project.

* No OS. It is a Linux-only product anyway.

* No priority. Priorities might make sense when people are paid for
support. We are not. We fix things when we feel like it.

* No status whiteboard. What is it for?

* No bug aliases. No use.

Do we need a QA contact? Again, sounds overkill for our project.
Assignee should be sufficient.

What is the URL for? Can't users just include URLs in their comments if
they need to?

I guess you've understood that what I really want is that we keep things
as simple as possible. 10 needless fields are likely to frighten the
users and potential helpers. If we can stick to what is really needed,
I'd expect the support to be easier for everyone.

Thanks,
-- 
Jean Delvare

Bugzilla

[Jean Delvare]

Hi Axel,

> it's lm-sensors day for me ;)

Who would complain :)

> I made it start at #1900, so you can still play a bit with it. When
> you give the go, I'll bump it up to 2000.

We're already at #1987 in the old base. Make it 2200 to be sure.

> bugzilla supports "products" and "components" (per product). The
> "version" filed is attached to the products.
> 
> We could have one product (lm_sensors) and have the current products
> become "components". Currently components were going to be assigned to
> drivers etc.

Sounds better, but what about the drivers? Can there be subcomponents?
The Linux kernel bugzilla has categories and components.

No other comments, rest is fine with me.

-- 
Jean Delvare

Bugzilla

[Axel Thimm]

On Sun, May 15, 2005 at 10:03:47PM +0200, Jean Delvare wrote:
> Hi Axel,
> 
> > > Sounds better, but what about the drivers? Can there be
> > > subcomponents?
> > 
> > No there are only two levels. If you have a singleton product, you are
> > left with one only.
> > 
> > > The Linux kernel bugzilla has categories and components.
> > 
> > That's the same as products and components. They only replaced
> > "products" in the html pages with "categories" in thir customized
> > bugzilla, but if you query for a "category" you will see
> > http://bugzilla.kernel.org/buglist.cgi?...&product=...
> 
> OK I see. Must be the reason why they do not use a list for version but
> rather a free input. Maybe we should just do the same?

They have dropped the classical version field and patched up bugzilla
to have a new free field "kernel_version". kernel.org picked bugzilla
2.16 and modified it according to their needs. They are now quite
stuck to 2.16 series unless a bugzilla magician helps them migrate.

As long as bugzilla does not offer a nice way to customize it w/o
becoming a maintenance nightmare I'd recommend to not have too many
changes.

The reason for kernel.org to have a free version field is different
than for lm_sensors: kernel.org has a miriad of parallel trees with
complex versioning like 2.6.12-rc1-bk2 or -mm3 etc. lm_sensors has a
normal and simple versioning scheme, e.g. one that doesn't change as
frequently and thus doesn't need too much administrative maintenance.

Discrete versions have also the advantage that you can limit new bug
reports to supported versions.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050515/c852d2a5/attachment.bin

Bugzilla

[Axel Thimm]

On Sun, May 15, 2005 at 09:26:47PM +0200, Jean Delvare wrote:
> Hi Axel,
> 
> > it's lm-sensors day for me ;)
> 
> Who would complain :)
> 
> > I made it start at #1900, so you can still play a bit with it. When
> > you give the go, I'll bump it up to 2000.
> 
> We're already at #1987 in the old base. Make it 2200 to be sure.
> 
> > bugzilla supports "products" and "components" (per product). The
> > "version" filed is attached to the products.
> > 
> > We could have one product (lm_sensors) and have the current products
> > become "components". Currently components were going to be assigned to
> > drivers etc.
> 
> Sounds better, but what about the drivers? Can there be subcomponents?

No there are only two levels. If you have a singleton product, you are
left with one only.

> The Linux kernel bugzilla has categories and components.

That's the same as products and components. They only replaced
"products" in the html pages with "categories" in thir customized
bugzilla, but if you query for a "category" you will see
http://bugzilla.kernel.org/buglist.cgi?...&product=...

> No other comments, rest is fine with me.

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050515/1efc6b6e/attachment.bin

Bugzilla

[Jean Delvare]

Hi Axel,

> > Sounds better, but what about the drivers? Can there be
> > subcomponents?
> 
> No there are only two levels. If you have a singleton product, you are
> left with one only.
> 
> > The Linux kernel bugzilla has categories and components.
> 
> That's the same as products and components. They only replaced
> "products" in the html pages with "categories" in thir customized
> bugzilla, but if you query for a "category" you will see
> http://bugzilla.kernel.org/buglist.cgi?...&product=...

OK I see. Must be the reason why they do not use a list for version but
rather a free input. Maybe we should just do the same?

-- 
Jean Delvare

Bugzilla

[Graeme Fowler]

Guys

Is it time, do you think, that we started using something like Bugzilla
or Trac to keep, erm, track of coding changes, issues and/or bugs as
they arise?

I'm happy to host an instance of something if it helps.

Graeme

Re: Bugzilla

[Simon Horman]

On Fri, Feb 13, 2009 at 01:10:46PM +0000, Graeme Fowler wrote:
> Guys
> 
> Is it time, do you think, that we started using something like Bugzilla
> or Trac to keep, erm, track of coding changes, issues and/or bugs as
> they arise?
> 
> I'm happy to host an instance of something if it helps.

In terms of managing patches, patchwork seems to be the new and
exciting tool to use. But in terms of managing bugs, tasks and the like,
I'm happy to work with whatever makes life easier for you, Joe, Malcolm
and the other people feilding lots questions on lvs-users.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: Bugzilla

[Graeme Fowler]

On Sat, 2009-02-14 at 09:15 +1100, Simon Horman wrote:
> In terms of managing patches, patchwork seems to be the new and
> exciting tool to use.

I hadn't come across this - the only "patchwork" I knew about was the
one on Savannah, which died some time ago. As this one appears to be
Jeremy Kerr's, I'll give it a good look-see!

> But in terms of managing bugs, tasks and the like,
> I'm happy to work with whatever makes life easier for you, Joe, Malcolm
> and the other people feilding lots questions on lvs-users.

...and Joe said, privately:
> I think anything here would help

I'll try to get something workable up this weekend, children
permitting...

Graeme

Re: Bugzilla

[Graeme Fowler]

On Sat, 2009-02-14 at 09:49 +0000, I wrote:
> I'll try to get something workable up this weekend, children
> permitting...

http://bugs.zolinone.net/

There's nothing in there (in terms of bugs) but it's a start!

Feel free to create yourself an account, folks.

Graeme

Re: Bugzilla

[Simon Horman]

On Sun, Feb 15, 2009 at 03:08:07PM +0000, Graeme Fowler wrote:
> On Sat, 2009-02-14 at 09:49 +0000, I wrote:
> > I'll try to get something workable up this weekend, children
> > permitting...
> 
> http://bugs.zolinone.net/
> 
> There's nothing in there (in terms of bugs) but it's a start!
> 
> Feel free to create yourself an account, folks.

Thanks, I'm signed-up and ready to go!

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Bugzilla

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

The OE bugzilla is back.

Please do not start adding bugs or comments yet, we are moving it to 
another machine so we can (hopefully) improve availability. The database 
dump is complete, we just need to install bugzilla on the new machine 
and reload the database.

Thanks for your patience!

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Bugzilla

[Leon Woestenberg]

Hello Philip,

On Tue, Apr 29, 2008 at 12:53 PM, Philip Balister <philip@balister.org> wrote:
>  Please do not start adding bugs or comments yet, we are moving it to
> another machine so we can (hopefully) improve availability. The database
> dump is complete, we just need to install bugzilla on the new machine and
> reload the database.
>
Thanks for this effort, and this update!

Regards,
-- 
Leon

Re: Bugzilla

[Rolf Leggewie]

Philip Balister wrote:
> dump is complete, we just need to install bugzilla on the new machine
> and reload the database.

Things should be back to normal now and we are back to having control
over our bug data.  The tracker is now hosted on amethyst.  I left a
good-bye message on the old installation to point people to the new one.
 All URLs should be back to working as before soon (.org DNS needs to
update)

Re: bugzilla

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

On Thu, Jan 16, 2003 at 10:20:14PM +0100, Martin Josefsson wrote:
> I should have looked at the 2.4.19->2.4.20 patch first.
> The problem is this: [...]

I see.

> so the problem is quite obvious. But I can't find any discussion about
> this break of backwardscompability anywhere (either it doesn't exist or
> I'm at leat partially blind :)

No, there was no discussion.  This was a patch by Marc Boucher, which
was pending for quite some time now.  And I have to admit that I didn't
think about the compatibility in this case.  Marc just passed it on to
me and asked me to submit it to the kernel.  No, I'm not blaming
anybody, at least not somebody besides me.

> The only solution is to recompile iptables (or atleast libipt_owner.c)
> against the new headers.

:(  

Well, I guess there's nothing we can do about it now.  Changing it back
to the old format would be even more harmful :(

The real problem with issues like this is: Where do you document them in
a way that it is obvious for people to find out?  Maybe the first step
would be to have this bug (reported, accepted and resolved) in
bugzilla...  So if you could submit it, despite the fact that we have
now resolved it already?

> /Martin
-- 
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
 as I'm the dictator."  --  George W. Bush Dec 18, 2000

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]