[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Policy: Versioning Macros In The Archive
From: |
Guido Draheim |
Subject: |
Re: Policy: Versioning Macros In The Archive |
Date: |
Thu, 27 Jan 2005 21:13:30 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906 |
Peter Simons wrote:
> Guido Draheim writes:
>
> >> These are all fields that my software uses internally
> >> and which need to be consistent in order for the whole
> >> thing to work. [...] Since, according to you, I can't
> >> treat any fields as "internal" as long as I distribute
> >> them publicly, I will stop distributing them.
>
> > Good lord, Peter, would you please stop overreacting, the
> > message to you was "stop modifying what the submitter has
> > given to you including the @version tag".
>
> But Guido, that is exactly what this will accomplish! The
> solution is beautiful. I had the right idea from the start,
> I just didn't realize it! Instead of having the _internal_
> archive information in the m4 source code and stripping that
> for release, I'll have that information in a separate
> database which will be invisible to users of the archive.
>
> This way, I can re-categorize, change, and re-organize
> everything just as I see fit, without ever having to modify
> the file that the submitter sent me!
That is almost but not entirely correct - I have started to
use those *.log files that will register meta-information
for the macros but I see them more as a fallback - if the
submitter wants a certain version tag then it should be
shown atleast additionally. Please keep that in mind when
cutting things.
>
> So in short, the only tags the submitter knows are:
>
> @synopsis
> @summary
>
> This makes the whole thing a lot easier for everybody. And
> the best part is: I can store that internal database with
> the meta-information in XML, like I wanted to all the time.
>
> Okay, I am sorry about the mess. I made a mistake when I
> decided to put the entire archive meta-data into CVS. I
> shouldn't have mixed up my stuff with the stuff the users
> submit. I apologize.
>
Well, in the majority of cases the submitter will actually
request an obsoletion or additional author mark. Even more
so there should be a pointer to obsoletion and authorship
in any copy of the macro being around in different projects
(either acinclude.m4 or project-local m4/ subdirectory). In
the last message it did all sound as if you will be stripping
it out of the "redistributed macro" moving it to an internal
database - be very sure submitters will be calling you names
if you try that.
-- good luck, guido
- Re: Policy: Versioning Macros In The Archive, (continued)
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Guido Draheim, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive,
Guido Draheim <=
- Re: Policy: Versioning Macros In The Archive, Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Guido Draheim, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Braden McDaniel, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Alexandre Duret-Lutz, 2005/01/27
- no-meta-data-rewrite is online (was: Versioning Macros In The Archive), Peter Simons, 2005/01/27
- Re: Policy: Versioning Macros In The Archive, Tom Howard, 2005/01/28
- re-licensing (was: Policy: Versioning Macros In The Archive), Peter Simons, 2005/01/28
- Re: Policy: Versioning Macros In The Archive, Guido Draheim, 2005/01/27