[Rock-dev] Decision on the fate of external/ ?

Sylvain Joyeux bir.sylvain at gmail.com
Mon Sep 8 17:13:00 CEST 2014


> 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


More information about the Rock-dev mailing list