development policy

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

development policy

Andreas Jellinghaus-2
Hi,

We had lots of discussion in the last weeks about
development policy (pkg-config vs. m4 files,
svn cleanups, how to generate documentation, ...).

I have started a wiki web page at
http://www.opensc.org/openct/wiki/DevelopmentPolicy

Comments and improvements are very welcome.

I'd like to keep the language in the page neutral,
so I can later copy it to all projects
(opensc, libp11, pam_p11, engine_pkcs11), but
we can also do project specific pages.

So far nothing is set in stone, but after we went
through discussing many issues, I feel it is best
to sum up the current compromises and document them
someplace for future reference.

Thanks for your help.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: development policy: a little doubt

Jonsy (teleline)
El jue, 01-09-2005 a las 17:20 +0200, Andreas Jellinghaus escribió:
> Hi,
[....]
> I have started a wiki web page at
> http://www.opensc.org/openct/wiki/DevelopmentPolicy
> Comments and improvements are very welcome.

In the document we can read:

| "make maintainer-clean" removes all generated files."

But GNU People says:

| `maintainer-clean'
|      Delete almost everything from the current directory that can be
|      reconstructed with this Makefile.  This typically includes
|      everything deleted by `distclean', plus more: C source files
|      produced by Bison, tags tables, Info files, and so on.
|
|      The reason we say "almost everything" is that running the command
|      `make maintainer-clean' should not delete `configure' even if
|      `configure' can be remade using a rule in the Makefile.  More
|      generally, `make maintainer-clean' should not delete anything that
|      needs to exist in order to run `configure' and then begin to build
|      the program.  This is the only exception; `maintainer-clean' should
|      delete everything else that can be rebuilt.

This apply, for instance to every "Makefile.in" in subdirectories....

Several months ago, pam_pkcs11 followed OpenSC convention, but after
Ludovic "showed me the truth" we decided to start with GNU convention.
In fact, I use a "mrproper" script to clean pam_pkcs11 tree to get
ready for svn

Really not sure on what to do....

Juan Antonio
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: development policy: a little doubt

Andreas Jellinghaus-2
On Thursday 01 September 2005 17:53, juan antonio martinez wrote:
> In the document we can read:
>
> | "make maintainer-clean" removes all generated files."
>
> But GNU People says:

tst, linus wrote:
> First off, I'd suggest printing out a copy of the GNU coding standards,
> and NOT read it.  Burn them, it's a great symbolic gesture.

I don't like identing with two spaces, programming in lisp, using herd,
adding "gnu/" before every occurrence of the word "linux", claiming
it is the "gnu system with the linux kernel" (sorry, they forgot about
kde, gnome, xfree, x.org, perl, python, apache, any everyone else
who wrote big parts of the system), writing m4 macros, and many other
things the gnu people say.

lets not talk about who sais what, this is no tabloid :)

I believe in clean systems. make uninstall should match make install.
make distclean should leave the source exactly as it was after untar'ing.
and make maintainer-clean should remove all those files generated with
bootstrap scripts.

I think the gnu people are wrong on this: they don't delete everything
that was generated with "make" when doing "make distclean". as you can
read, they won't delete info files, tags tables or files created by
bison.

they more or less do in "make maintainer-clean" what I expect "make distclean"
to do. and they have no equivalent of what I want "make maintainer-clean"
to do: there is not autounconfigure no autounmake and libtoolize --undo,
they completely forgot the concept of realy cleaning up the mess
those tools generate.

so why do a real cleanup? well, I often see that people forget to add new
files. they might have changed all Makefiles and everything, but forgot
to do a "cvs add" or "svn add". and the reason for that is: they are used
to have heaps of garbage in their working directories, because the gnu
toolchain doesn't properly clean up.

I think that is bad. with cvs I didn't have a different choice: I had
to have two checkouts, one where I worked and one untouched, so that
I could create patches that include any new file and any removed file
by diffing between those trees. with cvs it was essential for me to
get the make maintainer-clean situation right.

now you could argue that svn is a lot advanced and I can do a "svn add"
also on a read-only repository and thus generate diffs that include
localy added files. right. but it still requires me to think and to
not forget doing that "svn add" command.

I'm lazy and prefer the current system where I have to get "make
maintainer-clean" right, but can use all my old scripts and the two
checkout system to produce complete diffs, and not worry about
doing "svn add" to make sure a new file is part of a diff and
later to "svn rm" so the file is undone and I can "svn up"
after I added the file to the repository (via my third checkout -
which is the only writeable and is not used for anything else).


such a long posting for such a minor issue. long time ago we
started to change all makefiles in opensc do a real cleanup
on "make maintainer-clean". copied that system to openct when
we started that project and now copied that system to libp11,
pam_p11 and engine_pkcs11 as we split those off opensc.
it's not new, it is an old tradition still cared about.


but also it is not a requirement for any other project and
it is not set in stone, if the majority of developers want
it to be changed, we will change it.


> This apply, for instance to every "Makefile.in" in subdirectories....
>
> Several months ago, pam_pkcs11 followed OpenSC convention, but after
> Ludovic "showed me the truth" we decided to start with GNU convention.

hmm, maybe ludovic also forgot to burn the gnu coding standard and
instead read it?  :)

> In fact, I use a "mrproper" script to clean pam_pkcs11 tree to get
> ready for svn

that is one alternative to work. other people maintain those gazillion
of .cvsignore files and svn:ignore properties, so they have a readable
"svn stat" / "cvs stat" output and can catch files accidentialy not
added / not removed.

I'm happy with the system as it currently is. I don't want to change
it, but I also don't want to presure anyone else to use it. I'm fine
if you want to changed it.

but: noone is allowed to ask the system to be changed and leave me
hanging in the air :) if you want it to be changed, you would need
to either add an mrproper script or similar and maintain it, or add
those ignore properties or any other solution. simply removing some
nice featute and not providing an alternative is something I absolutely
veto. :)

Andreas
p.s. uh, long text. should we add this or some digested version to the
developer policy page? (unless we change the "make maintainer-clean"
system?)
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: development policy: a little doubt

Roumen Petrov-2
In reply to this post by Jonsy (teleline)
juan antonio martinez wrote:

> El jue, 01-09-2005 a las 17:20 +0200, Andreas Jellinghaus escribió:
>
>>Hi,
>
> [....]
>
>>I have started a wiki web page at
>>http://www.opensc.org/openct/wiki/DevelopmentPolicy
>>Comments and improvements are very welcome.
>
>
> In the document we can read:
>
> | "make maintainer-clean" removes all generated files."
>
> But GNU People says:
>
> | `maintainer-clean'
> |      Delete almost everything from the current directory that can be
> |      reconstructed with this Makefile.  This typically includes
> |      everything deleted by `distclean', plus more: C source files
> |      produced by Bison, tags tables, Info files, and so on.
> |
> |      The reason we say "almost everything" is that running the command
> |      `make maintainer-clean' should not delete `configure' even if
> |      `configure' can be remade using a rule in the Makefile.  More
> |      generally, `make maintainer-clean' should not delete anything that
> |      needs to exist in order to run `configure' and then begin to build
> |      the program.  This is the only exception; `maintainer-clean' should
> |      delete everything else that can be rebuilt.
>
> This apply, for instance to every "Makefile.in" in subdirectories....

Don't worry about this. Just build outside source tree and all is ok - Makefile.in and etc. left in source tree as should.

> [SNIP]
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: development policy: a little doubt

Ludovic Rousseau
In reply to this post by Andreas Jellinghaus-2
On 01/09/05, Andreas Jellinghaus <[hidden email]> wrote:
> On Thursday 01 September 2005 17:53, juan antonio martinez wrote:
> > Several months ago, pam_pkcs11 followed OpenSC convention, but after
> > Ludovic "showed me the truth" we decided to start with GNU convention.
>
> hmm, maybe ludovic also forgot to burn the gnu coding standard and
> instead read it?  :)

I confess I have read (part of) the GNU automake documentation. Sorry
for that :-)

I don't think I ever read the GNU coding styles. I don't like the GNU
indentation for example, but I don't like some parts of the OpenSC
indentation either :-)

Andreas I see your point and will not complain anymore.

Bye,

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel