Linda A. Walsh wrote:
> Eric Sandeen wrote:
>> Linda A. Walsh wrote:
>>> I can understand that for kernel work, but what about the xfs utils?
>> Again, just look at the git logs.
> I understand you want people to see the work that has gone into the
> kernel, but telling someone to search through 1327 entries just to find
> an answer of 'no', seems a bit ...something.
You originally asked, as far as I understood it, whether xfs can survive
if sgi does not.
I suggested that you read the list and look at the changelogs, and see
how much work is being done on xfs from -outside- sgi, as this may help
to answer your question.
> FWIW: I copied all 1327 entries to a text file and searched for
> any string "xfs[a-z]" to search for any comments about utility changes.
> Only strings found were for the daemons that are run.
> Now that I've determined that the xfs utils are not in the kernel
> source tree (I wouldn't have expected them to be), maybe I can more
> be less indirect and ask: Who is managing the the xfs_utils, Where are
> they kept and What is the procedure for trying to get changes (fixes
> or enhancements) to them? (I prefer direct questioning, but too many
> people, even in the engineering/sw community, find it rude or abrupt,
> so it's not usually my 1st choice).
Changes happen as they always have; patches are sent to the xfs
development mailing list. There are git trees on kernel.org as well as
on oss.sgi.com, though I'm not sure the exact details matter too
terribly much here. It all ultimately, eventually flows to a tarball on
> In other words, does one:
> (I) suggest new ideas and if the keeper(s) likes them, they are
> implemented and redistributed?
You could try that, though there is always the resource issue. Many
people are full of good ideas; fewer people can implement them :)
> (II.1) suggest new ideas and see if keeper(s) approve of 'project' so
> one can then go and
> (i) implement the changes in a local version, and then?
> (a) check them in?
no, you can't check them in upstream, the maintainers do that ...
> (b) submit for approval so they can be approved for
> inclusion (or fixing any found problems)
yes, send them to the list as has always been done.
> (III) just go off and implement the code, then come back and say, hey,
> here are my changes for this idea, and just expect to be greeted
> with open arms? ;^/
subject to review of course. It'd always be better to float the plan on
the list first before you go off and do a bunch of work.
> (I hope I got the indentation and syntax correct in that, English
> syntax isn't always the easiest language to express nested options
> I'm trying to get clear on process. If they are in the kernel
> tree, there may be no way for me to get from A->B, othewise, I'm
> trying to find out where one might have hope of bouncing ideas that
> might get implemented or that if sufficiently positively received
> might spure someone to try implementing the changes themselves (and
> possibly (and possibly get in completely over their head....or not.)
Basically, everything starts on the list, and ends in the git trees or
tarballs. This will continue to be true even if, for any reason, sgi
were to disappear, we'd just have potentially new URLs and fewer resources.