Hello Davic, David Kastrup wrote: > the GNU LilyPond project is slated to move regarding its issue tracking > infrastructure since Google Code, which we have been using previously, > is closing down operations in late summer.
Google Code closing down has caused disruption to many projects. It is a good example illustrating why long term stable repositories are necessary. Obviously I am thinking Savannah here. However as you are finding out that having Savannah doesn't make things a done deal however. > The current issue tracker is at > <URL:https://code.google.com/p/lilypond/issues/list>. That is quite an extensive list of entries to track. > As far as I understand, Savane is not currently a viable option for > several reasons. I might not get all of them right but I'll try > sketching what was found problematic: No one here will argue that Savannah doesn't need improvement for a variety of reasons. However I wonder if you have thought about the debbugs.gnu.org? This is an instance of the Debian BTS. http://debbugs.gnu.org/ Which bug tracking system people like is a strong personal preference. With debbugs everything is handled by email. People either love it or hate it. I am one of the people who love it and therefore I will advocate for it. The GNU instance isn't quite as fully functional as the Debian one however it is pretty close. The one feature I miss is the ability to subscribe to individual bugs. If you want to explore the GNU debbugs further the best place to discuss it is the [email protected] mailing list. Glenn Morris is the maintainer. > a) much of our issue/patch handling is done by scripts making life > easy for developers. Savane apparently does not offer an API for > script-based manipulation of its issues. The Savane code base implementing Savannah was developed from the free SourceForge code base some time back by a few strong developers. However time passes and currently there isn't any active development happening. The previous developers have moved on to other projects. That doesn't mean that we wouldn't want more development to happen. Far from it. It just means that currently there isn't anyone actively developing it. Features such as you ask for are perfectly reasonable. If someone were to implement them I am sure they could be incorporated into the code base. It would need someone to do the work. Specifically here I am talking about the web interface. Certainly the backend version control is maintained for example. That happens on a different system and is used as an engine by the web interface. > Now the current shortterm migration that the developers aim for is to > Allura, the software that SourceForge is currently running on as it > seems rasonably close in features and look-and-feel and is running on > free software as opposed to GitHub. Both an import to Allura running on > Sourceforge <URL:http://sourceforge.net/p/testlily/tickets> as well as > import in an Allura version installed on a personal computer have been > attempted. The import scripts takes about 36h, the current database > about 150MB. That is quite the import task! > Now the question is whether supporting something like Allura on > Savannah could ever become an option or how we could otherwise > reduce being dependent on a number of different hosters with mixed > priorities regarding the willingness or ability to support large > free software projects. The Git repository for LilyPond is already > on Savannah. There has been various short discussions about improving Savannah over the recent years. Nothing has ever happened out of them. A few people have wanted to migrate to FusionForge. Others want to use other things. Others want to maintain the current. I mention it like this because inertia has been carrying the site forward and there isn't any clear statement of direction differently. If someone wanted to commit to doing the work I think anything would be possible. But it would need someone to work on the problem. Specifically I think you are asking if we are already thinking of Apache Allura. We are not already thinking of it. Personally I wouldn't want to try to do a big-bang migration of Savannah to anything different. Instead in the same way that debbugs is an alternative BTS available for projects I would much rather see an instance of whatever fly formation along side it. Projects that wished to use it could do so without needing to migrate others that want to avoid the hosting thrash. In my mind this would be similar to how on vcs we host cvs, svn, git, hg and others side by side without requiring everyone to use a chosen one of them. However this type of opinion can cause a duplication of workload. I am not saying this is your case but for example many times people become excited about something, drive by code it, then abandon it. It would be worse for a free(dom) GNU hosting to have many different competing systems and none of them have anyone to maintain them. I would hate to end up with Savane and Allura and GitLab and several others but no one to maintain them. That is the current problem now. The original developers of Savannah have migrated to other projects. Of the new people here now only Assaf has been making headway on it. Fortunately the important things such as the version control is very solidly supported. I know that many people would like other random features in web user interfaces on top of the version control but at least with the vcs instance we know that the source code is safely hosted for long term availability. > Thanks for any thoughts about this Let me emphasize that those were my personal thoughts and not any type of policy statement. Nothing has been decided. Bob
