> kind of, yes. When support for a package can be found through the mailing > list, it is not external. The folder structure tells users directly whether > (good) support can be found on the rock-lists, or not > and users of these packages might have to care for themselves. Good support > here means that maintainer can also help by fixing bugs in the source, not > only the inclusion of the source into autoproj.
By this logic, most packages should go to external/ Most of our packages are a one-man or two-men development. When there is a bug, either the guy is around and can fix it or the people can dream of any support. In addition, if we strive to be more inclusive (i.e. have more contributors), this will become more and more the case. As the number of packages go up, we (Rock the project) really can't guarantee "Good support for each and every one of them". Package maintainers can, and all the projects we include have maintainers, just not people that necessarily identify themselves with Rock. Moreover, this point of view also goes contrary to the experience of most big projects with dependencies. Users don't care whether it is "developed by" or "pulled by". They are using Rock, have a problem with Rock, they are going to ask for help to the Rock developers. And so should they, we might have broken something ourselves. "This is a upstream bug" is a perfectly valid answer there, of course, but not the only possible. This was one of my point with the release situation: there is no such thing as a "well supported Rock", only a "well supported Rock core". The rest is a collection of software developed by various people that have various priorities, various schedules (like "I can't help you right now, spacebot is in two weeks", or "I am in the last three months of my thesis, no time to look into it") and (hopefully) will come from various places in the world. It brings me down to the inclusiveness of Rock as a project. I have the impression that both the point of views on how releases should be made and external/ boil down to: what should Rock's identity be in the end. For the pro-external, I feel that Rock is a showcase to what DFKI does. Every development is done internally by projects and sometimes released. Development behind closed doors. Discussions behind closed doors. For me (I won't speak for the others), Rock was aimed at being a true open-source project. Which means that we need to be inclusive to as much people outside of Rock and *especially* outside DFKI and push and include devel code so as to show (1) that we are progressing and (2) favor having people contribute to the development of Rock, not only to fixing its bugs. That's the only way we can start having a community and not only DFKI: making decisions in the open, and not separating "we" and "them". Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
