On Tuesday, 1. December 2009 00:01:23 Kelvie Wong wrote: > Alright, I do believe we are due for a release (even in the current state). > > To do a release, I would need a few things, if anyone wants to help out: > > 1. A list of known issues, the only major things I am aware of are the > following: > - GPG/encrypted baskets are not working, and will be disabled to > hopefully prevent data loss > - The Basket list view is not fully functional -- things like the > background colour and the "search all baskets" counter aren't shown. > - Other than these two issues, nothing new has been added to Basket. > Everything that worked before should still work, everything that was > broken before (in 1.0.3.1) should still be broken.
My grievance is that the tray icon is "dead" under some circumstances. After starting Basket you can double click for showing/hiding the window and a right click will present a menu with "Restore" and "Quit" as possible actions. But sometimes it does not do anything on double click and only shows the "Quit" action in the context menu. I suspect some misbehavior in the (KDE) session restore code as it works fine after restarting Basket. > 2. A disclaimer for data loss ;) Is it possible to detect versions of KDE3 Basket, backup copy the old data and inform the user where it is in case something happens? As a remedy: does anyone have any knowledge about C++ testing frameworks? It may be worth considering writing some tests to expose and prevent data corruption and compatibility issues. > 3. Someone probably needs to let the distro maintainers know On a side note: I just have recognized that packaging or more accurately determining the actual copyright holders of the code is more than difficult for Basket. Normally thats what the AUTHORS file is for. Every contributor to code/artwork/translations should be listed in there. Otherwise packagers need to examine all the project's files which is cumbersome and may yield inaccurate results. Please somebody with a somewhat accurate knowledge of the history of the project verify and add contributors to the AUTHORS file. Thanks in advance. > 4. A website update/announcement. Maybe this should be the priority for the website team *hint* ;) > 5. Developer stuff. Should we expect more people helping with > development after? In that case, perhaps we should switch the tools > around. > > Gitorious is really growing on me, I'm quite tempted to switch over > there and use that as the main repository. Since Qt moved over there > and KDE has been pondering it as well for a while, it seems like the > logical place Basket should go. I second that. Gitorious has several benefits in my eyes. * It uses Git as VCS (obvious one) ;) * In contrast to GitHub it is project centric allowing groups to own projects and repositories as well as multiple repos per project. * There is a lot of KDE development on Gitorious already (just search for kde) so it will make Basket (developments) more visible to the community * The merge request[1] and code review[2] features are very nice > Also, our bug tracker; I haven't been there for a while, but perhaps > we should just go back to using the KDE bugzilla instead. I still > have to get admin privileges there (to close bugs). [1] http://blog.gitorious.org/2009/07/15/new-merge-request-functionality/ [2] http://blog.gitorious.org/2009/11/06/awesome-code-review/ Regards, Riyad Preukschas ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Basket-devel mailing list Basket-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basket-devel
