On Mon, Feb 2, 2009 at 3:39 PM, Benoit Jacob
<jacob.benoit..1@xxxxxxxxx> wrote:
> On Feb 2, 2009, at 5:40 PM, Benoit Jacob wrote:
>
>>> The classes have been on my hard drive for a while and I thought you may
>>> find these features useful enough for a potential inclusion in Eigen.
>>
>> As for inclusion in Eigen, I think that the main prerequisite for this
>> would be for us to have clear use cases in mind and being confident
>> that we can cover them with good performance.
>
> One suggestion is that you could offer a "Eigen contributed" repository
Ah, you said _repository_. Interesting.
Working directly in a subdir of eigen2/ makes this work much more available..
But it requires that contrib/ contributors get a KDE SVN account. Keir
is already getting one anyway, and Timothy's been around for a while
so i guess it makes sense that he gets one too. However, should there
be people contributing only to contrib/, it would be strange to get a
KDE account just for that.
What's wrong with that? Having contrib/ be a staging directory seems reasonable. As something moves from contrib to core, then the maintainer will naturally be able to continue without having to get a different account.
Put another way, what is the harm in being liberal with accounts? (ok, build breakage, but did i hear about a continuous build somewhere?)
So that would justify having a separate
repo. We could have a command in eigen2 to fetch it. Tuxfamily could
provide the SVN or Git repo.
We could do this, but it is just more hassle for users. At this point Eigen is small; let's not add unnecessary steps to get extra contrib packages. By keeping it together, the development rate of contrib/ stuff will be higher. contrib can be split off later if it becomes a burden.
Perhaps rename the contrib directory 'unsupported/' to make it clear that code in that directory may format your harddrive.
Keir
I don't know.
Benoit