[1/5] gnuplot : new package

Create a package for gnuplot (a portable command-line driven graphing utility)

Signed-off-by: Anthony Viallard <viallard@syscom-instruments.com>
---
 package/Config.in             |    1 +
 package/gnuplot/Config.in     |    7 +++++++
 package/gnuplot/gnuplot.mk    |   13 +++++++++++++
 3 files changed, 21 insertions(+), 0 deletion(-)
 create mode 100644 package/gnuplot/Config.in
 create mode 100644 package/gnuplot/gnuplot.mk

Dear Anthony Viallard,

On Mon,  7 Jan 2013 14:30:13 +0100, Anthony Viallard wrote:

> +GNUPLOT_INSTALL_TARGET = YES

This line is not needed.

Also, please make your 1/5, 2/5, 3/5 and the LICENSE part of 5/5 a
single patch.

And then, a second patch containing your 4/5 and and the part of 5/5
that disables the documentation and the demos.

There has already been some discussion with Stefan about how to split
patches, and it seems that it is still not clear. Each patch should be
a logical change that works on its own.

So for example, in the same series, putting a package in section "Foo",
and then moving it to section "Bar" is very strange. Since you can
rebase your patches, why don't you put the package in section "Bar" in
the first place, so that we can believe you did everything perfectly
from the very beginning? :-)

You don't need to show to the whole world the gazillions of steps you
followed to create a package. You need to show the whole world a nice,
clean set of commits, where each commit is a logical change, that keeps
the "buildability" of Buildroot.

Does that make sense?

Thomas

On 07. 01. 13 14:48, Thomas Petazzoni wrote:
> Dear Anthony Viallard,
>
> On Mon,  7 Jan 2013 14:30:13 +0100, Anthony Viallard wrote:
>
>> +GNUPLOT_INSTALL_TARGET = YES
> This line is not needed.
>
> Also, please make your 1/5, 2/5, 3/5 and the LICENSE part of 5/5 a
> single patch.
>
> And then, a second patch containing your 4/5 and and the part of 5/5
> that disables the documentation and the demos.
>
> There has already been some discussion with Stefan about how to split
> patches, and it seems that it is still not clear. Each patch should be
> a logical change that works on its own.
>
> So for example, in the same series, putting a package in section "Foo",
> and then moving it to section "Bar" is very strange. Since you can
> rebase your patches, why don't you put the package in section "Bar" in
> the first place, so that we can believe you did everything perfectly
> from the very beginning? :-)
>
> You don't need to show to the whole world the gazillions of steps you
> followed to create a package. You need to show the whole world a nice,
> clean set of commits, where each commit is a logical change, that keeps
> the "buildability" of Buildroot.
>
> Does that make sense?
>
> Thomas
Indeed,

Sorry, i knew my post is not very sexy. This is because my git 
repository is very dirty and i don't known how clean my work.

I thoughwith lucky, my submit will be accepted :) Ok, i do the changes !

avd.

Dear Viallard Anthony,

On Mon, 07 Jan 2013 17:02:52 +0100, Viallard Anthony wrote:

> Sorry, i knew my post is not very sexy. This is because my git 
> repository is very dirty and i don't known how clean my work.

All you need to learn is how to use "interactive rebase".

See
http://elinux.org/Buildroot_how_to_contribute#In_case_of_mistakes_in_my_branch
for a very basic introduction. 

For more details, see
http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages.

Once you know how to use interactive rebase, you can prepare very nice
patch series.

Best regards,

Thomas

On 07. 01. 13 17:10, Thomas Petazzoni wrote:
> Dear Viallard Anthony,
>
> On Mon, 07 Jan 2013 17:02:52 +0100, Viallard Anthony wrote:
>
>> Sorry, i knew my post is not very sexy. This is because my git
>> repository is very dirty and i don't known how clean my work.
> All you need to learn is how to use "interactive rebase".
>
> See
> http://elinux.org/Buildroot_how_to_contribute#In_case_of_mistakes_in_my_branch
> for a very basic introduction.
>
> For more details, see
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages.
>
> Once you know how to use interactive rebase, you can prepare very nice
> patch series.
>
> Best regards,
>
> Thomas
Dear Petazzoni Thomas,

Thanks for the links. I already knew this command but i didn't realize 
it was so powerful !

I've commited better patches, it is good for you ?

Best regards,

avd.