|
From: M R. <mr...@gm...> - 2010-04-12 17:05:40
|
On Mon, 2010-04-12 at 11:06 -0500, kevin granade wrote:
> On Mon, Apr 12, 2010 at 10:25 AM, M Rawash <mr...@gm...> wrote:
> > - fork an earlier version of Ion that didn't include Tuomo's additional
> > terms (or one that had a loophole in it), this means a lot of extra
> > work, when many people would like to see us moving on (start adding new
> > features, rather than going back and fix/add old ones).
> >
>
> Another "PRO" for this option is the libtu and libextl situation.
> AFAIK these libraries are also unmaintained now, and I don't imagine
> them growing in popularity to the point of it being helpful to have
> them as separate libraries. IIRC, they were still part of the same
> package at the point when the license changes were made, so will be
> part of our original code. I haven't had a chance to really dig in,
> so for all I know this might be a trivial issue. All I know is this
> is the issue I ran into (trying to compile/install ion3 on a fresh
> system and failing since libtu/libextl were missing) that made me
> aware of the true extent of the problem.
>
> Also, what are the libtu and libextl licenses like? if they're
> standard lgpl we have a great deal of flexibility with what we do with
> them, to the point of possibly using the latest libtu/libextl along
> with the older version of ion as a starting point, but if they are a
> similar modified license, it seems it will be all-or-nothing with
> regard to which version of the sources we use as a starting point.
libtu and libextl are both licensed under standard LGPL, and Tuomo
didn't consider them as part of Ion (forming a whole), which means we
really can do whatever onto them. we will most likely distribute them
with notion and keep their licenses unchanged.
> On another note, how much information do we have available concerning
> the issues that were fixed in the time between the license change and
> the most recent release? It will make a rather large difference to
> how easy that work will be to reproduce if we have detailed
> information about the bugs we want to work on.
> More concretely, which resources would we be able to use if we do use
> the pre-license-change source code as a starting point:
> mailing list archives
> darcs commit messages
> changelog
> other???
well, depending on which version/snapshot we will fork, we can either
get a darcs log ('$ darcs changes') or a diff output. either way, we can
easily have a very accurate list of (two years worth of) changes,
> Thanks for the update,
> Kevin Granade
>
> >
> > as you can see, all our options are lacking in one way or another, so
> > it'd indeed be good if we could get Tuomo's blessing, but i think we
> > should remain realistic going forward; so if you have other
> > ideas/opinions, please, do tell.
> >
> > regards,
> > M Rawash
> >
> >
> > ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
>
> grr, I have crappy managed hosting with no ssh access, I'm tempted to
> get better hosting just so I can get rid of these ads, but I also
> haven't set anything like that up before. Does google's project
> hosting do the same thing?
IMO, a host with no ssh access is a bad idea, as for google, they
definitely don't have ads (just a few unnecessary instructions that can
'probably' be disabled), they do get spammed a lot though (which can
'probably' be avoided too).
regards,
M Rawash
|