5:26 a.m.
Hagio-san,
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'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, like crash-utility/gcore or
crash-utility/extension-gcore?
Thanks.
HATAYAMA, Daisuke
6:55 p.m.
Hi Hatayama-san, Bhupesh, Lianbo,
-----Original Message-----
Hagio-san,
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? :)
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, like crash-utility/gcore or
crash-utility/extension-gcore?
Hmm, what are the merits of having the gcore repository?
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?
maybe needless concern?
Thanks,
Kazu
3:22 a.m.
> 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
7:49 p.m.
Hagio san,
> > 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.
So, is it OK to think that you have accepted to make another git
repository of trace.c? If so, I'll next make it actually and then
inform of it to you later.
Thanks.
HATAYAMA, Daisuke
12:19 a.m.
Hi Hatayama-san, Lianbo, Bhupesh,
Lianbo, thanks for your thoughts, I think we agree.
Bhupesh, if you have any concerns from Red Hat's view point,
please let us know.
On Mon, Dec 28, 2020 at 10:52 AM d.hatayama(a)fujitsu.com
<d.hatayama(a)fujitsu.com> wrote:
Hagio san,
> > > 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.
That's great!
So, is it OK to think that you have accepted to make another git
repository of trace.c? If so, I'll next make it actually and then
inform of it to you later.
Yes, please proceed.
After that, we will need to do some changes, e.g. remove extensions/trace.c
from the crash repository and modify related parts.
As for moving the extension repositories into the crash utility project, I also
don't think it's preferable, because to have an extension's repository might
imply some responsibility for it. We provide the extension modules page [1]
for them, but are not going to broaden the scope for now.
[1] https://crash-utility.github.io/extensions.html
Thanks,
Kazu
10:44 p.m.
For preparing git repos for crash-gcore and crash-trace command,
I'm working now but a little delayed. Please wait for some more time.
Thanks.
HATAYAMA, Daisuke
________________________________________
From: crash-utility-bounces(a)redhat.com <crash-utility-bounces(a)redhat.com> on behalf
of Kazuhito Hagio <kazuhito.hagio(a)gmail.com>
Sent: Tuesday, December 29, 2020 15:19
To: Discussion list for crash utility usage, maintenance and development
Cc: Mizuma, Masayoshi/水間 理仁; lijiang
Subject: Re: [Crash-utility] git repositories for gcore/trace commands under crash-utility
project
Hi Hatayama-san, Lianbo, Bhupesh,
Lianbo, thanks for your thoughts, I think we agree.
Bhupesh, if you have any concerns from Red Hat's view point,
please let us know.
On Mon, Dec 28, 2020 at 10:52 AM d.hatayama(a)fujitsu.com
<d.hatayama(a)fujitsu.com> wrote:
Hagio san,
> > > 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.
That's great!
So, is it OK to think that you have accepted to make another git
repository of trace.c? If so, I'll next make it actually and then
inform of it to you later.
Yes, please proceed.
After that, we will need to do some changes, e.g. remove extensions/trace.c
from the crash repository and modify related parts.
As for moving the extension repositories into the crash utility project, I also
don't think it's preferable, because to have an extension's repository might
imply some responsibility for it. We provide the extension modules page [1]
for them, but are not going to broaden the scope for now.
[1] https://crash-utility.github.io/extensions.html
Thanks,
Kazu
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
2 a.m.
Hi, Hagio, Lianbo,
Sent: Thursday, January 21, 2021 13:44
For preparing git repos for crash-gcore and crash-trace command,
I'm working now but a little delayed. Please wait for some more time.
Sorry for the late notification.
I created the git repos as follows:
https://github.com/fujitsu/crash-gcore
https://github.com/fujitsu/crash-trace
Some notes for crash-trace:
- I created the repo for crash-trace based on commits on extnesions/trace.c
from https://github.com/crash-utility/crash.
- I gave the current latest of crash-trace v3.0 because although the RHEL8
version of crash-trace-command is v2.x, the current latest is not identical
with the RHEL8 version... It's for consistency.
Please also note that from our internal reasons, I don't update
the two repos for some more days, don't respond to any pull-requests, and so
issue feature is being disabled for the time being.
Please wait for a while until our preparation is fully done...
Hagio-san, could you update descriptions for gcore.c and trace.c in
https://crash-utility.github.io/extensions.html accordingly?
Thanks.
HATAYAMA, Daisuke
11:40 p.m.
Hi Hatayama-san,
-----Original Message-----
Hi, Hagio, Lianbo,
> Sent: Thursday, January 21, 2021 13:44
> For preparing git repos for crash-gcore and crash-trace command,
> I'm working now but a little delayed. Please wait for some more time.
Sorry for the late notification.
I created the git repos as follows:
https://github.com/fujitsu/crash-gcore
https://github.com/fujitsu/crash-trace
Some notes for crash-trace:
- I created the repo for crash-trace based on commits on extnesions/trace.c
from https://github.com/crash-utility/crash.
- I gave the current latest of crash-trace v3.0 because although the RHEL8
version of crash-trace-command is v2.x, the current latest is not identical
with the RHEL8 version... It's for consistency.
Please also note that from our internal reasons, I don't update
the two repos for some more days, don't respond to any pull-requests, and so
issue feature is being disabled for the time being.
Please wait for a while until our preparation is fully done...
Hagio-san, could you update descriptions for gcore.c and trace.c in
https://crash-utility.github.io/extensions.html accordingly?
Thank you for creating the repositories, updated the descriptions.
We will remove extensions/trace.c from the crash repository later.
Thanks,
Kazu
4:47 a.m.
Hagio-san,
> Hagio-san, could you update descriptions for gcore.c and trace.c
in
> https://crash-utility.github.io/extensions.html accordingly?
Thank you for creating the repositories, updated the descriptions.
We will remove extensions/trace.c from the crash repository later.
Thanks for your handling.
I confirmed that the new links are working as expected.
By the way, during this confirmation, I got aware of the fact that we
would need to repeat this in the next release as well because the description
of crash gcore command includes its version information... To simplify
this, how about just pointing at the URLs for the latest releases below?
https://github.com/fujitsu/crash-gcore/releases/latest
https://github.com/fujitsu/crash-trace/releases/latest
and then replacing all the crash-gcore-command-1.6.1.tar.gz by
crash-gcore-command-<version>.tar.gz.
Thanks.
HATAYAMA, Daisuke
________________________________________
From: HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
Sent: Monday, February 8, 2021 14:40
To: Hatayama, Daisuke/畑山 大輔; 'lijiang'
Cc: Mizuma, Masayoshi/水間 理仁; Discussion list for crash utility usage, maintenance and
development
Subject: RE: [Crash-utility] git repositories for gcore/trace commands under crash-utility
project
Hi Hatayama-san,
-----Original Message-----
Hi, Hagio, Lianbo,
> Sent: Thursday, January 21, 2021 13:44
> For preparing git repos for crash-gcore and crash-trace command,
> I'm working now but a little delayed. Please wait for some more time.
Sorry for the late notification.
I created the git repos as follows:
https://github.com/fujitsu/crash-gcore
https://github.com/fujitsu/crash-trace
Some notes for crash-trace:
- I created the repo for crash-trace based on commits on extnesions/trace.c
from https://github.com/crash-utility/crash.
- I gave the current latest of crash-trace v3.0 because although the RHEL8
version of crash-trace-command is v2.x, the current latest is not identical
with the RHEL8 version... It's for consistency.
Please also note that from our internal reasons, I don't update
the two repos for some more days, don't respond to any pull-requests, and so
issue feature is being disabled for the time being.
Please wait for a while until our preparation is fully done...
Hagio-san, could you update descriptions for gcore.c and trace.c in
https://crash-utility.github.io/extensions.html accordingly?
Thank you for creating the repositories, updated the descriptions.
We will remove extensions/trace.c from the crash repository later.
Thanks,
Kazu
6:09 p.m.
-----Original Message-----
By the way, during this confirmation, I got aware of the fact that
we
would need to repeat this in the next release as well because the description
of crash gcore command includes its version information... To simplify
this, how about just pointing at the URLs for the latest releases below?
https://github.com/fujitsu/crash-gcore/releases/latest
https://github.com/fujitsu/crash-trace/releases/latest
and then replacing all the crash-gcore-command-1.6.1.tar.gz by
crash-gcore-command-<version>.tar.gz.
That's helpful, updated. Could you check the page again?
Thanks,
Kazu
1:05 a.m.
-----Original Message-----
> By the way, during this confirmation, I got aware of the fact that we
> would need to repeat this in the next release as well because the description
> of crash gcore command includes its version information... To simplify
> this, how about just pointing at the URLs for the latest releases below?
>
> https://github.com/fujitsu/crash-gcore/releases/latest
> https://github.com/fujitsu/crash-trace/releases/latest
>
> and then replacing all the crash-gcore-command-1.6.1.tar.gz by
> crash-gcore-command-<version>.tar.gz.
That's helpful, updated. Could you check the page again?
Thanks for your handling. I confirmed that's updated as I expected.
Thanks.
HATAYAMA, Daisuke
2:08 a.m.
在 2020年12月25日 08:55, HAGIO KAZUHITO(萩尾 一仁) 写道:
Hi Hatayama-san, Bhupesh, Lianbo,
-----Original Message-----
> Hagio-san,
>
> 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?
This should be good to maintain it in another git repository separately.
> Having independent repository is useful to control versions
between
> upstream's and distribution's.
Seems doable. For example:
[1] In the distribution, when build a rpm package, it also can build several
related subpackages at the same time. The crash extension modules can be put
into the distribution for crash-utility as subpackages. But do not add them
into the crash-utility in upstream.
[2] When backport a patch from upstream to distribution, people can easily find
out the commit from upstream git repository and apply it to distribution, no need
to update the tarball.
It is convenient to maintain the git repository in upstream and also for distribution.
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? :)
Sound good.
> 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, like crash-utility/gcore or
> crash-utility/extension-gcore?
I would not recommend moving it under crash utility project, and probably
the additional extension modules won't be accepted any more in the future.
Hmm, what are the merits of having the gcore repository?
It is easier to maintain the source code than the tarball. And this is also
helpful to the distribution.
Bhupesh, Lianbo, what do you think?
Please see above input. Thanks.
Lianbo
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?
maybe needless concern?
Thanks,
Kazu
1414
days inactive
1467
days old
devel@lists.crash-utility.osci.io
11 comments
4 participants
participants (4)
-
d.hatayama＠fujitsu.com -
HAGIO KAZUHITO(萩尾 一仁) -
Kazuhito Hagio -
lijiang