Re: [Nautilus-list] Re: 1.0.4 release

[The message I'm replying to was sent to me in person, but I believe
this discussion belongs on the list]

Reginald Melchisedek Poyau wrote:
> > I think performerance is important aswell, but I don't think it is fair
> > to ask for a release to be delayed just because of it. Better with
> > multiple releases; performerance is important, but it isn't everything.
> > For example, the Swedish translation in Nautilus 1.0.3/Eel 1.0 had some
> > problems, and of course I'd like to see newer releases with improved
> > translations replace it soon. Add this and a hundred of other small
> > fixes that have been done in cvs, and delaying a release because of some
> > obscure performerance problem that has been there all the time (and with
> > no patch) seems silly.
> I've never posted anything on nautilus-list before, but I have to say
> something here.  First, nautilus performance problems are _not_ obscure,
> and the very fact that these problems have been plaguing nautilus for
> god knows how long ( I have been using/testing nautilus when it was down
> right unuseable ), is more reason _to_ make them a number one priority;
> IMHO this is the first thing that new users will notice about nautilus,
> and maybe the the last thing also :-(.

I agree with you. To quote myself from my previous letter, "I think
performerance is important aswell".
And by "obscure" I in this case meant "possibly not trivial to fix". I'm
sorry if that was a poorly chosen word.

>         I have to agree with Darin that one should not blame harkers, but at
> the same time one have to realize this is **very** big problem for
> nautilus.
> > I fully understand Darin's view on this. If you want some performerance
> > problem fixed, the best way to fix it is to send a patch to the list,
> No I don't think that is the correct way to address this
> Like Yoann, I believe that this problem should be declared public enemy
> number one. Goals adn tasks should be set to resolve these issues within
> a certain time schedule ( I am not taking about release here more like a
> priority ).

But this is free software, and unfortunately Eazel does not exist
anymore. You can declare goals all you want, but there is no way you can
*force* people to accomplish certain goals. You have to consider the
time people can spend hacking on their spare time and hack on what they
think is interesting.

Also, judging from this list, people seem to have been looking at, and
hacking on, performerance-related issues for the last one and half
months anyway. I myself don't see what would immediately be additionally
gained from "declaring performerance a public enemy" or anything.

> IMHO, I believe that nautilus performance issue _is_ a show  stopper. ie
> regular users will not want to  understand or even care why is nautilus
> so slow at doing stuff they perceive to be simple, they will just
> experience it, and then they will just form their own conclusions why
> this so.

I don't think it's a showstopper. It's not like a horribly nasty data
corruption bug or so that will crash and burn your computer every odd
week and leave a remote root exploit in the remains. It is more like a
public perception problem, and while it is important, I don't see why it
should block releases with other important fixes.

"Release early, release often" is the core of free software development.
You don't have to solve everything at once; if you try to do that you
will never be finished. Making smaller evolutionary releases is more
important, to show that the project is still alive and help other people
follow the development, and help them help if they want to.

> > and hopefully it can be included in the next release after this, after
> > review and testing. AFAIK, this has always been the standard procedure
> > with patches in Nautilus. With many releases, it shouldn't take that
> > long before the next release with the patch included.
> >
> > > BTW: I'm not an user, and I'm working on the performance thing.
> > >      I'm just getting tired of having the impression to be alone.
> >
> > I think that impression does not represent reality. I think most
> > Nautilus hackers are concerned with performerance, and many discussions
> > on nautilus-list have also been performerance-related. Also not only
> > long-time Nautilus hackers, but also people like Alex Larsson, are
> > looking into performerance, and have sent patches. I don't think it's
> > fair to completely ignore all those contributions.
> I'd be willing to help solve these problems myself, but at last my gtk
> skill are not up to par yet.

They are surely better than mine :)

> Still, I would be willing to  help anyway I
> doing code review of all pertaining files, looking for anything
> suspicious, and then bring that to the attention of someone else.

I don't know if someone has put up a TODO list. Anyway, I think any help
with reporting bugs and reviewing bug fixes in
is still very welcome.

> P.S. I would like to say "THANKS" to *everyone* who have been working on
> nautilus.  I really do appreciate/enjoy your work.

Like I said, this belongs on nautilus-list :-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]