I would be interested in started developing for gnuplot, but find =20
where to start a bit daunting. Maybe some mentoring of new developers =20=
with simple targets might be a good idea. Is there some sort of =20
'introduction to gnuplot dev' docs?
On 19 Jun 2007, at 20:45, Timoth=E9e Lecomte wrote:
> Daniel J Sebald wrote:
>> I'll be tuning out from the list for now... My thoughts are that =20
>> gnuplot development could use some fresh people to keep it going. =20=
>> The summers used to be fairly productive, but now not much happens =20=
>> even then. Should open an invitation for a few more =20
>> administrators or whomever's role it is to sort through patches =20
>> and chart a course for what needs attention. One or two people =20
>> doing that isn't enough on a voluntary basis. There are plenty of =20=
>> ideas for new stuff (multiple keys, better 3D/2D layout and use of =20=
>> margins, etc.). My sense is that people are willing to contribute =20=
>> but become discouraged when patches sit on SourceForge =20
>> indefinitely. Also, it might be good to review this kind of thing =20=
>> after each release, i.e., Will another release be warranted? What =20
>> new features, if any, should be in a future release? Are there =20
>> enough active contributors and administrators to get there in the =20
>> course of a year or two?
> Hi Daniel,
> For what is worth, I don't think the situation is hopeless, but I
> understand how you feel. The same happens for many open-source =20
> apart from the most trendy ones, and it heavily depends on the history
> of the project. For one thing, gnuplot being very old, some parts have
> not been touched for long. gnuplot is highly portable, which is a good
> thing but also a thing to take care of. Anyway, that's not what you
> express here. I would personally love to review your patches if I had
> more time, and it will hopefully happen after my examinations, i.e. =20=
> week. I can for sure review the history ones, but I'm afraid I =20
> won't be
> able to understand much of the hidden3d one unless I devote a lot of
> time to it... until now I've carefully stayed away from the graphic =20=
> functions in gnuplot.
> As far as contributions and administration is concerned, my feeling is
> that Ethan has been doing a great job lately. Of course, this doesn't
> mean that he can be everywhere every time.
> To me, the biggest differences between trendy projects that seem to be
> very dynamic and gnuplot today are:
> -few people have CVS commit rights, whereas the politic for kde (for
> example) is to give commit access almost immediately after the first
> patch. Other projects work like gnuplot, with a very small group of
> commiters, like compiz, but the latter also has a plugin architecture,
> and those plugins are written and modified by lots of people. Should
> more people get CVS access to gnuplot ? Why not. Apart from you, =20
> I don't see major and regular contributors that don't have CVS access.
> Anyway, having the right to commit doesn't mean that one should commit
> immediately anything. Staying a while on Sourceforge is a good =20
> thing, at
> least it gives the time to think about the best solution. So the real
> question is : why aren't there more contributors ?
> -gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The =20
> audience is quite heavily restricted to scientists, programmers and
> system administrators. In the scientists part, those who may be
> interested in gnuplot are those who aren't afraid of the command-line,
> those who are used to program or to use a shell, and those who are not
> addicted to Matlab but to LateX. Programmers and sysadmins tend to use
> gnuplot to plot stats and profiles, gnuplot is probably well suited =20=
> those people. All in all, I think gnuplot has a small target audience,
> and only a small subset of this audience tend to contribute.
> -there are a few alternatives to gnuplot (python, ...) so not all =20
> of the
> target audience ends up using gnuplot. And that's fortunate, diversity
> is good.
> -apart from the regular command-line use case, gnuplot architecture
> isn't that flexible. Most works to use gnuplot from another =20
> are either hacks or are not well integrated, so it's not satisfying =20=
> other projects that need a plotting engine.
> -gnuplot license discourages new contributors. This license obviously
> doesn't help in protecting gnuplot today. It prevents from sharing
> precious code with others. It results in doubt about the future of
> gnuplot, since because of this license, gnuplot is tied to its =20
> authors, who are now completely out of the development process.
> To address these problems and improve the situation, few but radical
> changes are needed:
> -make gnuplot core available as a library (including all its
> file/printers terminals, and adapted screen terminals, so that they =20=
> be used as widgets inside other apps).
> It implies to disentangle the command-line parser from the =20
> routines, and
> identify a sensible API. It's a lot of work.
> -contact identified contributors/rewrite parts of gnuplot to change =20=
> license, to something reasonable (core LGPL, frontend GPL). This is a
> huge lot of work, but that would definitely worth it. As far as
> rewriting parts, it could a good time to think about external
> libraries/tools. I'm thinking of doxygen for the help formatting,
> flex/bison for the parser. I think we would need to distribute the =20
> between several of us, and slowly get them done.
> I hope one day those two points will be marked as done. Most of the
> time, this kind of threads end up being unproductive, but I hope your
> mail and this one can help to start the process.
> Best regards,
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> gnuplot-beta mailing list