RFU jed 1:0.99.19~pre143-1
Jörg Sommer
joerg at alea.gnuu.de
Wed Jun 25 07:43:52 UTC 2008
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
More information about the Pkg-jed-devel
mailing list