[Brainstorm 2010] Garage and developer services

[dneary]

This thread is part of the Maemo Brainstorm 2010

Subversion, Gitorious, autobuilders, issue trackers, mailing lists... what can be done to improve the Maemo application developer experience by the community?

Propose your ideas and suggestions here, let's talk about it, and summarise the best ideas and conclusions in the Brainstorm 2010/Garage and developer services wiki page

[gri]

I'd like an option that the autobuilder does not add the packages to the repository when they were build successfully. Instead I want to get notified and be able to download the package before it's uploaded.
Otherwise you always have to make a new version number when the autobuilder did other things than the local sdk.

[Bundyo]

Also is it possible if a package build fails, the autobuilder to offer an option to scrap the package, so that we can reuse the version without changing the package itself (many of my build failures are actually unsatisfied dependencies and I don't want to change the version number and the changelog for that)?

[Bundyo]

Some of the developers dislike Bugzilla, is there a possibility Garage to offer a radio choice of several bug trackers?

[qgil]

It's been a while that I have been wondering about the mid term usefulness of http://garage.maemo.org . It made a lot of sense when it started in 2005, but nowadays there is a variety of rock solid services providing all those services, only not in a single place.

But how relevant is to have an ok-ish single place when with simple links you can have at reach free infrastructure like gitorious.org, transifex.net, wordpress.com, your closest bugzilla, etc?

The last garage project I created had as basically main purpose the obtention of a mailing list. I guess we could also have a default recommendation for project mailing lists.

Conclusion: http://gforge.org itself is not a simple beast to maintain, leave alone to customize, and the benefits nowadays are probably slim. So why not leaving it in pure maintenance mode, pointing developers to the current better alternatives instead of trying to add even more beef there?

[nicolai]

Originally Posted by Bundyo

Also is it possible if a package build fails, the autobuilder to offer an option to scrap the package, so that we can reuse the version without changing the package itself (many of my build failures are actually unsatisfied dependencies and I don't want to change the version number and the changelog for that)?

I never had this problem. I use always the same version number
if a package build fails. I use the webinterface to upload new
packages.I know packages are rejected if there is one already
with this version, but only if the build for this one succeeded.

nicolai

[Ferenc Szekely]

Originally Posted by Bundyo

Some of the developers dislike Bugzilla, is there a possibility Garage to offer a radio choice of several bug trackers?

A garage project can have several extra tabs (like the Lists, Tasks, Docs, Wiki etc). You could just create a tab for "Bugs" and point it to your preferred bug tracking service. See an example.

However this is just a link to a remote service, and no further integration is available. If the remote bug tracker offers RSS feeds for bugs, then we could perhaps list them on the garage pages, but nothing else, really.

[Ferenc Szekely]

Originally Posted by qgil

It's been a while that I have been wondering about the mid term usefulness of http://garage.maemo.org . It made a lot of sense when it started in 2005, but nowadays there is a variety of rock solid services providing all those services, only not in a single place.

Don't forget that granting upload privileges to extras happens through garage. It would take some effort to move this functionality elsewhere..

But how relevant is to have an ok-ish single place when with simple links you can have at reach free infrastructure like gitorious.org, transifex.net, wordpress.com, your closest bugzilla, etc?

The last garage project I created had as basically main purpose the obtention of a mailing list. I guess we could also have a default recommendation for project mailing lists.

Conclusion: http://gforge.org itself is not a simple beast to maintain, leave alone to customize, and the benefits nowadays are probably slim. So why not leaving it in pure maintenance mode, pointing developers to the current better alternatives instead of trying to add even more beef there?

GForge is not that bad to maintain. We have added quite a bit of new functionality there, we have the know-how.

There are couple of things which our garage offers for free unlike other providers:

• possibility of running private projects
• unlimited storage (for code, docs, etc)

However I agree with the maintenance mode proposal, but if there are some great ideas we can hack on GForge, no worries.

[Jaffa]

Originally Posted by qgil

It's been a while that I have been wondering about the mid term usefulness of http://garage.maemo.org . It made a lot of sense when it started in 2005, but nowadays there is a variety of rock solid services providing all those services, only not in a single place.

There are some advantages to providing them in a single place, including familiarity between projects, increasing possibility of cross-project collaboration; streamlined tools for Maemo use cases; web-site hosting and single authentication/authorisation point.

However, we could probably turn some of the defaults off for new projects.

The other big advantage is the offer of svn - for many tasks this is preferable (depending on the skills of the developers) - and I'm not aware of any gitorious-like service for Subversion.

However, there any many things around Garage which do need improvement: in particular, the communication around the move to vcs.maemo.org and drop.maemo.org were very poor. With svn relocation commands being discussed when developers had problems.

So why not leaving it in pure maintenance mode, pointing developers to the current better alternatives instead of trying to add even more beef there?

If it goes into "maintenance mode", it'll bitrot. However, if someone wanted to find the best-of-breed tools which provide the same features:

• Website hosting
• Version control (preferably choice of Subversion or git, but just git'd do for this list)
• Bug tracking
• Mailing lists
• Blogs
• Documents

...we could try and ensure tie-up between the services where appropriate.

[bergie]

Originally Posted by Jaffa

If it goes into "maintenance mode", it'll bitrot.

Not necessarily. As long as we have staff available maintaining the services and there are projects actively using them I don't think this will be a problem.