http://people.mozilla.com/~sayrer/2011/temp/process.html
It's time for a deeper dive on three areas that need more attention if we are to actually follow through. I'm going to cover some issues that multiple people have raised, and outline our plans to get more coordination in place.
1.) Getting patches on to mozilla-central.
I think there's some confusion about what "pref'd off" or "backoutable" means. How to make sure something can be backed out is up to the developer, according to our plan. Keep in mind that the developer is responsible for removing a feature if there's a problem, so making sure there's a switch is probably worth it for a big new piece of code. For a two-line patch, the feature removal strategy is probably a backout.
There have also been questions about how repositories that feed patches into mozilla-central are to operate. My suggestion is that they are self-governed, with the understanding that entire merges may be reverted if they land changes that are too hard to disentangle. For example, I think the JS team members are the best people to make landing policy decisions for the TraceMonkey tree.
2.) Release Management Details
Christian Legnitto is working on this document, by coordinating with IT, Release Engineering, QA, L10N, Addons.mozilla.org, and other groups. Gathering this data will take a lot of time, so please give Christian some space to operate. Keep in mind that we have more than 3 weeks to resolve many of these questions.
3.) Update Channel Bootstrapping
Sheila Mooney is going to run a temporary weekly meeting to track the status of this project. Right now, the proposed time is Wednesdays at 10am. She'll send out a notice to dev.planning on this matter.
This meeting will cover the actual updater code as well as dependencies such as bugzilla UI.
-------------
I hope that clarifies the status quo somewhat, but let me and/or the list know if there's something missing or wrong.
It's exciting to see so much effort taking place for Firefox 5.
thanks,
Rob
Will this meeting also cover tracking the changes required to enable
silent updates?
Joe
AFAIK, the changes required are just "don't show the notification that
there is an update to perform by restarting now", which is roughly
what Chrome does: changes are applied at the next startup, whenever
that might be.
There's more work to do the update application ahead of time, rather
than charging it to the next startup, but I think that's orthogonal.
Mike
Chrome shows a tiny notification icon. Perhaps Firefox should, too.
http://hsivonen.iki.fi/screen/Chrome-update.png
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
That reminds me so much of the old Firefox 1.0 "christmas tree" update
notification that it pains me to say I just spent 20 minutes
unsuccessfully looking for a screenshot of it.
-Ted
WHEREAS we are just sort of discussing this off-topic and buried under a misleading header when it should properly have a project description page explaining the existing work underway, future work to be undertaken and suggested user experiences under evaluation ...
... we ditched the "Christmas tree" notification because we determined that nobody understood what it meant. I know the UX team is looking at actually including an indicator that Firefox requires an update on a home tab which would replace the home button, and be a permanent app tab that could be used for browser-wide notifications like update required, session available to be restored, and also tie in to Firefox Sync information.
While I don't think we should tie things too closely together, I do think that this approach is far superior to a dingus that appears somewhere in the UI. IMO, better places are:
- on the new tab page
- next to the Exit entry in the Firefox button (where applicable)
- if urgent (ie: we've gone 24 hours without an update) a dialog of some form, preferably non-modal, but noticable
cheers,
mike
Ben's Christmas tree!! FTW!
- A
- Rob
+ I have a feature page in progress -
https://wiki.mozilla.org/ChannelSwitching/ChannelSwitchingFeature. It
covers the mechanism for which a user can "switch" channels but
doesn't really address anything in the UI for the "silent update"
piece specifically. We could certainly add this in...as I said, it's a
work in progress.
I will be sending out a formal announcement for the public status
meeting next Wed @10:00am (PST). I will probably wait until I have
some notes from the Monday discussion. This is not a long term
recurring meeting but will go on for several weeks as we get the new
process of the ground and it's valuable to continue to meet to track
issues and identify new projects that need some coordination.
Cheers,
Sheila
On Fri, Mar 25, 2011 at 9:08 AM, sayrer <say...@gmail.com> wrote:
> Yes, that is what I meant by "updater code".
>
> - Rob
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Yeah. It's great to see so much activity on this list, but let's pay
more attention to staying on topic in a given thread. It makes it easier
for people who don't follow the list on a daily basis.
If you want to discuss something tangential, please start a new thread.
- Rob
I'll hook up elsewhere in the threads here where my thinking about l10n
and channels is at this point, anyway. Like, sneak preview, I don't
think that all channels will be available for all locales.
Axel