Am 21.03.2006 um 02:45 schrieb Alexander K. Hansen:
[...]
I think we can all agree that fixing typos requires no particular
expertise with the package in question (and saves the maintainer from
being inundated with messages about the problem).
Indeed, fully agreed.
That is, as long as the person making the fix makes sure to apply it
to all versions of a given package. It can be quite annoying to
discover (or rather, not discover) that your 10.4 main package has
been fixed while the version in the 10.3 tree / in the 10.4 crypto
tree has not been fixed :-/
Changing a package for architecture-specific reasons is more
problematic, I agree. Since the 10.4 source distro is set up to work
jointly for Intel and PPC, we don't have the option for maintainers
only to maintain for one or the other.
Indeed. And while I am glad if people fix compilation of my stuff on
Intel, I would at least be able to understand why a change was
necessary. Hence, I'd like to get a mail, and ideally such changes
should also be documented in DescPackaging/DescPort.
Here's the issue as I see it: when there's a problem with a package
and the maintainer doesn't respond in a timely manner it's frustrating
for the users. They take it out on the general lists.
The first item I mentioned is clear-cut in that regard: there's a
problem whose solution is readily apparent. Why not have some
qualified party make the change quickly so that the package actually
builds?
I am skeptical about that. What makes somebody a "qualified party",
exactly? Plus, why can't that "qualified party" make the fix, then
mail the patched .info file(s) to both the user with a problem, for
testing ("Does this solve your problem?"), *and* to the package
maintainer, for review?
Furthermore, do we really want to let ourselves be blackmailed by
users who complain about bad support just because they didn't receive
help after a couple hours?
We have two main support channels: The maintainer, and the fink
mailing lists. If a user discusses my packages on fink-users, then
unfortunately, I have no easy way of knowing (subscribing to that
list is not an option for me anymore, sorry). However, if it is
determined there that a change is required, it is usually sufficient
to forward this to the maintainer. Do you really think the delay
caused by this alienates users? After all, the solution was already
explained there, and if a modified .info file is required, you can
send it to them already, even before the maintainer checked in the file.
The second channel is direct contact with the maintainer. If I get a
report directly sent to me via email, then I try to resolve it
quickly (usually it's done by just pointing them to the FAQ). Build
issues I fix or tell them when I will fix 'em. For Intel problems,
currently I am telling them that I can't help since I have no Intel
system. For the latter, it would indeed be nice if there was an
official channel to whom to delegate such problems. However, I still
would want that I am informed about the required changes.
If you think that you absolutely *must* checkin a fix immediately
(e.g. because the old version of the package can cause system files
to be deleted), then still, I think the maintainer should at least be
notified! Anything else is untenable IMHO.
The second item is more difficult. If the maintainer has responded to
the user in a timely manner and forwarded the message on to -devel (or
possibly we need an intel-specific list) saying that they don't own an
Intel Mac to verify a problem, then they're at engaged in the process,
and any change should be made with their approval. If they just send
a message to the user saying "sorry, I don't do Intel" and leave it at
that, or don't bother to respond at all, then in my view they've
abrogated their right to gripe about changes made that don't break
things on PowerPC.
Well, in my eyes, those "rights" were already severely cut when those
packages where moved to the intel tree, without the maintainers being
involved in anyway. Again, I understand the logistic reasons for
this. But: by this process, the packages were marked (in the eyes of
the users that will vent their frustration to the general lists or by
emailing the maintainer) as ready for usage on Intel -- even though
those packages in some cases don't work (yet) at all, may not even
compile. After getting the tenth mail complaining about the package
being broken on intel, a package maintainer IMO is entitled to feel
frustration, too, don't you think? And write according replys.
Hence, I wouldn't be so rash with disowning us. But if you think
that's the right way, then we must add a way to make maintainers arch
specific.
Bye,
Max
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
