On Mon, Jul 25, 2011 at 11:38:21PM +0200, DarkNekros <[email protected]> wrote: > I will say that it would be nice to indicate the number of the fw > version of current to know if the bug was fixed or if it wasn't (i.e., > current-1.5, current-1.6, etc).
We introduced git hashes in /etc/frugalware-release on current exactly for that purpose. In case of reporters paste that version, we can see what "current" meant when the report was sent in. > I'm 100% with Marius to review all the old opened bugs to decide > what to do with them. I will go further and tell those people who are > going to review them to label the tickets, like I said before, to know > which current number version was or is. Given that the main frugalware.org package lists stable releases, usually you can guess the version from the report date. One possible danger I see here is to blindly close all tasks which are 1 year old or older - some of them describe currently existing bugs. But sure, in most of the cases, the task is no longer relevant and cleaning those up is much appreciated. Xarkam: not keeping the bug database (the conversion is not need to be perfect, but at least description and comments should be migrated) is a no-go, please try to think of developers who spend much of their free time on Frugalware since years - it's quite important that when a commit message talks about "- closes #1234" then we know where to look it up. If we loose that database, then developers will learn that referring to bug numbers is useless, since they are wiped in the next migration anyway, so we'll end up with meaningless commit messages, like "closes security bug". I agree that Flyspray has its problems, but starting from scratch with Trac (or any other bug tracking software) is even worse. Thanks.
pgpKB6laCvTEk.pgp
Description: PGP signature
_______________________________________________ Frugalware-devel mailing list [email protected] http://frugalware.org/mailman/listinfo/frugalware-devel
