On 04/26/2010 12:46 PM, Mike Frysinger wrote:
On Monday 26 April 2010 11:12:40 Chuck Lever wrote:
However, as soon as a distributor sends patches (rather than, say,
> simply posting a bug report), you become a developer, and are thus
> obligated to act like one by reviewing the content of the local source
> management system before making changes, and by posting your patches to
> this list for us to review.
expecting anyone who sends a patch to be fully versed in NFS internals and the
full history is completely unreasonable.
I didn't say "anyone." We were specifically discussing distributors,
and specifically distributors that regularly send patches.
i'm not saying people shouldnt do a
little research here, but your position appears to be poor: if you want nfs-
utils info, regardless of who you are, you must go to the scm source and dive
through mounds of history and divine the answer yourself.
That's not my position at all. After you claimed the ChangeLog is not
kept updated, I merely observed that ChangeLog information is available
in the git log, and on the web. Asking the maintainer to copy the git
log into the ChangeLog during every release for tarball users is
perfectly reasonable.
> > people attempting to package nfs-
> > utils shouldnt need to crawl these backends to try and glean info
> > themselves.
>
> As I pointed out, you don't need git on your local system to look at
> this metadata: it's already available on linux-nfs.org if you have a web
> browser.
the interface is irrelevant -- you're still saying people have to dig through
piles of information that is not relevant to packaging.
Have you looked at the output of git log? It's basically the same
content as the ChangeLog file, up to 2006. It's exactly the information
you were asking for.
> >> Patches are posted on this mailing list for review before they are
> >> committed. Anyone has a chance to object, comment, or suggest a simpler
> >> way to do things.
> >
> > again, this isnt relevant to distro maintainers.
>
> How are nfs-utils developers supposed to know of a problem if distro
> maintainers don't tell us?
you're saying distro maintainers are expected to subscribe to the development
list and review patches ? that's bunk.
Anyone who is a regular contributor should subscribe to the mailing list
and review patches they care about to stay up to date. If you happen to
choose not to do that, then you really shouldn't be surprised when asked
to provide more detail on a patch, or to follow the normal patch
submission rules.
If you are a distro maintainer, you can either report problems to us,
ask for new features, or post patches. As a maintainer, if you want to
post a lot of patches, you should follow the patch submission rules the
rest of us are beholden to. That's only fair to the rest of us, and it
means we can do a better job reviewing everyone's changes. How is that
unreasonable?
I claim that "things" did not work. When statd was shut down, it left a
dangling rpcbind registration, and that's a bug in all environments.
perhaps, but some people are ok with that. considering that has always been
the behavior then, ive never seen one complaint about this via Gentoo. clear
documentation explaining the tradeoffs would be sufficient and there are
plenty of systems where this bug is meaningless. on my nfs servers, either
everything is up, or everything is down. there is no "in between" where some
services are left running while others are not.
My point is that explanation should have been included in the patch
description at the very beginning, because you should realize that not
everyone else is served by your changes, either, and many of us don't
run Gentoo and would not have known the details of your server
configuration.
So, why do you want to make libcap optional?
there are plenty of systems where privileges are meaningless (like
embedded) and so libcap is pure cruft.
In that case, your patch description should explain that so we can
understand why you've added another --enable switch. These switches are
overused, so a clear rationalization is needed when adding yet another.
By and large, those who participate on this list felt that "--enable"
flags are less desirable than automatic feature checking. Your view is
novel, I think.
the view of distro maintainers in this regard matters more than that of
developers. the configure script is designed for the end packagers to use,
not developers. my position here is not unique to me or something i pulled
out of nowhere.
It may be true that maintainers care more about the configure script
than developers, but none of those maintainers were here to express that
opinion or comment on any patches that changed the configure script.
Basically, how are we supposed to know your opinions if you refuse to
participate?
--
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
