XnView Software

<--// Moderator's note: This topic has been split off from “Here comes the Catalog”. //-->

I'm having a hard time keeping up with you, my friend

Sorry... {big sheepish grin}

Please let me know if you want me to refine the list.

No, it is very good. ...but do you think that's better to have a modern project management software (which includes also a bug-tracker) for XnViewMP?

Something like Apache Bloodhound: http://en.wikipedia.org/wiki/Apache_Bloodhound
Main page: http://bloodhound.apache.org/
A sample ticket here: https://bh-demo2.apache.org/products/%40/ticket/509

...or something like FusionForge: http://en.wikipedia.org/wiki/FusionForge
Main page: https://fusionforge.org/
...one can wander through its plethora of Forums, Trackers, Wikis etc. - for example see how FusionForge is managed in itself: https://fusionforge.org/projects/fusionforge/

Of course, both of the above are free, but it is up to Pierre to install one of them on his server.

m.Th. wrote:...but do you think that's better to have a modern project management software (which includes also a bug-tracker) for XnViewMP?

Yes, perhaps it's time to re-evaluate the idea. From the archives:

soeren ([url=http://newsgroup.xnview.com/viewtopic.php?t=5716&p=28402#p28402]10/Apr/2006[/url]) wrote:
One of my personal favorite topics regularly discussed with Helmut and sometimes Pierre is about using a bug tracking system, so I really like this discussion here ,-))

Drahken wrote:I've used the bugzilla system for mozilla on a few occaisions, and just found it hard to follow.

That is correct. Bugzilla is quite "legacy" now and there are a variety of other bt systems which are much more easy to handle.

Drahken wrote: Also, wouldn't a bug tracking system be kind of pointless with only 1 programmer working on the program? The main purpose of a bug tracking system is for open source software, so that each programmer can see what bugs have already been dealt with so that they don't duplicate their efforts.

No, I don't think so. A bt system is what it's name is standing for: Tracking these $§/((** bugs ,-)) For example it's also very usefull for Pierre as currently users are writing forum news which are not standardadized by any means. Sometimes people are forgetting to mention their version or platform, lots of time is spent to fetch this info. The BT system can standardize this be requesting this info directly when creating a bug info in the system.
Also it's quite nice for a user to see, that the current status of "his/her" bug: Done/postponed/rejeted/etc... You don't have to check new versions, update documents etc. As long as the systems is used for handling bug issues it's quite easy to cope whith such questions.

I think the forum worked as well as, or better than any bug tracking system would. However, I do agree that there should be a template or something telling everyone to post their system specs and such.

Drahken wrote: One flaw with the forum (although I don't think a bug tracking system would be any better, perhaps even worse since you wouldn't be able to move topics from the bug tracker to the support forum and vice-versa) is that people often don't know if they have a bug or just don't understand how to use something. As a result, some bugs wind up posted in the support forum and some report requests wind up in the bugs forum.

That is definitely a big drawback in the current system, so having a good bug tracking system for XnView would definitely help to further improve it and provide good feedback between the users and the developer.


regards,
Soeren

XnTriq ([url=http://newsgroup.xnview.com/viewtopic.php?t=10968&p=59820#p59820]22/Mar/2008[/url]) wrote:
How about a combined solution for both the help manual and bug-tracking?

• Trac – Integrated SCM & Project Management
  Trac is a web-based software project management and bug/issue tracking system emphasizing ease of use and low ceremony. It provides an integrated Wiki, an interface to version control systems, and a number convenient ways to stay on top of events and changes within a project.

XnTriq ([url=http://newsgroup.xnview.com/viewtopic.php?t=10968&p=61621#p61621]10/May/2008[/url]) wrote:
Flyspray – The Bug Killer!

Flyspray is an uncomplicated, web-based bug tracking system written in PHP for assisting with software development. It was originally conceived when the Psi Jabber client project couldn't find a bugtracker that suited their needs, and has been made available for everyone to use for their own projects.

Flyspray is Free Software, released under the GNU Lesser General Public Licence Version 2.1. This essentially means that you can get Flyspray and use it free of charge. The source code is available, and you are welcome to modify it to suit your needs. Submitting your changes back to us is entirely optional, but we'd love to hear from you!

Features include:

• Web-based, platform-independent
• Multiple database support, currently MySQL and PGSQL
• Easy installation
• Easy to use
• Multiple projects
• ‘Watching’ tasks, with notification of changes (email or Jabber)
• Comprehensive task history
• File attachments
• CSS themes
• Advanced search features (though easy to use)
• Atom/RSS feeds
• Two syntax options for task descriptions and more (Dokuwiki / plain text)
• Voting for tasks
• Dependency graphs

• Show Quick Reply Form feature missing
• Bug Tracker

I can answer but, unfortunately, I think that we hijacked this thread. ...before answering, can you split the topic in a new thread called 'Project management tools' or something similar?...

m.Th. wrote:I can answer but, unfortunately, I think that we hijacked this thread. ...before answering, can you split the topic in a new thread called 'Project management tools' or something similar?...

Would've done so right away, but had to go AFK ASAP (-:

...before of (re)discussing the Project Management here, I think that we must layout some main characteristics of XnViewMP's community:

- Small but technical, knowledgeable core of users. They can easily fill bugs, requests etc.
- Long-lasting but very easy to fix bugs / problems which means to me that we need a list to (re)mind us what was done and what not
- Discussions in forums but nothing is 'frozen' in an more or less organized/categorized form (the main usage of a bug tracker)

...something else?

Does Pierre want this sort of fine-grained forum participation in his development process? I don't get a sense that he is moving toward an open-source/crowd development paradigm.

Or have I missed something or misunderstood what is meant in this thread by "project management"?

JohnFredC wrote:Does Pierre want this sort of fine-grained forum participation in his development process? I don't get a sense that he is moving toward an open-source/crowd development paradigm.

Or have I missed something or misunderstood what is meant in this thread by "project management"?

The main thing which bugs me is that there are, as I said,

Long-lasting but very easy to fix bugs / problems which means to me that we need a list to (re)mind us what was done and what not

...this doesn't mean that he needs to open the code but he certainly should be more aware about what stops him to gain more users.

We are in a big overproduction crisis, our market is close to the level of commodity and the competition is fierce.

If he wants to stay in business he must be very focused on the users' needs. He must cover much better than the others the needs of his user base and then his user base will help him to survive by giving him goodwill / reputation - which he needs most now, spread the word, donations / sponsorship, free R & D / crowdsourcing etc. This has nothing to do with the open-source, even if, indeed, many FOSS projects use this model.

(Almost) all big players in IT use these. Nobody can do it alone anymore. They have big trackers directly linked to these forums, either internal (like Microsoft et al.) either a voting and keywording system in the very same forums like Adobe (see the link in the prev. proposition) and ACDSee (which uses the same social engine with Adobe).

The (ideal?) thing which I imagine is a global informational structure - that's why I posted in one of my prev. posts a link to Apache's Bloodhound - in which the developer should see immediately something like "There's a need to finish first the A thing for which I need to implement the B, C, D which has the following dependencies: B1, B2, C1, C2 etc. which comes from the discussions on topics Ax, Bx, By, Cx"

IMHO we must minimize the changes of the requirements, we must streamline the development workflow.

That's why I post my request (more or less) in logical order of implementation and much more in front of the developer's ability to implement and always I give hints (in the limited space of the forums) how one can implement this. He must know what lies ahead.