Re: sponsor and advocate wanted
On Tue, 2002-06-25 at 11:06, Ben Armstrong wrote:
> On Tue, Jun 25, 2002 at 02:01:46PM -0300, Ben Armstrong wrote:
> > On Thu, Jun 20, 2002 at 09:24:27PM -0700, Kristis Makris wrote:
> > > tkxcd - a diff front end with a look and feel based on Atria Clearcase
> > > xcleardiff. Similar to tkdiff. Outdated, but upstream has a much
> > > improved version that I'm pushing him to formally release.
> >
> > This one looks interesting. I'm taking a look right now.
Hi Ben, thanks for your comments and time.
> Never having seen Atria Clearcase xcleardiff, I don't know how close this
> utility comes to its look and feel. However, comparing it to tkdiff and
Neither do i.
> xxdiff, I don't see anything in this package that would recommend it above
> these more mature visual diff programs already in Debian. Can you help me
> out here? Have I missed some obvious advantage that tkxcd has over tkdiff
> and xxdiff?
The newer version that I'd like to see the upstream release allows
displaying two files one below the other, rather than left and right. I
found no way to do this in tkdiff or xxdiff, if there is one, and is the
main reason I use tkxcd.
> Moving along to some general observations about your packaging:
>
> - You include ./debian/menu, but it does not work because arguments must be
> provided to the command. Therefore you should remove it. You can add it
> back later if/when tkxcd supports being started with no arguments.
>
> - Why do you depend on tk8.0 in particular? That is a bit dated. Will
> tk8.3 not work? If more recent versions work, specify a dependency
> on tk8.3 or earlier versions with: Depends: tk8.3 | wish
As a matter of fact the minimum requirement is tk4.1. How can I express
that since there's no tk4.7 package in woody? Should I simply set a
Depends: wish ? How can the package also be installed on older Debian
systems (e.g. potato) where tk4.1 is available? I understand that it
cannot be officially part of potato now, but I'd still like to have the
option of installing it on an older Debian. If I recall correctly
dpkg-buildpackage (or lintian) complained that there's no package called
tk4.1
> - You make the package priority "optional". I would say "extra", given
> that tkdiff and xxdiff both already provide more functionality than tkxcd.
>
> - The URL you give in copyright gives me a 404. Is there a new home page
> for tkxcd?
I'm waiting for upstream to make a new one, along with releasing the
latest version.
> - You unnecessarily create /usr/sbin in the deb because you did not delete
> it from ./debian/dirs (dh_make put it there).
>
> - You unnecessarily leave in unused and/or commented-out dh_* routines
> in your ./debian/rules file. Find the ones that aren't needed and
> delete them, thereby improving readability of the makefile.
>
> - Similarly, configure & configure-stamp do nothing. Eliminate these
> targets and all references to them.
>
> - Under build (which is mandatory) you do nothing. Instead of leaving
> dh_make's comment in, you might replace it with a comment simply stating
> that tkxcd has nothing to build.
>
> - The DEB_HOST_*_TYPE variables are not needed. Neither are the
> DEB_BUILD_OPTIONS if statments that set switches that would only
> be used during building & installing a binary program, which you
> don't do.
>
> - You include TODO in ./debian/docs but not README. Why not? Yes, I
> can see README contains some install notes, but it also has valuable
> user information in it not also in the man page (see the "Bug Reports"
> section at bottom). Including a README with install notes in it is
> not without precedent in Debian. I see it all the time, and for
> similar reasons as in this case: after the install notes often comes
> some valuable information for the end user.
>
> And finally some comments about the program itself:
>
> - I found tkxcd segfaulted and core-dumped on me upon reaching the bottom of
> a file which ended with trailing nulls (an artefact of copying the files
> over SMB from a Pathworks server)
>
> - When advancing from one diff to the next, and both differences are visible
> in the same screenful, the window does not advance, nor is there any
> visible indicator that we are now viewing the next difference section.
> This has the "feel" of being broken. When I press a button, I expect
> something to happen visibly.
>
> - Providing a '-rcs' switch is a nice touch, but nothing new, since tkdiff
> provides this, and more. Tkdiff will also do cvs, which is far more
> common than rcs these days anyway. (Yes, I know you warned that the
> package was out of date.) I did not test the -rcs switch, so I can't
> say whether it works as advertised.
>
> I have only looked at this packages as it is the only one that interested me
> personally. Perhaps this was an early attempt and you have since learned to
> make more polished packages. If you want to make a good impression on a
> would-be sponsor or advocate, my principal advice to you is to pay careful
> attention to the stuff that dh_make automatically adds for you and make sure
> all the rough edges are gone before you announce your package to the world.
Thanks again for all your comments.
I would claim that most of my decisions during packaging where results
of having a hard time finding clear documentation in either a detailed
or "Guide" style. I've found the NM's Guide to lack a lot of
clarifications on even mere mentioning of certain features/techniques
used in packaging. I had been looking for "The Packaging Manual" for a
long time, after seeing it casually referenced by other documents,
lintian, but never the NM Guide, and to this date I do not know which
package provides that, even though google spit back a link to it. I'm
frustrated with the documentation in general, and I do firmly believe in
rtfm.
What is the proposed way of handling RFPs or ITPs? Are all the packages
listed there first examined for their feature set and accepted/rejected
as being possible Debian package candidates? (or should they be)? If
there is (or was) such a process it could possibly save maintainers time
packaging software that is not generally liked.
> If there is another package you have made that shows off your packaging
> skills better, perhaps you could let us know so we could better assess your
> abilities.
xsb received most of my packaging attention. I'm waiting for an official
2.6 release from upstream before I continue with it.
Thanks,
Kristis
--
To UNSUBSCRIBE, email to debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: