On 3/20/06, Max Horn <[EMAIL PROTECTED]> wrote: > > Am 19.03.2006 um 23:10 schrieb Trevor Harmon: > > > On Mar 19, 2006, at 1:04 PM, Benjamin Reed wrote: > > [...] > > > > >> It makes > >> sense to, by default, defer to the person who understands that > >> software > >> well enough to package it, when questions arise. > > > > But this can still be the default in the model I propose. And as > > you said in your response to Max, sometimes changes are so trivial > > that there's no need to defer to the original maintainer. > > That's debatable. Sometimes you *think* the change is trivial, > precisely because you are not intimately aware of all the subtle > aspects of a given package. > > Anyway, to me "maintainership" for Fink packages was always very > close to that in Debian: It's not all "for life", but rather, the > maintainer is the single person who feel responsible for taking care > of a given package. He coordinates all changes made to the package. > He's the "expert" for it. And if he lacks time or interest, he hands > over this position to another maintainer. If other people discover > bugs or problems in the package, they report them to the maintainer, > possibly including a patch/fix, which the maintainer reviews and > incorporates into the package. > > -> that's what my understanding of the role of a maintainer was so > far, and I think it's rather close to what Debian does, though I am > not really sure if that claim is true :-). > > > Cheers, > Max > >
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). 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. 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? 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. -- Alexander K. Hansen Fink Documenter [Day Job] Levitated Dipole Experiment http://psfcwww2.psfc.mit.edu/ldx/ ------------------------------------------------------- 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&kid0944&bid$1720&dat1642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
