Dmitry is there an update on this ?
On Wed, 2007-06-27 at 01:39 -0700, Kristis Makris wrote:
> Hi Dmitri, thanks for diving into this.
>
> On Tue, 2007-06-26 at 22:58 +1000, Dmitri Colebatch wrote:
> > > Yep, I tried that, and then I tried deleting all the versions in
> > > bugzilla. My guess is that its a genuine failure - I'll try to make
> > > time to take a look.
>
> I suspect there's something we're missing. Perhaps the way the version
> is added.
>
> > I think the difference here is that the previous code removed the
> > version via SQL, meaning there were no checks to see if any bugs were
> > raised against that version. We're now removing it via the
> > remove_from_db method which looks like this:
> >
> > sub remove_from_db {
> > my $self = shift;
> > my $dbh = Bugzilla->dbh;
> >
> > # The version cannot be removed if there are bugs
> > # associated with it.
> > if ($self->bug_count) {
> > ThrowUserError("version_has_bugs", { nb => $self->bug_count });
> > }
> >
> > $dbh->do(q{DELETE FROM versions WHERE product_id = ? AND value = ?},
> > undef, ($self->product_id, $self->name));
> > }
> >
> > So obviously this isn't going to work if bugs are still raised against
> > that version. I see three options here:
>
> Right, the code makes sense. What I'm unsure of is whether the Bugzilla
> backend is adding the version in Bugzilla using the correct API call. I
> mean when a tag is applied, are we just adding the version in the
> versions list, or are we (accidentally) adding the version
> against ...the particular bug! I'm saying that the testsuite currently
> seems to cause bugs to be associated with versions, while it shouldn't.
> It's not the testsuite that's doing it really -- it must be the Scmbug
> Bugzilla backend.
>
> Yeah, have another look and see what's going on there.
>
> I see that the create function in Bugzilla/Version.pm reads:
>
> sub create {
> my ($name, $product) = @_;
> my $dbh = Bugzilla->dbh;
>
> # Cleanups and validity checks
> $name || ThrowUserError('version_blank_name');
>
> # Remove unprintable characters
> $name = clean_text($name);
>
> my $version = new Bugzilla::Version({ product => $product, name =>
> $name });
> if ($version) {
> ThrowUserError('version_already_exists',
> {'name' => $version->name,
> 'product' => $product->name});
> }
>
> # Add the new version
> trick_taint($name);
> $dbh->do(q{INSERT INTO versions (value, product_id)
> VALUES (?, ?)}, undef, ($name, $product->id));
>
> return new Bugzilla::Version($dbh->bz_last_key('versions', 'id'));
> }
>
> so it looks like it's implemented correctly. Hmmmm.... there's something
> fishy here.
>
> > 1. Leave it as is - don't allow people to remove tags that have bugs
> > raised against them. This to me seems valid - if there's a bug raised
> > against a version then it has been used by users and to me that would
> > mean it shouldn't be deleted. Having said all this, different
> > organisations have different policies.
>
> I think this option is reasonable, and also enforces change management:
> if users want to remove the version, they should scrub their bugtracker
> first. I just don't understand how the testsuite associated a bug with a
> version.
>
> > 2. Go back to SQL and delete the version in the database as per
> > previous behaviour.
>
> Well, we'd rather use the published Bugzilla API.
>
> > 3. Go through the bugs and change the version to null before removing
> > the version.
>
> No, that'd be too presumptious on our part.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
