0.9.2 release

[Arik]

Hi All,

This thread is about the next release (0.9.2) which we're planning these days.
Even though we managed to implement a desired feature (tabbed browsing) and fix important bugs we had (such as move to trash on Windows 64 bit, handling of symbolic links etc) and some other enhancements and features in the last releases, we feel that the project is progressing slower than we expect. some of the reasons for that are the descreased number of contrinuters (although there were some very nice contributions lately) and the less participation by the community (as we can see by the descreased number of messages in the forums, open bugs, etc). so this thread is a step to improve it by getting the developers group to be more involved in the project, and the next release is about to focus on it from other aspects as well.

The main feature for the next release is Plugin APIs. by exposing APIs for plugins we want to make it easier to implement extensions - both technically (to implement the extention) and from the workflow aspect (to make is easier to make extensions accessible for the users), and by that to increase the number of contributions and involvment in the project. there is a different thread just about this feature, which describes the other goals of using plugins and its design, please check it out and comment there on this feature.

There are couple of other improvements in that area we plan to make in the next release:

1. Move to git: git had become more and more popular, especially in the open source world, in the last couple of years. we talked about switching to use git as our source control for a long time and now it seems like a good time to make the transition.

2. Replace our management tool: that is also something we talked about for a long time - to replace our trac system. we used bugzilla before, and then switched to trac, which is a good tool but it seems that there are better tools out there we can use to improve our productivity. apparently, we have a disagreement about which tools to use as some of us thing that we should use github which is very popular and has a very cool fork-pull requests mechanism that is well fit for open source development (and we already see few forks of mucommander that were made on github which is cool), and others think we should use gerrit + different bug tracker.

IMO one of the most important aspects in open source development is how good is the process of integrating patches into the project. we see that currently there are quite a few contributions that were posted in the trac for a long time (more than 1 month) - it is just too much, people forget about their patches that are waiting for so long, and it makes them feel that there is no feedback from the maintainers of the project, thus stop sending patches. in addition, the feedback we give, in case the patch needs to be improved, is mostly send via email/comments on trac which makes it more complex to describe the problems and to track that all the things that should be fixed are being fixed. we can also see that in most of the time, no one besides the maintainers is reviewing the patches.

We can solve most of the things mentioned above by using Gerrit. I'm using Gerrit for a pretty long time now, and it is a great tool for code review: it shows in a clear way the changes made in the code and the reviewer can write comments next to the code. in fact, the contributor can answer next to the comment, which makes it easy to track the review progress. everyone with openID can login and review, make comments and score the patches (while only maintainers can give a score that makes it possible to merge the patch). Gerrit makes it also possible to run automated tests for each patch before it is merged. I think that Gerrit can give us a big boost to the project and attract new contributions and involvement in the project (I also started to write a TODO list that we can use to propose things for people to contribute for the project, see: http://trac.mucommander.com/wiki/TODO?version=5).

As for bug tracking, what I'm missing the most with trac is:
- support for openID: I think that by letting people login without creating/typing/restoring a unique password but using their google/facebook account, to fill new bugs or comment on existing ones, we'll attract more people to do so. I know there is a plugin for integrating openID in trac, but I prefer a tool in which it is integrated in or it is easier to integrate a plugin in
- auto-completion of user names: currently if we want to add in cc someone we need to type his exact name since there is no auto-completion
- multiple projects support: as we're now having multiple projects (i.e mucommander, mucommanders-commons-file, mocommander-commons-runtime, etc) we need a way to managing the different project with the same tool. currently we can manage only one project in our trac. we'll need to upgrade our trac to have support for multiple projects
- vote capability: the users to have the option to vote for feature/bug fix in order for us to understand better what are the most desired things by the users. currently we monitor the forums and see the number of duplicate bugs etc - voting will be a much nicer mechanism.
- watch capabilities: the users to have an option to 'watch' an issue - to be notified of changes related to watched issues. currently we use the CC field for that, I would prefer better implementation of this capability
- better looking UI: I would prefer a tool that looks better and which is more customizable than our trac
- better knowledge center: currently we use the integrated wiki in the trac which is quite messy and is not fun to write in. I would prefer to have a better tool for that

Of course the bug tracker will have to have good integration with git and gerrit as well.

I think that Jira can address the above requirements and much more. I tested Jira once and it seemed to be a really mature product with lots of functionality and yet, easy to use and with very nice looking interface (that is subjective of course..). As Jira has free license for open source projects for many of their tools, I think it can well fit for our project.

3. Demoes and Discussions: I think that having a youtube channel or videoes section on our website with videos for new feautres and non trivial stuff like using 'quick lists' that I'm not sure how many are aware of, can be something useful for our users.

There were few discussions on the IRC channel once but most of the discussions are made in a private way, either by private emails/phone calls/etc, thus they were not accessible for the developers and users groups. Maxence used to publish discussions on the mailing list, but it wasn't always the case. I think we should use the mailing list more, and maybe even schedule meetings on IRC or conference calls once in a while.

Please feel free to comment about the stuff I listed above and propose different thoughts and ideas.

Regards,
Arik

[Johann Schmitz]

Hi,

thank you Arik for this extensive overview of the current status of the
mucommander project.

> 1. Move to git: git had become more and more popular, especially in the
> open source world, in the last couple of years. we talked about
> switching to use git as our source control for a long time and now it
> seems like a good time to make the transition.

I fully agree with you - moving to git makes it much easier for someone
to contribute code.

> 2. Replace our management tool

I would like to see less tools for following the overall progress of the
project. I'm a regular user of Jira at work and imho it's one of the
best tools to manage projects. Unfortunatly it's more workflow-oriented,
which means it only works well if all participants know and follow the
workflow. I doubt that this will happen without a strict rule to use the
system (so no more bug reporting in the forums, etc.) and a responsive
staff.

However, if the project moves to Github (and that's the git provider I
would prefer), i don't think we should use such a big solution as github
has many features like bug tracking, reviewing, commenting on commits,
wiki pages, etc. To avoid cluttering of these things, I think a good bug
tracker with tight integration into github should be enough in this case.

> - support for openID: I think that by letting people login without
> creating/typing/restoring a unique password but using their
> google/facebook account

As someone who forgets his login/password all the time, I would really
like to see OpenID support. There is some progression to support logins
via OpenID in Jira via Plugins (quick Google search; haven't tested them).

> - multiple projects support: as we're now having multiple projects (i.e
> mucommander, mucommanders-commons-file, mocommander-commons-runtime,
> etc) we need a way to managing the different project with the same tool.
> currently we can manage only one project in our trac. we'll need to
> upgrade our trac to have support for multiple projects

I'm in the progress of packaging the mucommander built from source on
Gentoo (the binary version has already been around for a long time).
From a packagers point of view, the split repositories of the commons
projects are really horrible. Plus it seems that the subversion
repositories differ from the source jars.
Maybe we should rethink the split of the commons trees - maintaining
multiple git repositories for one project seems to be very stressful to me.

> There were few discussions on the IRC channel once but most of the
> discussions are made in a private way, either by private emails/phone
> calls/etc, thus they were not accessible for the developers and users
> groups. Maxence used to publish discussions on the mailing list, but it
> wasn't always the case. I think we should use the mailing list more, and
> maybe even schedule meetings on IRC or conference calls once in a while.

I think this is not a technical but an organisational thing - every
idea/discussion should be created as a ticket or something to make it
visible for everyone. Something like campfire may help with that, but I
think it's a little bit overkill...

Best regards,
Johann

[Arik]

Thanks for the quick reply Johann

On Saturday, June 22, 2013 9:51:44 AM UTC+3, Johann Schmitz wrote: 

> 2. Replace our management tool

I would like to see less tools for following the overall progress of the
project. I'm a regular user of Jira at work and imho it's one of the
best tools to manage projects. Unfortunatly it's more workflow-oriented,
which means it only works well if all participants know and follow the
workflow. I doubt that this will happen without a strict rule to use the
system (so no more bug reporting in the forums, etc.) and a responsive
staff.

I think the 'bugs' section in our forum is redundant - usually when I see a bug report there I ask the reporter to open a ticket in the trac, as it's easier to track it for us, and that way the reporter is notified about any progress related to this issue. Sometimes I open a ticket and add a link to the relevant thread in the forums. We'll definitely need to keep encoraging people to use the system more in order to get the most of it. The workflow we'll define should be pretty simple and we probably won't use the advanced options that exist in tools like Jira for workflows, so that the workflow won't be difficult to follow.

 

Regarding the responsiveness issue - as with other open source projects which are not being developed by people that work on it on a full-time job basis, there are times where the maintainers have less time to spend on the project and the staff is being less responsive. I think we could address this issue by integrating more automated tools such as automated checkstyle tools that check the patches before the maintainer start to review so that he could concentrate on other things and the review will be quicker or tools that that make it easier to integrate contributions than manually apply patches and so on. Another thing is to reach a point where more people in the community review each other's patches. Such things will require less involvement by maintainers and we'll be able to be more responsive in other areas. I can say that it is something we think of.

However, if the project moves to Github (and that's the git provider I
would prefer), i don't think we should use such a big solution as github
has many features like bug tracking, reviewing, commenting on commits,
wiki pages, etc. To avoid cluttering of these things, I think a good bug
tracker with tight integration into github should be enough in this case.

Yes, to be honest I'm not very familiar with Github and I didn't work with it, but afaik Github provides the 'whole package' of things you mentioned, so if we'll decide to use it we may not even need additional tools and if so we could probably use simple ones that integrate with Github. It's just that, as implied in the previous meesage, I want to see us using Gerrit and it seems that there's no good combination between those two tools, as their workflows are different. I have a good experience with Gerrit (see gerrit.ovirt.org), and it also becomes more and more popular. in case we'll decide to use Gerrit we'll need more sophisticated bug tracker, as Gerrit doesn't provide bug tracking capabilities and wiki pages and so on, and Jira looks to me as a good choice.

 

 As someone who forgets his login/password all the time, I would really
like to see OpenID support. There is some progression to support logins
via OpenID in Jira via Plugins (quick Google search; haven't tested them).

Yeah, I've seen those plugins. we'll probably need to make a proof-of-concept to verify that all the things we want work as expected - integration with OpenID, integration with Gerrit (if we'll choose Gerrit) and so on. 

I'm in the progress of packaging the mucommander built from source on
Gentoo (the binary version has already been around for a long time).
From a packagers point of view, the split repositories of the commons
projects are really horrible. Plus it seems that the subversion
repositories differ from the source jars.
Maybe we should rethink the split of the commons trees - maintaining
multiple git repositories for one project seems to be very stressful to me.

 I don't like the fact we use different repositories for the different projects either - not only that it makes the packaging more complex as you say, it makes the debugging and development of features that influence couple of projects more complicated. I think that the benefit of using different repositories is that the projects are more independent and thus more reusable by other projects. Take a look at: http://code.google.com/p/moviejukebox/ - this project uses a light version of our commons-file project: it use the infrastructure with two file types, for local files and iso files. The fact that there are different repositories probably makes it easier for other projects to take only the part they need. IMO, we should decrease the number of projects by replaceing some of them with standard libraries, such as replacing the commons-conf project with library like apache-common-configuration or somehting similar, and consider what is the best way to handle the projects that remain.

I think this is not a technical but an organisational thing - every
idea/discussion should be created as a ticket or something to make it
visible for everyone. Something like campfire may help with that, but I
think it's a little bit overkill...

I also think it is a little bit overkill and I agree that it is more organisational thing. Using an improved knowledge sharing tool (such as atlassian confluence) + ticketing system + IRC channel + mailing list + something like openmeetings (http://code.google.com/p/openmeetings/) for conferences is more than enough. We'll just need to use them in the right way.

 

Arik