Re: [Basket-devel] Release time? Need a list of known issues, webpage update.

[Kelvie W. <ke...@ie...>]

2009/11/30 Riyad Preukschas <ri...@in...>:
> 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.
>

There's a test module in Qt, otherwise something simple can be
scripted quite easily.  Matt Rogers has put in some unit tests in the
code (look in src/tests, if interested).

>> 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.
>

Git can do this quite easily; the source code goes back as far as the
inital import done to SVN at v0.6.3, I think.

>> 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/

Yeah, I saw that, that is what essentially got me interested in
Gitorious, seeing how the Qt folks handled their merge requests.  It
also allows me to get a better picture of what everyone's working on,
the RSS feed I get from github is somewhat cluttered (hard to sort by
project), and I have to follow everyone manually.


-- 
Kelvie Wong