Merged ft/policy-wip into master of grml-policy.git, marking this bugreport as 
"won't fix" as discussed. 

thx && regards,
-mika-

Michael Prokop <bts@bts.grml.org>:
> Michael Prokop <mika@grml.org> added the comment:
> * Frank Terbeck <bts@bts.grml.org> [20090613 11:55]:
[...]
> > Also: I don't think the header makes much sense any more.
> 
> > We're using git.
> > That means, we have *detailed* information about when a file what last
> > changed.
> 
> ACK, and "Latest changes" causes headaches when merging stuff.
> So I'm dropping this stuff out of every file which I'm updating anyway.

Good. :)

[...]
> > Filename:
> > maybe Purpose:. Maybe.
> > Author: (And I think "grml-team (grml.org)" would suffice.)
> 
> Good idea, I hate the "who should we include into the Author field
> overall" problem anyway. Let's use instead grml-team. Do we want to
> use something like that? ->
> 
> Author(s):   grml team (http://grml.org/)

Yes, exactly.

> > Bug-Reports: maybe. And if, we should make sure the right URL is used.
> 
> http://grml.org/bugs/ is the right place IMO, because it provides
> all the necessary information for users.

Okay.

> > License: GPL v2 (unless otherwise noted)
> 
> > Those headers don't need constant updating.
> 
> ACK
> 
> > I'm voting for "won't fix" here. Don't add redundant information
> > without reason.
> 
> How to we want to proceed? Should we provide a good, ACK-ed template
> in the grml-policy (which requires some action anyway as you're
> aware ;))?


Well, "won't fix" this issue, merge ft/policy-wip of grml-policy.git
into its master. Add a note about what header we generally expect for
new files in grml.

Regards, Frank

* Frank Terbeck <bts@bts.grml.org> [20090613 11:55]:

> Holy smoke.

> I just looked at the code.

> Do we actually want this much code for a feature that's boiling in the
> bts for 1.5 years without anyone really getting it working?

> Also: I don't think the header makes much sense any more.

> We're using git.
> That means, we have *detailed* information about when a file what last
> changed.

ACK, and "Latest changes" causes headaches when merging stuff.
So I'm dropping this stuff out of every file which I'm updating anyway.

> That means, we _have_ *detailed* information about who changed a file.
> About who changed what _line_ and _when_ (git blame/annotate).

> I really think these headers make sense:

> Filename:
> maybe Purpose:. Maybe.
> Author: (And I think "grml-team (grml.org)" would suffice.)

Good idea, I hate the "who should we include into the Author field
overall" problem anyway. Let's use instead grml-team. Do we want to
use something like that? ->

Author(s):   grml team (http://grml.org/)

> Bug-Reports: maybe. And if, we should make sure the right URL is used.

http://grml.org/bugs/ is the right place IMO, because it provides
all the necessary information for users.

> License: GPL v2 (unless otherwise noted)

> Those headers don't need constant updating.

ACK

> I'm voting for "won't fix" here. Don't add redundant information
> without reason.

How to we want to proceed? Should we provide a good, ACK-ed template
in the grml-policy (which requires some action anyway as you're
aware ;))?

regards,
-mika-

Holy smoke.

I just looked at the code.

Do we actually want this much code for a feature that's boiling in the
bts for 1.5 years without anyone really getting it working?

Also: I don't think the header makes much sense any more.

We're using git.
That means, we have *detailed* information about when a file what last
changed.

That means, we _have_ *detailed* information about who changed a file.
About who changed what _line_ and _when_ (git blame/annotate).

I really think these headers make sense:

Filename:
maybe Purpose:. Maybe.
Author: (And I think "grml-team (grml.org)" would suffice.)
Bug-Reports: maybe. And if, we should make sure the right URL is used.
License: GPL v2 (unless otherwise noted)

Those headers don't need constant updating.

I'm voting for "won't fix" here. Don't add redundant information
without reason.

Regards, Frank

* Frank Terbeck <bts@bts.grml.org> [20090407 02:03]:

> Obvious question: 1.5 year old issue with solution attached.
> Is the solution not good enough? Do we want to do this differently?
> Do we want this at all? Was this just forgotten?

> Regards, Frank - who fills up people's Inbox tonight. :)

Yeah, great :)

I just give it a try. First issue:

| Tried to find out your real name and email adress.
| Please verfiy them. They will be saved in /home/mika/.vim/userdata for further usage.
| Is your email adress correct? 

=> *which* email ad*d*ress is correct? Please display it. :)

And then the following errors appear (IIRC it's the same issue I
experienced long time ago, though it's not document in the BTS
AFAICS yet):

| Tried to find out your real name and email adress.
| Please verfiy them. They will be saved in /home/mika/.vim/userdata for further usage.
| Is your email adress correct?                                                        line   44:
| E121: Undefined variable: g:com
| E116: Invalid arguments for function setline
| line   46:
| E121: Undefined variable: g:com
| E116: Invalid arguments for function append
| [...]

Oh and: the 'Latest change' isn't needed anymore as you might know
(so we don't run into automatic merge problems), I guess this should
even simplify fixing it.

Alex, do you care updating the patch so we can ship it via
/etc/skel/.vimrc?

regards,
-mika-

Obvious question: 1.5 year old issue with solution attached.
Is the solution not good enough? Do we want to do this differently?
Do we want this at all? Was this just forgotten?

Regards, Frank - who fills up people's Inbox tonight. :)

See attached file, contributed by Alexander 'Stone' Steinböck.