RFU jed 1:0.99.19~pre143-1

[Jörg Sommer]

Hallo Rafael,

Rafael Laboissiere schrieb am Tue 24. Jun, 13:31 (+0200):
> * Jörg Sommer <joerg at alea.gnuu.de> [2008-06-23 21:55]:
> > Rafael Laboissiere schrieb am Mon 23. Jun, 16:40 (+0200):
> > > Okay, I prepared two patches for the above.  You will find them attached
> > > below.  If you agree,
> > 
> > Sorry, no.
> > 
> > Firstly, what about starting a new version 0.99.19~pre143-2. I've
> > tagged the old version and it seems to be much clearer.
> 
> Okay, I will upload 0.99.19~pre143-1 as in the git repository and start -2
> as you suggest However, please, next time hold on with the tagging until the
> version is actually uploaded.

There's no problem with resetting the tag. But I found it much cleaner to
start a new version that making a version UNRELEASED, editing it and
releasing it again.

> > Secondly, the patch for the override makes changes to pieces out of
> > scope.
> > 
> > -  * debian.control: Bump Standards-Version to 3.8.0 (no changes needed) [RL]
> > +  * debian/control: Bump Standards-Version to 3.8.0 (no changes needed) [RL]
> 
> I sent you two patches in my last message.  The first
> (standards-version.diff) contained a typo

Yes, I see, but you should fix the typo in the old patch not in a new
one. You can do git rebase -i and mark the commit edit or create a new
commit and squash it with the old commit or you can use git commit --amend.

> > And you should not update the date. You should start a new version with
> > “Thu, 01 Jan 1970 00:00:00 +0000”. This avoids to have this line in
> > every diff and eases cherry-picks, mergen and rebases.
> > 
> > - -- Rafael Laboissiere <rafael at debian.org>  Mon, 23 Jun 2008 13:31:17 +0200
> > + -- Rafael Laboissiere <rafael at debian.org>  Mon, 23 Jun 2008 14:08:29 +0200
> 
> I do not see a problem with changing the trailer line,

This line is different in *every* commit, i.e. it's changed in every
commit. If you merge two branches, reorder commits or somehow else bring
two commits in contact, you get a conflict, because every commit changes
this line and both lines differ. This makes using git features like
rebase and merge harder.

> > +  * debian/jed-common.lintian-overrides: Add override for Lintian warning
> > +    about wrong spelling of XWINDOWS (this is a false positive, because
> > +    this word is a S-Lang keyword) [RL]
> > +  * debian/rules: Call dh_lintian for jed-common
> > +  * debian/control: Build-depend on debhelper >= 6.0.7, since this is the
> > +    version where dh_lintian appeared
> > +  * debian/compat: Bump debhelper compatibility level to 6
> > 
> > Is it really worth to mention the change in every file? Why not “Bumped
> > the debhelper compatibility level to 6 and added the version 6.0.7 in the
> > Build-Depends (BTW: You forgot the S) field to get support for
> > dh_lintian.” Maybe you can join the other messages, too.
> 
> It is a matter of style.  I prefer mine, because it is clear which files
> have been changed. However, as ususal, YMMV.

Yes. A short explanation of my point of view: Assumption, you make three
changes (1) bump the debhelper level, (2) add the lintian override and
(3) use a different feature from debhelper 6, e.g. comments in debhelper
files. The changes 2 and 3 depend on 1. Later, lintian get's magically
changed to no more warn about the XWINDOWS mistake. If you had split the
commits, you could simply use git revert and create a new commit that
reverts the change in 2 or you can drop this commit with git rebase. But
if you put the changes 1 and 2 in one commit, you can't revert them. You
must create a new commit to revert the change manually, because the part
for 1 must stay for 3.

Or if you would like to raise the debhelper level in a different branch,
too, but there isn't the mistake in the other branch. With two commits
you can reuse one of them. With only one commit you must create a new
commit.

But all this doesn't hit us here. These changes are to small.

And a new problem: The part of the README.Debian is already in jed_faq. I
forgot to remove it in version pre138-1. John added these questions in
pre136.

> BTW, I do not forgot the S in "Build-depend".  It is a verb.

You're right. I thought of the field in the control file.

> Thanks for the tutorial.  I will try the refs/heads/rl-0.99.19 option above,
> since this seems to interfere less with the way you are managing the
> repository at Alioth.

On suggestion: The first commit should not include the line with the
asterisk *, because it's a line that get's removed by the next commit. My
suggestion:

jed (1:0.99.19~pre143-2) UNRELEASED; urgency=low

 -- Rafael Laboissiere <rafael at debian.org>  Tue, 24 Jun 2008 13:46:05 +0200

Do “git rebase -i HEAD~2” in your branch, replace the first “pick” by
“edit”, when rebase stopps change the file and do “git commit -a
--amend”, then do “git rebase --continue”.

> > And can you include the fix for the rxvt problem?
> 
> What do you mean exactly?

The fix in the thread “what to do with rxvt-unicode terminfo bug”
started by Günter last week.

G. Milde schrieb am Wed 18. Jun, 15:51 (+0200):
> I use the following workaround in my ~/.jed/jed.rc
>
>   % fix rxvt-unicode bug (Debian bug #446444)
>   % resulting in inkonsistent keydef error
>   #ifndef XWINDOWS   
>   require("keydefs");
>   if (Key_Shift_Ins == "\e2$")
>      Key_Shift_Ins = "\e[2$";
>   #endif

> c) provide a fix, e.g. the above patch to /etc/jed.d/05jed-common.sl?

Regards, Jörg.

PS: Don't get a bad feeling from my pedantic manner and nitpicking. I
don't want to educate you but share my experiences.
-- 
Optimisten haben gar keine Ahnung von den freudigen Überraschungen, die
Pessimisten erleben.
	    	    				(Peter Bramm)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20080625/5eacf83e/attachment.pgp