> I'm now preparing for providing crash-gcore-command and
> crash-trace-command packages in Fedora, which has been provided in
> RHEL only so far.
>
> Relevant to that, I'd like to talk about extensions/trace.c about
> maintaining it in another independent git repository. Is it possible?
> Having independent repository is useful to control versions between
> upstream's and distribution's.
I think it would be better.
But the official maintainer doesn't respond for some time.
If we make it independent, I don't want to leave it unclear.
Do you mean that Fujitsu folks will maintain the trace.c? :)
Yes. I'll do it. Please update the maintainer name of trace.c
in
https://crash-utility.github.io/extensions.html.
> I'm now also attempting to put the git repository for crash gcore
> command in public, that has been managed locally in our company in
> private. Is it possible to move it under crash utility project,
>
https://github.com/crash-utility
crash-utility ・ GitHub
crash-utility has 4 repositories available. Follow their code on GitHub.
github.com
, like crash-utility/gcore or
> crash-utility/extension-gcore?
Hmm, what are the merits of having the gcore repository?
Another candidate for me is to put it at Fujitsu's public location:
https://github.com/fujitsu. But our Fujitsu's project has no sense
of unity on the provided repos. So I just simply think it's natural
to put it under crash utility's official project first.
If it's impossible, I'll put it at
https://github.com/fujitsu,
maybe together with trace.c's.
Bhupesh, Lianbo, what do you think?
If we have an extension repository in the crash utility project,
I think we should decide first what kind of extensions we have.
Because probably we cannot accept all extensions that want to
come in. If we have one and its maintainer becomes unresponsive
like trace.c, what will happen?
Sorry for the situation. That's the fact that there's virtually
no maintainer and contributions for trace.c in Fujitsu
in some period. I'll improve the situation in this opportunity.
maybe needless concern?
Thanks.
HATAYAMA, Daisuke