Re: Homepage-field in description
On 6/15/06, Don Armstrong <don@debian.org> wrote:
> That is a point, but still the users might find the link useful.
> Also, checking if something fresher is present is in upstream could
> be facilitated because there is no need to look for the copyright
> file and ge the info from there.
This problem is solved by watch files and similar, not the copyright
file or any other field in control.
Err, I was afraid someone will say that, but sometimes (I have such a
package), the upstream has a sane work flow with a stable branch and a
development branch. I don't think is a sane approach to have the watch
file detect development releases, but it might be useful to have that
info from a developer POV so he/she can make experimental packages in
case major chnages occured, so the release lag for the new stable
version is as small as possible.
(see more arguments below for watch file and users)
There are also some cases when the homepage will provide new auxiliary
tools which are releated to the old product. This info can't be parsed
by any parser.
BTW, the watch file links to the download page, that is not
necessarily the same as the homepage (quite frequent - see
sourceforge).
> If the info is present in the copyright file, why isn't it parsed
> automaticaly to be displayed on the package page?
It's available in the copyright file which is linked there; feel free
to write a parser to pull it out of the free form copyright field...
it shouldn't be too difficult to get the majority of upstream pages
that way.
Free form fields are a pain to parse, everbody knows that. That's why
a Homepage: field would be preferrable.
> Still I don't understand why is this reservation towards providing a
> Homepage link (even if via a new Homepage field in the control
> file)?!
If a maintainer has a problem with including it, then perhaps they
know best? If it makes sense, maintainers will include it. If not,
they won't.
I have heard one too many times about others knowing what's best for
me. My general feeling was that most maintainers do what they think is
good for them as maintainers and leave to the end what is good for
users (probably not intentional, in most cases, but still in that
order). Look at most of the arguments here:
- "is in the copyright", the average user does not care about
copyright and they certainly will not go leaps and bounds to get to
that information (may I add that the place is non-obvious for a
user?);
- "wastes bandwidth" - Who cares about that? Most probably not the
users. I am not ignorant about the space/bandwidth problem, but that
is not a _user_ concern. Also the supplemental bytes are not going to
make a difference[1]
- "the information in the description must be short" - exactly, that
info is short, so the user might obtain close to 0 information, he
_will_need_ the homepage link to decide about the package if is the
right thing for him/her
- "the new versions are detected via the watch file" - how many users
know about the watch file? How many of them even care and know how to
get to that info on p.q.d.o?
> Exactly, that's why Debian shoudl link to the upstream. Think from a
> user POV, not from a Debian maintainer's view.
We may want to link to upstream, but it's possible that the extra
information that you're asking for has no place in the control file
which serves a totally separate purpose.
The point is to have Homepage: information for all packages which have one.
I don't know who is working on packages.debian.org right now, but
there's nothing stoping you from expanding the codebase to allow user
contributions of links and screenshots that are kept with the packages
(or even just linking directly to the proper freshmeat.net package
page.)
Not everybody announces their projects on freshmeat. I never look at that site.
Just check out the codebase and do it; blocking on maintainers to see
things your way when it isn't necessary to acomplish the things that
you want to do is just a path to frustration of everyone involved.
Yes, Debian, like all big comunities has became a big thing with a
huge inertia, just for historical reasons.
This discussion about creating the infrastructure for a thing which is
not mentioned in the policy has occured before, but it has been proven
(see the current Homepage: meta field parsing) inefficient, because as
long is not enforced by the policy most maintaners will just ignore
that.
[1] iirc, Daniel J. Bernstein has a paper on e-mail bandwidth
reduction by shortening the fields names in the SMTP protocol (e.g.:
F: instead of From:, R: instead of Reply-to: and so on); at an extreme
Debian could approach the control field in a simillar manner (e.g.: D:
for Depends:, R: instead of Recomends:, and so on) and reduce the
bandwidth and storage space.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: