From mint-bounce@lists.fishpool.fi Mon Dec 21 06:48:39 2009 Message-ID: <7F23F7302157451193C950D1C576C053@mercatus.local> From: "Jo Even Skarstein" To: References: In-Reply-To: Subject: Re: [MiNT] Potential bug on mouse wheel Date: Mon, 21 Dec 2009 12:46:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-EsetScannerBuild: 6227 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: joska@online.no Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: -------------------------------------------------- From: Sent: Monday, December 21, 2009 12:22 PM Cc: 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