Bugzilla reorg status?
Robert Kaiser
being resolved this week, wouldn't it be the perfect point to move
forward with this before release planning queries for 1.9.1 arise as the
next big blocker?
What's the status on this? Is someone working on the scripts, which were
the other issue?
Robert Kaiser
Gervase Markham
Yes, we are looking at moving on this ASAP. Dave Miller is reviewing the
scripts I wrote to move components and so on. My tentative date
suggestion to him was Friday 20th June, but I haven't heard back yet.
We have a plan:
http://www.gerv.net/temp/bmo-reorg.html
And an order of execution:
http://www.gerv.net/temp/bmo-plan.txt
(Yes, go on, laugh at my use of the "temp" directory.)
It's been nine months since the plan has been updated. However,
reopening the plan for another round of discussion would slow things
down and cause us to miss this window which you have rightly identified.
So the idea is that we execute the plan as it is now, and then a week
later, have a second round, which can incorporate both fixes to the
original plan and new things people have thought of.
So, if you have additions to the plan, hold your fire. If there are
things we are going to do which we should now _not_ do, let us know.
Gerv
Robert Kaiser
> Yes, we are looking at moving on this ASAP. Dave Miller is reviewing the
> scripts I wrote to move components and so on. My tentative date
> suggestion to him was Friday 20th June, but I haven't heard back yet.
>
> We have a plan:
> http://www.gerv.net/temp/bmo-reorg.html
> And an order of execution:
> http://www.gerv.net/temp/bmo-plan.txt
Sounds good, I'm very much looking forward to that! Thanks a lot!
Robert Kaiser
Wayne Mery
> Robert Kaiser wrote:
>> Now that the big blocker of the planned BugZilla reorg that FF3 was is
>> being resolved this week, wouldn't it be the perfect point to move
>> forward with this before release planning queries for 1.9.1 arise as the
>> next big blocker?
>>
>> What's the status on this? Is someone working on the scripts, which were
>> the other issue?
>
> Yes, we are looking at moving on this ASAP. Dave Miller is reviewing the
> scripts I wrote to move components and so on.
bmo reorg won't change affected bugs' last change date, right?
Gervase Markham
> bmo reorg won't change affected bugs' last change date, right?
Why would it be bad if it did?
Gerv
Axel Hecht
Wouldn't that break queries like "these bug had been stale for 3 months,
let's resolve them INCOMPLETE"? At least?
Axel
Gary Kwong
If it did, it would give us problems when we do queries for "old bugs"
that haven't been changed at all for some period of time.
Hopefully the migration won't change the "last changed" date.
-Gary
Tony Mechelynck
It would throw logs into the cogs of any query including "last change
older than XXX days", for one thing.
Best regards,
Tony.
--
Flying saucers on occasion
Show themselves to human eyes.
Aliens fume, put off invasion
While they brand these tales as lies.
Dave Miller
Yes, it will.
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
Makoto Kato
I have a question of current plan.
How about Firefox mobile?. Reporters should use minimo for it?
I believe Minimo project goes away.
- Makoto
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
-- Makoto Kato / mako...@gmail.com / m_k...@ga2.so-net.ne.jp
Robert Kaiser
> Wayne Mery wrote on 6/17/08 3:07 PM:
>
> Yes, it will.
Probably something we have to swallow. There are tradeoffs in many
things, the outcome of this reorg is badly needed, I'm happy with a
number of tradeoffs if we can finally get this done at least.
Robert kaiser
Gervase Markham
>> bmo reorg won't change affected bugs' last change date, right?
>
> Yes, it will.
Some changes will get done using the GUI; that will affect the last
change date. Some changes will get done using a script (e.g. component
renames). That doesn't _have_ to affect the last change date - it
depends what we tell the script to do. (I have the code in there, but
it's currently commented out.)
Of course, Dave's statement above might actually have meant to be a
ruling on that very question :-)
Gerv
Gervase Markham
> I have a question of current plan.
>
> How about Firefox mobile?. Reporters should use minimo for it?
> I believe Minimo project goes away.
The plan is probably out of date in that area. So we'll fix that in round 2.
Gerv
Wayne Mery
> Some changes will get done using a script (e.g. component
> depends what we tell the script to do. (I have the code in there, but
> it's currently commented out.)
>
> Of course, Dave's statement above might actually have meant to be a
> ruling on that very question:-)
I hope not :) I don't mind taking a hit for the greater good, but date
changes should be avoided if possible.
What I care about is bugs moving to new product Mailnews Core (~2,900
bugs), for example "Mailnews Core; Backend [moved from Core; "MailNews:
" prefix removed]".
Dave, my reading of http://www.gerv.net/temp/bmo-plan.txt is step 8 is
what will affect the example, "Backend" bugs. Gerv states the date might
not change depending on how you run it the script. Must you run the
script in a way that affects last changed date?
Simon wrote: "If they have been stale for a few months or even years,
they'll likely stay that way for another few months and then you can
query them again."
True if one is OK with waiting a long time. But, with a significant
mailnews bug cleanup effort in progress (and also targeting of bugs to
fix based on date), I and others are not keen on waiting several months
for the best indicator of "staleness" to reemerge. (and then, it will
would also likely be after we get locked down by beta status of
Thunderbird 3 - also no desirable)
If the date change can't be avoided - does it make sense for us
(Thunderbird) to do other massive bug changes like fixing QA for about
1700 core: mailnews:* bugs? (We've been deferring this to some "future
date" exactly because of not wanting to affect last changed dates)
Is it feasabile for justdave to reset QA to default in the same pass? Or
is this already in the script?
I know everyone is eager to get the reorg done, but I'll throw out that
it would help us if the reorg didn't occur as soon as this Friday June 20.
Gervase Markham
> I hope not :) I don't mind taking a hit for the greater good, but date
> changes should be avoided if possible.
I agree that it's unhelpful for the date to be changed by an automated
process, because people read "last changed date" as "last affected by a
human".
> True if one is OK with waiting a long time. But, with a significant
> mailnews bug cleanup effort in progress (and also targeting of bugs to
> fix based on date), I and others are not keen on waiting several months
> for the best indicator of "staleness" to reemerge. (and then, it will
> would also likely be after we get locked down by beta status of
> Thunderbird 3 - also no desirable)
You make a good point.
> If the date change can't be avoided - does it make sense for us
> (Thunderbird) to do other massive bug changes like fixing QA for about
> 1700 core: mailnews:* bugs? (We've been deferring this to some "future
> date" exactly because of not wanting to affect last changed dates)
>
> Is it feasabile for justdave to reset QA to default in the same pass? Or
> is this already in the script?
It would be a different script. Is there a bug filed on getting this
done? Please CC me.
> I know everyone is eager to get the reorg done, but I'll throw out that
> it would help us if the reorg didn't occur as soon as this Friday June 20.
Why's that?
Gerv
Mark Banner
> I know everyone is eager to get the reorg done, but I'll throw out that
> it would help us if the reorg didn't occur as soon as this Friday June 20.
The problem is, if we delay it any longer, then it'll just keep on
getting delayed.
Whilst I understand the problems with the "staleness indicator", I don't
think it would stall TB's effort too much.
Firstly, you could say look at UNCO bugs with a number less than x - if
they are created that long ago then they should have been
confirmed/closed ages ago.
Secondly, you could always shift the focus onto finding dups (of UNCO &
NEW) bugs for a few weeks (i.e. look at various areas), before you know
it, you'd have 30 days gone by where bugs haven't been touched.
Looking at the charts, to get to a stage where this wouldn't affect
Thunderbird's UNCO effort you're probably looking at another 6 months to
1 year.
This needs to happen sometime, its already been delayed a year or more,
lets just do it and take the hit. I think the advantages of being able
to file/locate bugs in a correctly laid out bugzilla far outway the
disadvantages of some harder searching for a month or two.
Standard8
Ron K.
> Wayne Mery wrote:
>
>> I hope not :) I don't mind taking a hit for the greater good, but date
>> changes should be avoided if possible.
>>
> I agree that it's unhelpful for the date to be changed by an automated
> process, because people read "last changed date" as "last affected by a
> human".
>
>
>> it would help us if the reorg didn't occur as soon as this Friday June 20.
>>
>
> Why's that?
>
> Gerv
>
Thunderbird Bug Day is Today, Thurday the 19th running for about an 18
hour span.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Wayne Mery
Because it's going to take more than 24hr to figure out how to deal with
the fallout - and I'd rather know prior to this change in case we want
to do something before those bugs get touched.
This is still dependent on Dave saying the date must if fact get changed
- I'd still very much rather it did not.
Wayne Mery
> Wayne Mery wrote:
>> I know everyone is eager to get the reorg done, but I'll throw out that
>> it would help us if the reorg didn't occur as soon as this Friday June
>> 20.
>
> The problem is, if we delay it any longer, then it'll just keep on
> getting delayed.
>
> Whilst I understand the problems with the "staleness indicator", I don't
> think it would stall TB's effort too much.
>
> Firstly, you could say look at UNCO bugs with a number less than x - if
> they are created that long ago then they should have been
> confirmed/closed ages ago.
I agree bug age (number) is a useful, alternative measure - particularly
for UNCO. However, UNCO is not the primary issue....
Triage is not all about UNCO. And in fact the population of confirmed
bugs with no activity FAR, FAR surpass the UNCO count. And this is the
population of bugs that is most affected by the reorg.
As far as I'm concerned, it's *all* about the date - until we have a
good alternative. Gary has something suggested by justdave - but it's
still being discussed.
> Secondly, you could always shift the focus onto finding dups (of UNCO &
> NEW) bugs for a few weeks (i.e. look at various areas), before you know
> it, you'd have 30 days gone by where bugs haven't been touched.
>
> Looking at the charts, to get to a stage where this wouldn't affect
> Thunderbird's UNCO effort you're probably looking at another 6 months to
> 1 year.
I'm not suggesting delay by more than a week or two, until some of the
issues mentioned so far can be discussed and planned out, at least
partly. I don't think that's too much to ask for.
> This needs to happen sometime, its already been delayed a year or more,
> lets just do it and take the hit. I think the advantages of being able
> to file/locate bugs in a correctly laid out bugzilla far outway the
> disadvantages of some harder searching for a month or two.
>
> Standard8
Again, harder searching/query isn't the only issue. And I haven't heard
anyone say another week or two wait will hurt something specific.
Though justdave saying this can be done with date not being changed
would make this whole discussion irrelevant.
Wayne Mery
> On 6/19/2008 11:59 AM, Mark Banner wrote:
>> Wayne Mery wrote:
>>> I know everyone is eager to get the reorg done, but I'll throw out that
>>> it would help us if the reorg didn't occur as soon as this Friday June
>>> 20.
>>
>> The problem is, if we delay it any longer, then it'll just keep on
>> getting delayed.
>>
>> Whilst I understand the problems with the "staleness indicator", I don't
>> think it would stall TB's effort too much.
>>
>> Firstly, you could say look at UNCO bugs with a number less than x - if
>> they are created that long ago then they should have been
>> confirmed/closed ages ago.
>
> I agree bug age (number) is a useful, alternative measure - particularly
> for UNCO. However, UNCO is not the primary issue....
>
> Triage is not all about UNCO. And in fact the population of confirmed
> bugs with no activity FAR, FAR surpass the UNCO count. And this is the
> population of bugs that is most affected by the reorg.
[I failed to complete the thought]
This ties in part to the era when bugs were confirmed according to lower
than the present standards, various though they may be. So a significant
percentage of status=NEW are in fact not confirmed.
Mark Banner
> Again, harder searching/query isn't the only issue. And I haven't heard
> anyone say another week or two wait will hurt something specific.
A week or two doesn't sound too bad, do we have any details from
Dave/Gerv as to how long these issues will take to resolve? IMO if we're
delaying, we should set a new date, publish it and stick to it.
Standard8
Gary Kwong
> As far as I'm concerned, it's *all* about the date - until we have a
> good alternative. Gary has something suggested by justdave - but it's
> still being discussed.
It's something along the lines of date of last comment being older than
an arbitrary date; *excluding the mass change commenter*. (The *'ed bit
is the important addition)
Then again, it can't be reliably tested till the reorg has actually
taken place.
-Gary
timeless
Gerv wrote:
> I agree that it's unhelpful for the date to be changed by an automated
> process, because people read "last changed date" as "last affected by a
> human".
this is problematic. what you're doing is asking for data corruption.
bugs can and do get randomly hit by people who cc, or add stray comments.
if your queries can't deal with this, then you need to fix them.
Wayne wrote:
> I and others are not keen on waiting several months
> for the best indicator of "staleness" to reemerge. (and then, it will
> would also likely be after we get locked down by beta status of
> Thunderbird 3 - also no desirable)
i'd suggest you schedule a moment (with justdave) before the change
where you can add closeme tags.
the closeme tags already violate staleness and it seems people are
able to use them.
> If the date change can't be avoided - does it make sense for us
> (Thunderbird) to do other massive bug changes like fixing QA for about
> 1700 core: mailnews:* bugs? (We've been deferring this to some "future
> date" exactly because of not wanting to affect last changed dates)
Wayne wrote:
> I know everyone is eager to get the reorg done, but I'll throw out that
> it would help us if the reorg didn't occur as soon as this Friday June 20.
Gerv wrote:
> Why's that?
Wayne wrote:
> Because it's going to take more than 24hr to figure out how to deal with
> the fallout - and I'd rather know prior to this change in case we want
> to do something before those bugs get touched.
this is important. we do not give anywhere near enough headsup nor
enough repeated notices in mozilla.org.
i'm about to catch up on mdp now, and i think i'm caught up on
bugmail, and possibly everything minus a couple dozen specifications i
need to review (critique, including complaints for most).
compare this w/ sun, where they announce changes months in advance and
give weekly reminders and progress updates.
this is not the same thing as saying 10 months ago "we're going to
make changes", being silent for 9 months, and then just doing
something.
Mark wrote:
> A week or two doesn't sound too bad, do we have any details from
> Dave/Gerv as to how long these issues will take to resolve? IMO if we're
> delaying, we should set a new date, publish it and stick to it.
Gary wrote:
> It's something along the lines of date of last comment being older than
> an arbitrary date; *excluding the mass change commenter*. (The *'ed bit
> is the important addition)
ideally mass changes should not have comments. such comments only hurt
such things (and my mailbox).
Dave Miller
<nth...@gmail.com> wrote:
That should work fine. I think someone else pointed it out already,
but the script that does the changes *has* to bump the last modified
date on the bug. Not doing so can cause data corruption because that
timestamp is used for collision detection among other things. There are
other ways to detect staleness in a bug besides the date, and Gary's
suggestion above is a good one.
This isn't going to happen today (Friday). I want to be around when it
does, and I'm getting on a plane in about 5 hours, and will be most of
the day traveling. And it's obvious people need a little more warning.
I'm also going to be on vacation this coming week. So perhaps early
the following week would be good. That gives us the coming week to get
everyone warned and have all our ducks in a row before we throw the
switch.
Robert Kaiser
> That should work fine. I think someone else pointed it out already,
> but the script that does the changes *has* to bump the last modified
> date on the bug. Not doing so can cause data corruption because that
> timestamp is used for collision detection among other things. There are
> other ways to detect staleness in a bug besides the date, and Gary's
> suggestion above is a good one.
OK, good to know. Will there be a mass-change comment on the bugs at
all, or will just "date of last comment" be a good search criterion as well?
Robert Kaiser
Wayne Mery
> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/370f6a7e356cab4d
>
> Gerv wrote:
>> I agree that it's unhelpful for the date to be changed by an automated
>> process, because people read "last changed date" as "last affected by a
>> human".
>
> this is problematic. what you're doing is asking for data corruption.
>
> bugs can and do get randomly hit by people who cc, or add stray comments.
>
> if your queries can't deal with this, then you need to fix them.
Are you saying the reorg's affect on date can be avoided?
> Wayne wrote:
>> I and others are not keen on waiting several months
>> for the best indicator of "staleness" to reemerge. (and then, it will
>> would also likely be after we get locked down by beta status of
>> Thunderbird 3 - also no desirable)
>
> i'd suggest you schedule a moment (with justdave) before the change
> where you can add closeme tags.
> the closeme tags already violate staleness and it seems people are
> able to use them.
Interesting point. Would have to be done before reorg of course.
Gervase Markham
> OK, good to know. Will there be a mass-change comment on the bugs at
> all, or will just "date of last comment" be a good search criterion as
> well?
We currently have no plans to add a comment, and timeless has requested
that we don't. Is there a reason we should?
Gerv
Gervase Markham
> this is problematic. what you're doing is asking for data corruption.
>
> bugs can and do get randomly hit by people who cc, or add stray comments.
>
> if your queries can't deal with this, then you need to fix them.
Well, Dave has said the date needs to change, so looks like it needs to
change :-) So there's no problem here.
> this is important. we do not give anywhere near enough headsup nor
> enough repeated notices in mozilla.org.
OK. From Dave's post, looks like we have a week. Where do you suggest we
make announcements? I've blogged it, and that'll appear on the planet.
That's a start.
http://weblogs.mozillazine.org/gerv/archives/2008/06/bugzilla_reorg_soon.html
Gerv
Robert Kaiser
No, the contrary. It's better for our queries if you don't. :)
Robert Kaiser
David E. Ross
>
> OK. From Dave's post, looks like we have a week. Where do you suggest we
> make announcements? I've blogged it, and that'll appear on the planet.
> That's a start.
> http://weblogs.mozillazine.org/gerv/archives/2008/06/bugzilla_reorg_soon.html
>
> Gerv
Announce it at <news://news.mozilla.org:119/mozilla.announce> (possibly
cross-posted to other news.mozilla.org newsgroups) and in a banner when
anyone go to <https://bugzilla.mozilla.org/>. This is indeed a big deal
and needs publicity. The fact that the last date updated will change
needs to be in the announcement.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Philip Chee
> Well, Dave has said the date needs to change, so looks like it needs to
> change :-) So there's no problem here.
Hmm. Does the new date have to be the current date or perhaps just
previousDate+60000ms?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]So what's the matter with MY taglines?
* TagZilla 0.066.6
Gervase Markham
> Hmm. Does the new date have to be the current date or perhaps just
> previousDate+60000ms?
Dave: if Bugzilla is closed down while the work is done, is there still
a danger of data corruption?
I guess if people have pages loaded, then submit them when Bugzilla
comes back up, there is.
Gerv
timeless
> Announce it at <news://news.mozilla.org:119/mozilla.announce> (possibly
> cross-posted to other news.mozilla.org newsgroups) and in a banner when
> anyone go to <https://bugzilla.mozilla.org/>. This is indeed a big deal
> and needs publicity. The fact that the last date updated will change
> needs to be in the announcement.
this is a good start. I'd also stick it on the top of MDC.
Gervase Markham
As soon as we have a date, I'll do these things. We can't agree a date
until justdave gets back next week.
Gerv
Daniel Veditz
> As soon as we have a date, I'll do these things. We can't agree a date
> until justdave gets back next week.
Justdave should be back now, are you close to having a date?
Gervase Markham
He's reviewing the code today. I want to make sure we are technically
ready before deciding on one. We should have one in the next 48 hours.
(Famous last words.)
Gerv
Peter Weilbacher
It's been roughly 570h now, is this reorg ever going to happen? Or did I
miss something?
P.
Robert Kaiser
A few days ago I was told it'll probably happen during next week's
Summit event as a good number of people probably won't do much work on
Bugzilla that week.
Robert Kaiser