getfirefox

[Ged Murphy]

Although we're in feature freeze, do you think it's worth including the 
getfirefox utility to the 0.2.9 branch?

It's a great little app and I had firefox running for a few hours last 
night with no real issues.

I'm thinking it would be good to get lots of feedback to ensure it's 
stable for the upcoming network release.
As this will be one of our selling points, we need to ensure it's stability.

Ged.

[Magnus Olsen]

We fot feature freeze for 0.2.9 I say no
they for wait until next release we are doing

----- Original Message ----- 
From: "Ged Murphy" <gedmurphy(a)gmail.com>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 14 December 2005 11:07
Subject: [ros-dev] getfirefox


>   Although we're in feature freeze, do you think
> it's worth including the
>  getfirefox utility to the 0.2.9 branch?
>
>  It's a great little app and I had firefox running for a few hours last
>  night with no real issues.
>
>  I'm thinking it would be good to get lots of feedback to ensure it's
>  stable for the upcoming network release.
>  As this will be one of our selling points, we need to ensure it's 
stability.
>  
>  Ged.
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  -- 
>  No virus found in this incoming message.
>  Checked by AVG Free Edition.
>  Version: 7.1.371 / Virus Database: 267.13.13/199 - Release Date: 
2005-12-13
>  
>

[Ge van Geldorp]

>   From: Ged Murphy
>  
>  Although we're in feature freeze, do you think it's worth 
>  including the getfirefox utility to the 0.2.9 branch? 
I agree that getfirefox is totally awesome :D but I might not be completely
objective on it. I always copy fixes I made to trunk to the branch, but as
you noticed, we're in feature freeze and getfirefox is not a fix, it's a new
feature, hence I didn't copy it. Then again, the risk to stability in the
branch is minimal. I think WaxDragon should decide on this, I can live with
it either way.

GvG

[Magnus Olsen]

I do think it is good idea start bending the rules when new cool program or
featuer comes and put it to the release branch.  I want see we strict follow
this rules.
other wise it maybe end up all new featuer and program ends up to the
release bransh when they comes to trunks under a release process.


----- Original Message ----- 
From: "Ge van Geldorp" <gvg(a)reactos.org>
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Sent: den 14 December 2005 11:32
Subject: RE: [ros-dev] getfirefox


> >   From: Ged
> > Murphy
> >
> >  Although we're in feature freeze, do you think it's worth
> >  including the getfirefox utility to the 0.2.9 branch? 
>  I agree that getfirefox is totally awesome :D but I might not be 
completely
>   objective on it. I always copy fixes I made to trunk
> to the branch, but as
>  you noticed, we're in feature freeze and getfirefox is not a fix, it's a
new
>   feature, hence I didn't copy it. Then again, the
> risk to stability in the
>  branch is minimal. I think WaxDragon should decide on this, I can live 
with
>   it either way.
>
>  GvG
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  -- 
>  No virus found in this incoming message.
>  Checked by AVG Free Edition.
>  Version: 7.1.371 / Virus Database: 267.13.13/199 - Release Date: 
2005-12-13
>  
>

[Ged Murphy]

Magnus Olsen wrote:
>   I do think it is good idea start bending the rules
> when new cool program or
>  featuer comes and put it to the release branch.  I want see we strict follow
>  this rules.
>  other wise it maybe end up all new featuer and program ends up to the
>  release bransh when they comes to trunks under a release process.
>     
I wasn't pushing this for the cool factor, I was pushing for the 
feedback we would get.
I think it would be beneficial to get feedback sooner rather than later.
If 0.3.0 does happen to be our next release, it would be the first time 
we've offered firefox, which could be dangerous IMO.
It's better to get the bugs ironed out before this time.

However I'm happy either way. It was just a thought.

[Ge van Geldorp]

>   From: Ged Murphy
>  
>  I wasn't pushing this for the cool factor, I was pushing for 
>  the feedback we would get.
>  I think it would be beneficial to get feedback sooner rather 
>  than later. 
It's still possible to download Firefox using ibrowser. Only problem is that
ibrowser is glacially slow for some reason :(

GvG

[Ged Murphy]

Ge van Geldorp wrote:
>   It's still possible to download Firefox using
> ibrowser. Only problem is that
>  ibrowser is glacially slow for some reason :( 
Last night I was finding the opposite.

ibrowser was lightening fast. I would go as far to say that it was as 
quick on ROS running in vmware as my firefox browser was on the host 
machine.
The only problem I had with it, is that you can't type into the text 
boxes, which makes Google unusable. 
Firefox didn't have this problem, but was much slower in comparison.

Ged.

[David Hinz]

I recognized something similiar last night, I was using something around 
r20150 on VMWare 4.5 at I was really wondering, why ibrowser was that fast.
Then I downloaded Firefox, and it didn't start, will check this again in 
some time.

This is another reason, why we should include getfirefox, it will expose 
a lot of combinations, where Firefox doesn't work. And it's very 
important to find them.

Greets,

David Hinz

Ged Murphy schrieb:
>   Ge van Geldorp wrote:
> >   It's still possible to download Firefox using
> > ibrowser. Only problem 
> >  is that
> >  ibrowser is glacially slow for some reason :( 
>  
>  Last night I was finding the opposite.
>  
>  ibrowser was lightening fast. I would go as far to say that it was as 
>  quick on ROS running in vmware as my firefox browser was on the host 
>  machine.
>  The only problem I had with it, is that you can't type into the text 
>  boxes, which makes Google unusable. Firefox didn't have this problem, 
>  but was much slower in comparison.
>  
>  Ged.
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Magnus Olsen]

We got featuere freze for 0.2.9
And if we start make one expetion then it will end up with next one. I got
code I want to be in 0.2.9

About new cool featuer for directx, it is not even commit yet for I need
more testing.
then I commit some real cool stuff for dx, like new sync of dxdiagn with
wine to was way out of
sync. I want see it also in 0.2.9. And I want also see the new sync with
wine in 0.2.9.
I want see alex ws_32 code in 0.2.9 shall I go on.

But we got a featuer freze for 0.2.9. and it must and shall be respekted.
other wise
will end up with alot of new featuer in 0.2.9. I am agains adding any new
featuer for 0.2.9
it will end up with a mess.  and DO NOT BREAK the relase process rule. THEY
must and shall
follow to 100%.




----- Original Message ----- 
From: "David Hinz" <post.center(a)gmail.com>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 14 December 2005 15:17
Subject: Re: [ros-dev] getfirefox


>   I recognized something similiar last night, I was
> using something around
>  r20150 on VMWare 4.5 at I was really wondering, why ibrowser was that 
fast.
>   Then I downloaded Firefox, and it didn't start,
> will check this again in
>  some time.
>
>  This is another reason, why we should include getfirefox, it will expose
>  a lot of combinations, where Firefox doesn't work. And it's very
>  important to find them.
>
>  Greets,
>
>  David Hinz
>
>  Ged Murphy schrieb:
> >   Ge van Geldorp wrote:
> > >   It's still possible to download Firefox using
> > > ibrowser. Only problem
> > >  is that
> > >  ibrowser is glacially slow for some reason :( 
> >  Last night I was finding the opposite.
> >
> >  ibrowser was lightening fast. I would go as far to say that it was as
> >  quick on ROS running in vmware as my firefox browser was on the host
> >  machine.
> >  The only problem I had with it, is that you can't type into the text
> >  boxes, which makes Google unusable. Firefox didn't have this problem,
> >  but was much slower in comparison.
> >
> >  Ged.
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  -- 
>  No virus found in this incoming message.
>  Checked by AVG Free Edition.
>  Version: 7.1.371 / Virus Database: 267.13.13/199 - Release Date: 
2005-12-13
>  
>

[Ged Murphy]

Magnus Olsen wrote:
>   About new cool featuer for directx, it is not even
> commit yet for I need
>  more testing.
>  then I commit some real cool stuff for dx, like new sync of dxdiagn with
>  wine to was way out of
>  sync. I want see it also in 0.2.9. And I want also see the new sync with
>  wine in 0.2.9.
>  I want see alex ws_32 code in 0.2.9 shall I go on.
>     
As I've already said on more than one occasion, this isn't just a ploy 
to get a 'cool feature' into 0.2.9.
It was an idea to help developers by gaining feedback in preparation for 
0.3.0, as it may be that this is the next release.

DirectX has nothing to do with 0.3.0, and Alex's code is still under 
test.  The getfirefox was a tiny little app that sits on it's own. Thus 
it wouldn't be decremental to overall system stability in the way 
DirectX or the socket library.

>   But we got a featuer freze for 0.2.9. and it must and
> shall be respekted.
>  other wise
>  will end up with alot of new featuer in 0.2.9. I am agains adding any new
>  featuer for 0.2.9
>  it will end up with a mess.  and DO NOT BREAK the relase process rule. THEY
>  must and shall
>  follow to 100%. 
I wasn't breaking rules. The wiki clearly states :

 "Any nontrivial or destabilizing modifications to the branch must be 
discussed on the mailing list prior to committing."

which is what I did and was hoping for some useful feedback, not someone 
going off on a tangent about DirectX and sockets.

Anyway, lets just forget the idea  ;)

Ged.

[David Hinz]

I just thought a bit more about it, we don't we create an additional 
"release"?

We could maybe stay with our current release cycle, but in addition to 
it, we could create releases for testers. They could be released every 
week, branching from head on monday 0:00, and feature freeze for one 
day, from sunday 0:00 until release which could be monday 0:00.

This way, we would create the possibility to test new features, but 
don't need to have them as stable as a release, as they are just 
wip-releases, if they compile fine and are installable and bootable, 
they could be releases.

This is a _bit_ like Microsofts CTPs, but they would be more often.

If you think, branching is a bit too mush work, I would suggest to 
create them from head, I don't think, it would be a very big problem to 
call for a feature freeze on head for one day in the week, and 
additionally this would have the advantage, that head would be more 
stable (it is very stable at the moment, but from time to time this 
chages, and this way it wouldn't).

This is just an idea, it's up to others, what they make out of it.

Greets,

David Hinz

And yes, I know this is getting a bit ot, but that's one of my hobbies, 
I guess...

Magnus Olsen schrieb:
>   We got featuere freze for 0.2.9
>  And if we start make one expetion then it will end up with next one. I got
>  code I want to be in 0.2.9
>  
>  About new cool featuer for directx, it is not even commit yet for I need
>  more testing.
>  then I commit some real cool stuff for dx, like new sync of dxdiagn with
>  wine to was way out of
>  sync. I want see it also in 0.2.9. And I want also see the new sync with
>  wine in 0.2.9.
>  I want see alex ws_32 code in 0.2.9 shall I go on.
>  
>  But we got a featuer freze for 0.2.9. and it must and shall be respekted.
>  other wise
>  will end up with alot of new featuer in 0.2.9. I am agains adding any new
>  featuer for 0.2.9
>  it will end up with a mess.  and DO NOT BREAK the relase process rule. THEY
>  must and shall
>  follow to 100%.

[Ge van Geldorp]

>   From: Ged Murphy
>  
>  Ge van Geldorp wrote:
> >   It's still possible to download Firefox using
> > ibrowser. 
> >  Only problem is that ibrowser is glacially slow for some
> >  reason :( 
>  
>  Last night I was finding the opposite.
>  
>  ibrowser was lightening fast. I would go as far to say that 
>  it was as quick on ROS running in vmware as my firefox 
>  browser was on the host machine. 
It turns out that if I set the virtual network card to NAT (which I do most
of the time) ibrowser is slow and Firefox doesn't start up at all. If I set
it to Bridged I get the same results as you. This is in VMware 5 on Linux.

GvG

[Ged Murphy]

Ge van Geldorp wrote:
> >   From: Ged
> > Murphy
> >
> >  Ge van Geldorp wrote:
> >      
> > >   It's still possible to download Firefox using
> > > ibrowser. 
> > >  Only problem is that ibrowser is glacially slow for some
> > >  reason :(
> > >         
> >  Last night I was finding the opposite.
> >
> >  ibrowser was lightening fast. I would go as far to say that 
> >  it was as quick on ROS running in vmware as my firefox 
> >  browser was on the host machine.
> >       
>  It turns out that if I set the virtual network card to NAT (which I do most
>  of the time) ibrowser is slow and Firefox doesn't start up at all. If I set
>  it to Bridged I get the same results as you. This is in VMware 5 on Linux.
>
>  GvG
>     
Mine is also bridged using vmware 5 on Windows.

Ged

[WaxDragon]

I get 2.5Mbit when transferring files in bridged mode with ncftp on a
debug build.  I'm sure the NAT latency aggrivates whatever this issue
with Moz/FF is.

On 12/15/05, Ged Murphy <gedmurphy(a)gmail.com> wrote:
>   Ge van Geldorp wrote:
> > >   From: Ged
> > > Murphy
> > >
> > >  Ge van Geldorp wrote:
> > >
> > > >   It's still possible to download Firefox using
> > > > ibrowser.
> > > >  Only problem is that ibrowser is glacially slow for some
> > > >  reason :(
> > > >  
> > >  Last night I was finding the opposite.
> > >
> > >  ibrowser was lightening fast. I would go as far to say that
> > >  it was as quick on ROS running in vmware as my firefox
> > >  browser was on the host machine.
> > >  
> >  It turns out that if I set the virtual network card to NAT (which I do most
> >  of the time) ibrowser is slow and Firefox doesn't start up at all. If I set
> >  it to Bridged I get the same results as you. This is in VMware 5 on Linux.
> >
> >  GvG
> >  
>  Mine is also bridged using vmware 5 on Windows.
>
>  Ged
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  

--
<Russell> argh
<Russell> iterator shenanigans :/

[James Tabor]

Ge van Geldorp wrote:
> >  From: Ged
> > Murphy
> >
> > I wasn't pushing this for the cool factor, I was pushing for 
> > the feedback we would get.
> > I think it would be beneficial to get feedback sooner rather 
> > than later. 
>  
>  
>  It's still possible to download Firefox using ibrowser. Only problem is that
>  ibrowser is glacially slow for some reason :(
>  
>  GvG
>   
Mozilla 1.7.12 is slow too, even on real hardware it takes over a min to dl the
mozilla home page.
James

[WaxDragon]

Moving the mouse around seems to speed things up. We really should
figure that one out.


On 12/14/05, James Tabor
<jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote:
>   Ge van Geldorp wrote:
> > >  From: Ged
> > > Murphy
> > >
> > > I wasn't pushing this for the cool factor, I was pushing for
> > > the feedback we would get.
> > > I think it would be beneficial to get feedback sooner rather
> > > than later. 
> >
> >  It's still possible to download Firefox using ibrowser. Only problem is that
> >  ibrowser is glacially slow for some reason :(
> >
> >  GvG
> >  
>  Mozilla 1.7.12 is slow too, even on real hardware it takes over a min to dl the
>  mozilla home page.
>  James
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
WD
--
<Russell> argh
<Russell> iterator shenanigans :/

[James Tabor]

Hi all!
WaxDragon wrote:
>   Moving the mouse around seems to speed things up. We
> really should
>  figure that one out.
>  
>   
I noticed mouse and keyboard interaction is slowing when playing Quake.
When you need to move using the keyboard, it becomes buffered and the
player moves all over the room. Mouse seems to have the higher priority
over the keyboard and acts non buffered.
Stuff I noticed,
James

[Magnus Olsen]

Hi
The mouse in dinput have very small or no buffer at all for the mouse.
but have a large buffer for the keyboard. and winquake are using dinput if
it
dectect directx.  But that is not the problem. The problem is key msg does
not
devliver fast egunt in the msg queru I think. it feel reactos msg query are
bit slow
in some case.  I can try look at dinput again see if I can do anything
aginst this
small problem. I have notice this problem is almost complete gone. when
I using vmware drv and some trix.  Can some with knowleges of msg devlier
system
lookinto if it can be made faster ?? or is it  another problem like
strechblt is to slow ??
or some thing else. I am guesing now what the problem lies

1. dinput smaller keyboard buffer if it posible.
2. look at strechblt see if it can be made faster
3. some look at msg quary if it can made faster.
4. something else ??

I think it is most 3 fualt I am not sure about it


----- Original Message ----- 
From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 14 December 2005 21:08
Subject: Re: [ros-dev] getfirefox


>   Hi all!
>  WaxDragon wrote:
> >   Moving the mouse around seems to speed things up.
> > We really should
> >  figure that one out.
> >
> >  
>  I noticed mouse and keyboard interaction is slowing when playing Quake.
>  When you need to move using the keyboard, it becomes buffered and the
>  player moves all over the room. Mouse seems to have the higher priority
>  over the keyboard and acts non buffered.
>  Stuff I noticed,
>  James
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  -- 
>  No virus found in this incoming message.
>  Checked by AVG Free Edition.
>  Version: 7.1.371 / Virus Database: 267.13.13/199 - Release Date: 
2005-12-13
>  
>

[TwoTailedFox]

Make an exception on Feature Freeze for 0.2.9, and everyone will want
to have that exception. Hell, even I'd like to see this included, but
we have Feature Freeze for a reason, even this trivial app might
introduce an unforseen bug.

On 12/14/05, Magnus Olsen <magnus(a)itkonsult-olsen.com> wrote:
>   Hi
>  The mouse in dinput have very small or no buffer at all for the mouse.
>  but have a large buffer for the keyboard. and winquake are using dinput if
>  it
>  dectect directx.  But that is not the problem. The problem is key msg does
>  not
>  devliver fast egunt in the msg queru I think. it feel reactos msg query are
>  bit slow
>  in some case.  I can try look at dinput again see if I can do anything
>  aginst this
>  small problem. I have notice this problem is almost complete gone. when
>  I using vmware drv and some trix.  Can some with knowleges of msg devlier
>  system
>  lookinto if it can be made faster ?? or is it  another problem like
>  strechblt is to slow ??
>  or some thing else. I am guesing now what the problem lies
>
>  1. dinput smaller keyboard buffer if it posible.
>  2. look at strechblt see if it can be made faster
>  3. some look at msg quary if it can made faster.
>  4. something else ??
>
>  I think it is most 3 fualt I am not sure about it
>
>
>  ----- Original Message -----
>  From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
>  To: "ReactOS Development List" <ros-dev(a)reactos.org>
>  Sent: den 14 December 2005 21:08
>  Subject: Re: [ros-dev] getfirefox
>
>
> >   Hi all!
> >  WaxDragon wrote:
> > >   Moving the mouse around seems to speed things up.
> > > We really should
> > >  figure that one out.
> > >
> > >  
> >  I noticed mouse and keyboard interaction is slowing when playing Quake.
> >  When you need to move using the keyboard, it becomes buffered and the
> >  player moves all over the room. Mouse seems to have the higher priority
> >  over the keyboard and acts non buffered.
> >  Stuff I noticed,
> >  James
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  --
> >  No virus found in this incoming message.
> >  Checked by AVG Free Edition.
> >  Version: 7.1.371 / Virus Database: 267.13.13/199 - Release Date: 
>  2005-12-13
> >  
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  

--
"I had a handle on life, but then it broke"

[Ged Murphy]

Ge van Geldorp wrote:
> >   From: Ged
> > Murphy
> >
> >  Although we're in feature freeze, do you think it's worth 
> >  including the getfirefox utility to the 0.2.9 branch?
> >       
>  I agree that getfirefox is totally awesome :D but I might not be completely
>  objective on it. I always copy fixes I made to trunk to the branch, but as
>  you noticed, we're in feature freeze and getfirefox is not a fix, it's a new
>  feature, hence I didn't copy it. Then again, the risk to stability in the
>  branch is minimal. I think WaxDragon should decide on this, I can live with
>  it either way. 
My main reason for wanting to break the rules just his once, is that I 
think we would gain a lot of feedback from users having firefox within 
their grasp.
With us working towards the 0.3.0 release, I think it would be a good 
thing to get lots of feedback as it needs to be stable by that time, 
being one of the major show stoppers.

However, I too can live with either decision :)

[Casper Hornstrup]

Restart the release cycle then and delay the release. Don't break the rules. If the
rules are wrong then change them instead of
breaking them. There will always be features that would "be nice" to have in a
release.

Casper

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Ged
> Murphy
>  Sent: 14. december 2005 11:55
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] getfirefox
>  
>  Ge van Geldorp wrote:
> > >   From: Ged
> > > Murphy
> > >
> > >  Although we're in feature freeze, do you think it's worth
> > >  including the getfirefox utility to the 0.2.9 branch?
> > >  
> >  I agree that getfirefox is totally awesome :D but I might not be completely
> >  objective on it. I always copy fixes I made to trunk to the branch, but as
> >  you noticed, we're in feature freeze and getfirefox is not a fix, it's a new
> >  feature, hence I didn't copy it. Then again, the risk to stability in the
> >  branch is minimal. I think WaxDragon should decide on this, I can live with
> >  it either way. 
>  
>  My main reason for wanting to break the rules just his once, is that I
>  think we would gain a lot of feedback from users having firefox within
>  their grasp.
>  With us working towards the 0.3.0 release, I think it would be a good
>  thing to get lots of feedback as it needs to be stable by that time,
>  being one of the major show stoppers.
>  
>  However, I too can live with either decision :)
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Royce Mitchell III]

Casper Hornstrup wrote:

>  Restart the release cycle then and delay the release.
> Don't break the rules. If the rules are wrong then change them instead of
> breaking them. There will always be features that would "be nice" to have in a
> release.
>
> Casper
>  
+1

[Ged Murphy]

Royce Mitchell III wrote:
>   Casper Hornstrup wrote:
>
> >   Restart the release cycle then and delay the
> > release. Don't break the 
> >  rules. If the rules are wrong then change them instead of
> >  breaking them. There will always be features that would "be nice" to 
> >  have in a release.
> >
> >  Casper
> >  
>  +1 
As I noted previously, I wasn't breaking the rules. The wiki states 
under feature freeze:

"Any nontrivial or destabilizing modifications to the branch must be 
discussed on the mailing list prior to committing."

http://www.reactos.org/wiki/index.php/Release_Management_Overview

I think restarting the release process is a little extreme. Lets just 
forget this thread ever started ;)

Ged.

[WaxDragon]

There are several things I would like to have in 0.2.9, but are not
directly addressing a bug.  Besides, ibrowser has been fixed so it can
download the Mozilla Control.  Getting feedback on the Mozilla Control
would be just as valuable as feedback on Firefox.

On 12/14/05, Ged Murphy <gedmurphy(a)gmail.com> wrote:
>   Although we're in feature freeze, do you think
> it's worth including the
>  getfirefox utility to the 0.2.9 branch?
>
>  It's a great little app and I had firefox running for a few hours last
>  night with no real issues.
>
>  I'm thinking it would be good to get lots of feedback to ensure it's
>  stable for the upcoming network release.
>  As this will be one of our selling points, we need to ensure it's stability.
>
>  Ged.
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
WD
--
<Russell> argh
<Russell> iterator shenanigans :/

[Mike Swanson]

The zip-file builds of Firefox still exist, though very hidden in the FTP. Is 
this an easier way to "install" Firefox on ReactOS perhaps? (Download Zip 
file, extract it in C:\Program Files, maybe add a shortcut on the 
desktop/start menu)

This here is exactly the same as the Firefox Setup 1.5.exe installer, only 
packaged in a Zip file (ignore that it's in the 'nightly' directory):
ftp://ftp.osuosl.org/pub/mozilla.org/firefox/nightly/2005-11-11-17-mozilla1…

On Wednesday 14 December 2005 02:07, Ged Murphy wrote:
>   Although we're in feature freeze, do you think
> it's worth including the
>  getfirefox utility to the 0.2.9 branch?
>
>  It's a great little app and I had firefox running for a few hours last
>  night with no real issues.
>
>  I'm thinking it would be good to get lots of feedback to ensure it's
>  stable for the upcoming network release.
>  As this will be one of our selling points, we need to ensure it's
>  stability.
>
>  Ged.
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
-- 
Mike