[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Potential bug on mouse wheel
--------------------------------------------------
From: <p.slegg@scubadivers.co.uk>
Sent: Monday, December 21, 2009 12:22 PM
Cc: <mint@lists.fishpool.fi>
Subject: Re: [MiNT] Potential bug on mouse wheel
It looks to me like the dialogue is opened and although it is
visible the AES doesn't think it is topped and so no amount
of clicking on it gives a response.
To me it seems like the problem is that Thing doesn't keep track of the top
window correctly.
I believe there was a lot of XaAES work done on topping and focus a
few years ago with ideas about permanently topped app windows etc.
for task managers, toolbars etc.
That's correct.
The MTU bug was never resolved, I just worked around it and use an MTU
setting that
means slower broadband.
The MTU bug is not reproducible on my Milan.
The floppy problem seems to be related to syslogd holding a lock but what
is causing that ?
Alan said he will be looking into this.
Anyone looking at the Sparemint website would assume Mint is dead.
There hasn't been a public release since 1.16.1 and there hasn't
been any RPM updates for years either.
That is very true.
I think we should try to create a Mint Roadmap and lay out some basic
tasks.
I agree 100%. And this is my suggestion:
1. Fix known bugs and get the current version stable.
2. Release 1.17 beta. Get it into AFROS and EasyMiNT so we get a userbase
that can report bugs. Average users should be able to report bugs without
having to subscribe to the list. They should be able to just send a mail to
'bugreport@freemint.org' (or whatever) and a case is created in our bug
tracking system.
3. Fix more bugs.
4. Release 1.17.
5. Start work on 1.18 with new features. Goto 1.
Fixing known bugs and getting 1.17 stable is critical. I know that adding
features and eye-candy is a lot more fun, but it's not worth sh*t if the
system isn't stable. When 1.17 is stable and released, we can start thinking
about what to add next.
Quarterly public builds would be good so that we aim for a stable
release. It gives a goal and tasks can be ticked off the list.
Not so sure about quarterly builds, but I think that there should be a lot
less fixes and features between releases. This would make bugtracking much
more manageable.
However, I think that this calls for more strict project management of some
sort. I don't think that Alan should be burdened with such tasks. If he's
the last remaining maintainer, he should only have to concern himself with
the technical details. Then the project should be managed by someone else,
of course in cooperation with Alan.
Also, I suggest that the current build-system is changed so that every 'make
all' also results in a zip that contains everything needed to install or
upgrade MiNT. Then it will be very easy for the maintainer and project
manager to release new versions when required.
Jo Even
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4694 (20091216) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com