Closed Bug 271042 Opened 20 years ago Closed 20 years ago

Components, Releases, Votes for UMO

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: Bugzilla-alanjstrBugs, Assigned: asa)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.999
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.999

UMO in bugzilla should have subcomponents, target releases of its own, and votes. 

UMO should have separate items for front end and back end bugs.  We should also
let the community vote.  Right now we have things targetted for the next release
mostly by using the status whiteboard.  Since we'll have other releases, we
should label them so that we can target functionality.  

Reproducible: Always
Steps to Reproduce:
Oh yeah, patch reviews, too.
We're not growing that fast, and beyond update-beta vs. update I don't
particularly see the project being release focused. After the extension/theme
bugs go away with update-beta, the number of remaining bugs don't justify a full
product, IMO. Others may disagree.
You should keep in mind that other groups may want to have their own copy of
UMO.  I have seen interest in update.bugzilla.org, for example.  

I don't think having a separate component is a must.  The others, however, would
bring us more in line with the rest of mozilla.org.
Out of curiousity, where did the target milestone and versions that were added
to the update product come from? They're invalid.

Current Verions are 0.9 (branch/update), and 1.0 (trunk/update-beta). Since
Update tends to follow Firefox/aviary versioning/management, it'd make sense for
target milestones to be. 1.0, 1.1, 1.5, 2.0 and Future. Subject to change of
course, but way more accurate than the 2.0/2.1 that's there now.
They came from me at 3am.  There is no reason for UMO to follow the versioning
of Firefox.  UMO is not only for Firefox and I think you need to start
understanding that.  I picked 1.0 since UMO has been public for a while now.

2.0 represents the next generation of UMO, currently in beta.  There are enough
changes that it seemed to warrant a large jump.  There will be some incremental
updates after that, I'm sure.
The current version is pre-release and has been considered that since it's
inception, therefore it is, as labeled on the Admin login, 0.9, not 1.0.
Update-beta is the first finished release quality edition, which would get the
1.0 version, as is already planned. 

You can't just make up version #s because you feel like it and expect them to be
used. Thanks, but no thanks.

BTW, like it or not, Firefox and mozilla.org are currently the only implementor
or update. As such, following such versioning is not unacceptable, you need to
understand that.
Yes, the login page says 0.9 beta.  That would imply that 0.9 final is next.  

You just completely ignored Thunderbird.  You also ignored Mozilla 1.x, which
several people in mozilla.org do not even think should be supported.  

And of course you are forgetting that bugzilla has expressed interest.  When we
did the bugzilla reorg, don't you remember the reasons for the groupings? 
They're about the product itself, not about how Firefox uses them.

A complete rewrite of a site does not sound like going from beta to final.  Do I
misunderstand the use of beta?  Is the existing site beta-quality?  Yes.  And
I've said that for months.  But it is a public release that has been around for
a while.

I asked them to implement milestones so that we can start getting bugs closed
and real targets set.  Slapping everything under meta-bugs does not give anyone
a concept of what is really going on.
(In reply to comment #7)
> Yes, the login page says 0.9 beta.  That would imply that 0.9 final is next.
It might, though beta is mostly there for people who don't understand that < 1.0
equals pre-release.
> 
> You just completely ignored Thunderbird.  You also ignored Mozilla 1.x, which
> several people in mozilla.org do not even think should be supported.  
I'm picking Firefox to follow over Thunderbird or Moz 1.x because it's
Mozilla.org's lead product. Thunderbird is not harmed by it. Bugs needed for a
tbird release can be landed for one w/o needing a version in pairity.
Those who think mozilla 1.x should no longer be supported should contact me if
they feel that strongly. The general consensus so far for update-beta (based on
the discussions had so far) is it is still supported, and will remain featured
until the space is needed for something else.
> 
> And of course you are forgetting that bugzilla has expressed interest.  When we
> did the bugzilla reorg, don't you remember the reasons for the groupings? 
If you're determined to paint a picutre that looks one way, you'll find a way to
keep it looking that way. Currently update has no other installations, when it
does, they'll be worked with. Throwing yet another possibly conflictive product
release schedule when it's not needed doesn't help mozilla.org, and won't help
any potentional other implementors either. Paricularly when it doesn't hurt
update development or other would-be implementors in the slightest to follow a
release schedule that matches closely the primary product that uses it.

> They're about the product itself, not about how Firefox uses them.
> 
> A complete rewrite of a site does not sound like going from beta to final.  Do I
> misunderstand the use of beta?  Is the existing site beta-quality?  Yes.  And
> I've said that for months.  But it is a public release that has been around for
> a while.

Beta -- as in pre-release quality. The current site is not release quality, and
isn't tagged as such. It wasn't intended to be anything but beta-quality. The
label is used instead of just 0.9 for journalists who understand what "beta"
means. Sorry, you can't rebrand it based on your own personal wishes. It's 0.9.
(hence update_0_9_branch, which has existed for awhile now).
> 
> I asked them to implement milestones so that we can start getting bugs closed
> and real targets set.  Slapping everything under meta-bugs does not give anyone
> a concept of what is really going on.

Real targets? Having target milestones and versions that mismatch reality
doesn't create real targets. The defense that its better than meta-bugs doesn't
hold up. The milestones need changing, Comment #4 states milestones that make
sense for the project.

Target Milestones: 0.9, 1.0, 1.1, 1.5, 2.0 and Future
Versions: 0.9, 1.0
So you're going to wait until a Firefox release before releasing a new version
of UMO?  That's what having synchronized releases means.  

Fine.  Call the current version 0.9.  Call the next one 1.0.  Its just a number.
 But please don't say that you're following Firefox because that makes no sense.
 Why wouldn't you release a feature because Firefox hasn't had a release?  
Current release has been changed to 0.9.  Next milestone is now 1.0.  Can we
resolve all fixed-beta bugs as Fixed now since they're fixed on trunk?
For end-user clarity, don't resolve bugs fixed on beta but not on the live site.
Making sure end-users don't get conufsed when digging through update's bugs is
the reason the fixed-beta status whiteboard exists. From a visitor POV, it's not
fixed.

2.1 still exists in Target Milestones, and 1.1 and 1.5 don't.
2.0beta shouldn't be in Versions either.

Once those issues are corrected this bug is fixed.
Every other mozilla product, including bugzilla, marks a bug as fixed once the
code is checked in on trunk.  Sure, you get duplicates, but then you don't have
to rely on the whiteboard.  
Thanks for the advice, but I prefer not to confuse end-users. :-)
Oh, Future is missing too.

Target Milestones:
Remove 2.1
Add 1.1, 1.5 and Future

Versions: 
Remove 2.0beta

Timeless or Asa, can one of you make these changes for me? thanks! :-)
(In reply to comment #11)
> For end-user clarity, don't resolve bugs fixed on beta but not on the live site.
Apparently, that includes all of the bugs that users didn't file, can't see, or
don't care about.  There are a few I resolved like bad OS detection that I
shouldn't have.  But its moot now.

IMHO, marking a bug as "fixed-beta" means the same thing as "fixed on trunk". 
Every other product does it like that.  But this is Wolf's Product, so I
shouldn't have touched it.
(In reply to comment #14)
Justdave fixed that up for me. :-) So, I'm pretty sure that this bug is now fixed. 
Wolf, Bugzilla is not an end-user tool. It's a tool for development and QA. When
a bug is fixed, it should be resolved as such. Please follow the normal
conventions inside Bugzilla. Thanks.
Also, releases of UMO are not and should not be following the Firefox release
cycle. If UMO has a new release ready to go, it should not hold for 6 months
waiting on a Firefox release. The same would go for Firefox. If we're ready to
ship Firefox and UMO isn't ready, it should not ship prematurely.

The only exceptions would be changes in the web service that would require a
change by the other side.  
The web service isn't part of Update's code. It's a Firefox component living on
the same server, that shares a common DB.

Note: I never said the releases would be strictly coordinated. That was an
assumption made by somebody other than me. The target milestones represent a
rough timetable based on Firefox's release plan. If somethings ready before, or
alot of somethings, there's nothing blocking a release not currently on that
list. Just like I never said Update would be forced out early.. As Update 1.0
was most definitely not.

As for Update's deviation from Bugzilla's usual rules, the end-user duplicate
bugs reason given isn't the primary or the only. The greater reason is, with the
bulk of the code being touched, I'm leaving the bugs open, because of the high
chance of regressions and a not particularly high-visability site to get QA bug
reports on, before resolving them as fixed which will likely be before release,
I intend to personally make sure they are fixed, and no issues were brought up.
Rather than blanket resolve.

BTW, the review flag in Update, is first-review, it probably should be review.
and we might want to consider adding an approval flag there too. but i'm not
sure on that.
(In reply to comment #20)
> The web service isn't part of Update's code. It's a Firefox component living on
> the same server, that shares a common DB.

Who controls when this webservice gets updated on the server?  If I fix a bug,
do I have to wait for a UMO release?  A Firefox release?  Someone's approval?
Wolf, not resolving a Fixed bug in UMO until the next Firefox release is just
wrong. If it's fixed, it's fixed. If it's not fixed, then QA (whoever that
happens to be at the time) can re-open the bug. 
Asa -

He's not waiting until the Firefox release, just the UMO release.  However, I
agree.  If the code has landed in cvs, we should mark it as fixed.  If something
is broken, we open a new bug or reopen an existing one.
I didn't say Firefox release. I'd say until a bug is marked fixed, it's not
fixed, perhaps half-fixed.

(In reply to comment #21)
> Who controls when this webservice gets updated on the server?  If I fix a bug,
> do I have to wait for a UMO release?  A Firefox release?  Someone's approval?

So far, Vlad's maintained it. The webservice is *absolutely* critical to the
functionality of Firefox. So, I'd say there should absolutely be approval before
applying a patch to the live webservice. (After it's been tested thoroughly) I'd
defer that approval to Vlad or Ben even though I can probably give it accurately.
(In reply to comment #24)
> I didn't say Firefox release. I'd say until a bug is marked fixed, it's not
> fixed, perhaps half-fixed.

It is either fixed or not fixed.  Putting "fixed-beta" on the whiteboard implies
that it is fixed.  

> (In reply to comment #21)
> > Who controls when this webservice gets updated on the server?  If I fix a bug,
> > do I have to wait for a UMO release?  A Firefox release?  Someone's approval?
> 
> So far, Vlad's maintained it. 

So once Vlad signs off on the patch, who chooses when to put it on the site? 
Who decides when it has been tested enough?  Is that something Asa should decide?
FYI, UMO does have a Guided Bug submission process.  We should probably link to it.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.