Request for setup of new repositories
Hi Jaroslav, Iwai-san,
Thanks for your maintenance for alsa-project organization in github.com. Currently I'd like to add new three repositories under the organization as a part of my work for ALSA firewire stack.
I've been maintaining libhinawa since 2014 and recently realized that current design is not necessarily convenient since it includes two functions; operation to Linux FireWire cdev, and operation of ALSA HwDep cdev. Currently I'm working for new library to split the latter operation. Then I'd like you to setup below repositories:
* 'libhitaki' * 'libhitaki-doc' * 'hitaki-rs'
The library itself and its Rust binding are utilized by 'snd-firewire-ctl-services'[2], thus it's preferable to register them under 'GObject Introspection' Team.
Thanks for your assist for my work.
[1] https://github.com/alsa-project/libhinawa [2] https://github.com/alsa-project/snd-firewire-ctl-services
Regards
Takashi Sakamoto
On 25. 04. 22 15:20, Takashi Sakamoto wrote:
Hi Jaroslav, Iwai-san,
Thanks for your maintenance for alsa-project organization in github.com. Currently I'd like to add new three repositories under the organization as a part of my work for ALSA firewire stack.
I've been maintaining libhinawa since 2014 and recently realized that current design is not necessarily convenient since it includes two functions; operation to Linux FireWire cdev, and operation of ALSA HwDep cdev. Currently I'm working for new library to split the latter operation. Then I'd like you to setup below repositories:
- 'libhitaki'
- 'libhitaki-doc'
- 'hitaki-rs'
The library itself and its Rust binding are utilized by 'snd-firewire-ctl-services'[2], thus it's preferable to register them under 'GObject Introspection' Team.
Thanks for your assist for my work.
Hi Takashi,
All is set on github. Let me know, if you need other changes.
Jaroslav
Hi Jaroslav,
On Tue, Apr 26, 2022 at 09:23:38AM +0200, Jaroslav Kysela wrote:
On 25. 04. 22 15:20, Takashi Sakamoto wrote:
Hi Jaroslav, Iwai-san,
Thanks for your maintenance for alsa-project organization in github.com. Currently I'd like to add new three repositories under the organization as a part of my work for ALSA firewire stack.
I've been maintaining libhinawa since 2014 and recently realized that current design is not necessarily convenient since it includes two functions; operation to Linux FireWire cdev, and operation of ALSA HwDep cdev. Currently I'm working for new library to split the latter operation. Then I'd like you to setup below repositories:
- 'libhitaki'
- 'libhitaki-doc'
- 'hitaki-rs'
The library itself and its Rust binding are utilized by 'snd-firewire-ctl-services'[2], thus it's preferable to register them under 'GObject Introspection' Team.
Thanks for your assist for my work.
Hi Takashi,
All is set on github. Let me know, if you need other changes.
Thanks for your arrangement. At present, I have no with for additional changes.
However for settings of libhinwa repository, I'd like you to change URL of documentation. We can see it in right side of top page.
* https://github.com/alsa-project/libhinawa
Currently it points to 'https://takaswie.github.io/libhinawa-docs/' while it should be 'https://alsa-project.github.io/libhinawa-docs/'.
Regards
Takashi Sakamoto
Hi Jaroslav,
On Tue, Apr 26, 2022 at 08:38:46PM +0900, Takashi Sakamoto wrote:
Hi Jaroslav,
On Tue, Apr 26, 2022 at 09:23:38AM +0200, Jaroslav Kysela wrote:
On 25. 04. 22 15:20, Takashi Sakamoto wrote:
Hi Jaroslav, Iwai-san,
Thanks for your maintenance for alsa-project organization in github.com. Currently I'd like to add new three repositories under the organization as a part of my work for ALSA firewire stack.
I've been maintaining libhinawa since 2014 and recently realized that current design is not necessarily convenient since it includes two functions; operation to Linux FireWire cdev, and operation of ALSA HwDep cdev. Currently I'm working for new library to split the latter operation. Then I'd like you to setup below repositories:
- 'libhitaki'
- 'libhitaki-doc'
- 'hitaki-rs'
The library itself and its Rust binding are utilized by 'snd-firewire-ctl-services'[2], thus it's preferable to register them under 'GObject Introspection' Team.
Thanks for your assist for my work.
Hi Takashi,
All is set on github. Let me know, if you need other changes.
Thanks for your arrangement. At present, I have no with for additional changes.
However for settings of libhinwa repository, I'd like you to change URL of documentation. We can see it in right side of top page.
Currently it points to 'https://takaswie.github.io/libhinawa-docs/' while it should be 'https://alsa-project.github.io/libhinawa-docs/'.
Additionally today I push documentation for libhitaki into the added repository:
* https://github.com/alsa-project/libhitaki-doc
I expect Github Pages makes association between the content and publish URI:
* https://alsa-project.github.io/libhitaki-doc
However it doesn't. I think we have missing configuration. Would I ask you to change settings following to this instruction?
https://docs.github.com/en/pages/getting-started-with-github-pages/configuri...
Regards
Takashi Sakamoto
Hi Jaroslav,
On Fri, Apr 29, 2022 at 11:29:22AM +0900, Takashi Sakamoto wrote:
Hi Jaroslav,
On Tue, Apr 26, 2022 at 08:38:46PM +0900, Takashi Sakamoto wrote:
Hi Jaroslav,
On Tue, Apr 26, 2022 at 09:23:38AM +0200, Jaroslav Kysela wrote:
On 25. 04. 22 15:20, Takashi Sakamoto wrote:
Hi Jaroslav, Iwai-san,
Thanks for your maintenance for alsa-project organization in github.com. Currently I'd like to add new three repositories under the organization as a part of my work for ALSA firewire stack.
I've been maintaining libhinawa since 2014 and recently realized that current design is not necessarily convenient since it includes two functions; operation to Linux FireWire cdev, and operation of ALSA HwDep cdev. Currently I'm working for new library to split the latter operation. Then I'd like you to setup below repositories:
- 'libhitaki'
- 'libhitaki-doc'
- 'hitaki-rs'
The library itself and its Rust binding are utilized by 'snd-firewire-ctl-services'[2], thus it's preferable to register them under 'GObject Introspection' Team.
Thanks for your assist for my work.
Hi Takashi,
All is set on github. Let me know, if you need other changes.
Thanks for your arrangement. At present, I have no with for additional changes.
However for settings of libhinwa repository, I'd like you to change URL of documentation. We can see it in right side of top page.
Currently it points to 'https://takaswie.github.io/libhinawa-docs/' while it should be 'https://alsa-project.github.io/libhinawa-docs/'.
Additionally today I push documentation for libhitaki into the added repository:
I expect Github Pages makes association between the content and publish URI:
However it doesn't. I think we have missing configuration. Would I ask you to change settings following to this instruction?
https://docs.github.com/en/pages/getting-started-with-github-pages/configuri...
Would I request the above to you, please?
Thanks
Takashi Sakamoto
On 05. 05. 22 13:41, Takashi Sakamoto wrote:
Hi Jaroslav,
On Fri, Apr 29, 2022 at 11:29:22AM +0900, Takashi Sakamoto wrote:
Hi Jaroslav,
On Tue, Apr 26, 2022 at 08:38:46PM +0900, Takashi Sakamoto wrote:
Hi Jaroslav,
On Tue, Apr 26, 2022 at 09:23:38AM +0200, Jaroslav Kysela wrote:
On 25. 04. 22 15:20, Takashi Sakamoto wrote:
Hi Jaroslav, Iwai-san,
Thanks for your maintenance for alsa-project organization in github.com. Currently I'd like to add new three repositories under the organization as a part of my work for ALSA firewire stack.
I've been maintaining libhinawa since 2014 and recently realized that current design is not necessarily convenient since it includes two functions; operation to Linux FireWire cdev, and operation of ALSA HwDep cdev. Currently I'm working for new library to split the latter operation. Then I'd like you to setup below repositories:
- 'libhitaki'
- 'libhitaki-doc'
- 'hitaki-rs'
The library itself and its Rust binding are utilized by 'snd-firewire-ctl-services'[2], thus it's preferable to register them under 'GObject Introspection' Team.
Thanks for your assist for my work.
Hi Takashi,
All is set on github. Let me know, if you need other changes.
Thanks for your arrangement. At present, I have no with for additional changes.
However for settings of libhinwa repository, I'd like you to change URL of documentation. We can see it in right side of top page.
Currently it points to 'https://takaswie.github.io/libhinawa-docs/' while it should be 'https://alsa-project.github.io/libhinawa-docs/'.
Additionally today I push documentation for libhitaki into the added repository:
I expect Github Pages makes association between the content and publish URI:
However it doesn't. I think we have missing configuration. Would I ask you to change settings following to this instruction?
https://docs.github.com/en/pages/getting-started-with-github-pages/configuri...
Would I request the above to you, please?
Appologize, I already set this last Friday, but forgot to send the confirmation e-mail.
https://alsa-project.github.io/libhitaki-doc/
There's possibility to have the doc and sources in one repo (I can specify doc subtree). It may reduce the repositories, but I suspect that your preference is to have things separated.
Jaroslav
On Thu, May 5, 2022, at 21:10, Jaroslav Kysela wrote:
On 05. 05. 22 13:41, Takashi Sakamoto wrote:
Hi Jaroslav,
On Fri, Apr 29, 2022 at 11:29:22AM +0900, Takashi Sakamoto wrote:
Hi Jaroslav,
On Tue, Apr 26, 2022 at 08:38:46PM +0900, Takashi Sakamoto wrote:
Hi Jaroslav,
On Tue, Apr 26, 2022 at 09:23:38AM +0200, Jaroslav Kysela wrote:
On 25. 04. 22 15:20, Takashi Sakamoto wrote:
Hi Jaroslav, Iwai-san,
Thanks for your maintenance for alsa-project organization in github.com. Currently I'd like to add new three repositories under the organization as a part of my work for ALSA firewire stack.
I've been maintaining libhinawa since 2014 and recently realized that current design is not necessarily convenient since it includes two functions; operation to Linux FireWire cdev, and operation of ALSA HwDep cdev. Currently I'm working for new library to split the latter operation. Then I'd like you to setup below repositories:
- 'libhitaki'
- 'libhitaki-doc'
- 'hitaki-rs'
The library itself and its Rust binding are utilized by 'snd-firewire-ctl-services'[2], thus it's preferable to register them under 'GObject Introspection' Team.
Thanks for your assist for my work.
Hi Takashi,
All is set on github. Let me know, if you need other changes.
Thanks for your arrangement. At present, I have no with for additional changes.
However for settings of libhinwa repository, I'd like you to change URL of documentation. We can see it in right side of top page.
Currently it points to 'https://takaswie.github.io/libhinawa-docs/' while it should be 'https://alsa-project.github.io/libhinawa-docs/'.
Additionally today I push documentation for libhitaki into the added repository:
I expect Github Pages makes association between the content and publish URI:
However it doesn't. I think we have missing configuration. Would I ask you to change settings following to this instruction?
https://docs.github.com/en/pages/getting-started-with-github-pages/configuri...
Would I request the above to you, please?
Appologize, I already set this last Friday, but forgot to send the confirmation e-mail.
OK. I can see the published pages.
Besides, please fix the URL in "about" information of libhinawa repository. You probable see a wheel icon in right side of top page. When clicking it, you can see "website" field has "https://takaswie.github.io/libhinawa-docs/". Please replace it with "https://alsa-project.github.io/libhinawa-docs/".
There's possibility to have the doc and sources in one repo (I can specify doc subtree). It may reduce the repositories, but I suspect that your preference is to have things separated.
At present I prefer separated pages from source since the pages can be generated from the source, however as you say the inclusive way is worth to reduce repository maintained by the project. I test the idea later in my libhinoko repository. When it looks well, I'll request you for configuration change.
Thanks
Takashi Sakamoto
On 05. 05. 22 14:49, Takashi Sakamoto wrote:
Besides, please fix the URL in "about" information of libhinawa repository. You probable see a wheel icon in right side of top page. When clicking it, you can see "website" field has "https://takaswie.github.io/libhinawa-docs/". Please replace it with "https://alsa-project.github.io/libhinawa-docs/".
Done.
Jaroslav
On Thu, May 05, 2022 at 02:59:06PM +0200, Jaroslav Kysela wrote:
On 05. 05. 22 14:49, Takashi Sakamoto wrote:
Besides, please fix the URL in "about" information of libhinawa repository. You probable see a wheel icon in right side of top page. When clicking it, you can see "website" field has "https://takaswie.github.io/libhinawa-docs/". Please replace it with "https://alsa-project.github.io/libhinawa-docs/".
Done.
Jaroslav
Thanks!
Takashi Sakamoto
Hi Jaroslav,
On Thu, May 05, 2022 at 09:49:52PM +0900, Takashi Sakamoto wrote:
At present I prefer separated pages from source since the pages can be generated from the source, however as you say the inclusive way is worth to reduce repository maintained by the project. I test the idea later in my libhinoko repository. When it looks well, I'll request you for configuration change.
I'd like to fix the issue for the URL of documentation before releasing libhitaki since I put the URL to configuration for gi-docgen.
I'm investigating to put the documentation into the same repository where source is maintained, however I prefer to separate the two into different repositories. Then I suppose it good to put several documentations into one repository rather than maintaining them in different repositories.
At present, three repositories are maintained for documentations:
* https://github.com/alsa-project/alsa-gobject-docs * https://github.com/alsa-project/libhinawa-docs * https://github.com/alsa-project/libhitaki-doc
Let us consolidate them in one repository. For example, by referring to team name:
* https://github.com/alsa-project/gobject-introspection-docs/
The documentations are expected to be public under below URL:
* https://alsa-project.github.io/gobject-introspection-docs/alsa-gobject/ * https://alsa-project.github.io/gobject-introspection-docs/hinawa/ * https://alsa-project.github.io/gobject-introspection-docs/hitaki/
I'd like to ask your opinion about the idea.
Thanks
Takashi Sakamoto
On 24. 05. 22 13:25, Takashi Sakamoto wrote:
Hi Jaroslav,
On Thu, May 05, 2022 at 09:49:52PM +0900, Takashi Sakamoto wrote:
At present I prefer separated pages from source since the pages can be generated from the source, however as you say the inclusive way is worth to reduce repository maintained by the project. I test the idea later in my libhinoko repository. When it looks well, I'll request you for configuration change.
I'd like to fix the issue for the URL of documentation before releasing libhitaki since I put the URL to configuration for gi-docgen.
I'm investigating to put the documentation into the same repository where source is maintained, however I prefer to separate the two into different repositories. Then I suppose it good to put several documentations into one repository rather than maintaining them in different repositories.
At present, three repositories are maintained for documentations:
- https://github.com/alsa-project/alsa-gobject-docs
- https://github.com/alsa-project/libhinawa-docs
- https://github.com/alsa-project/libhitaki-doc
Let us consolidate them in one repository. For example, by referring to team name:
The documentations are expected to be public under below URL:
- https://alsa-project.github.io/gobject-introspection-docs/alsa-gobject/
- https://alsa-project.github.io/gobject-introspection-docs/hinawa/
- https://alsa-project.github.io/gobject-introspection-docs/hitaki/
I'd like to ask your opinion about the idea.
Thanks for this idea. I just noted that github allows to specify a branch for the git pages (github.io). Do you think that a 'doc' or 'docs' branch in the separate source repos will be sufficient for your work? It may be more logical than having a common doc repo (logical URLs) and things (source and generated pages) will not mix together.
Thanks, Jaroslav
On Tue, May 24, 2022 at 02:36:19PM +0200, Jaroslav Kysela wrote:
On 24. 05. 22 13:25, Takashi Sakamoto wrote:
Hi Jaroslav,
On Thu, May 05, 2022 at 09:49:52PM +0900, Takashi Sakamoto wrote:
At present I prefer separated pages from source since the pages can be generated from the source, however as you say the inclusive way is worth to reduce repository maintained by the project. I test the idea later in my libhinoko repository. When it looks well, I'll request you for configuration change.
I'd like to fix the issue for the URL of documentation before releasing libhitaki since I put the URL to configuration for gi-docgen.
I'm investigating to put the documentation into the same repository where source is maintained, however I prefer to separate the two into different repositories. Then I suppose it good to put several documentations into one repository rather than maintaining them in different repositories.
At present, three repositories are maintained for documentations:
- https://github.com/alsa-project/alsa-gobject-docs
- https://github.com/alsa-project/libhinawa-docs
- https://github.com/alsa-project/libhitaki-doc
Let us consolidate them in one repository. For example, by referring to team name:
The documentations are expected to be public under below URL:
- https://alsa-project.github.io/gobject-introspection-docs/alsa-gobject/
- https://alsa-project.github.io/gobject-introspection-docs/hinawa/
- https://alsa-project.github.io/gobject-introspection-docs/hitaki/
I'd like to ask your opinion about the idea.
Thanks for this idea. I just noted that github allows to specify a branch for the git pages (github.io). Do you think that a 'doc' or 'docs' branch in the separate source repos will be sufficient for your work? It may be more logical than having a common doc repo (logical URLs) and things (source and generated pages) will not mix together.
Thanks for the suggestion. Indeed, we can choose the way to put documentation to specific branch in the repository. I've already investigated the way then had complexed feeling.
...To be honest, I'd like to avoid it, as much as possible, in a point of the essential concept in source control management. The branching idea forces to put several histories disconnected each other into one repository. It's surely available technically, however I feel sort of awkward somehow.
(I think I'm enough conservative when using tools. I feel something shooting myself in the foot when doing it. It perhaps comes from my experience under UNIX-like environment...)
The separated common repository for documents had room for integration of documentation. For example, I can put library documentations as well as overview page for included software such like Rust crates. It's flexible and logical in a view of top level of software stack.
Thanks
Takashi Sakamoto
On 25. 05. 22 3:42, Takashi Sakamoto wrote:
On Tue, May 24, 2022 at 02:36:19PM +0200, Jaroslav Kysela wrote:
On 24. 05. 22 13:25, Takashi Sakamoto wrote:
Hi Jaroslav,
On Thu, May 05, 2022 at 09:49:52PM +0900, Takashi Sakamoto wrote:
At present I prefer separated pages from source since the pages can be generated from the source, however as you say the inclusive way is worth to reduce repository maintained by the project. I test the idea later in my libhinoko repository. When it looks well, I'll request you for configuration change.
I'd like to fix the issue for the URL of documentation before releasing libhitaki since I put the URL to configuration for gi-docgen.
I'm investigating to put the documentation into the same repository where source is maintained, however I prefer to separate the two into different repositories. Then I suppose it good to put several documentations into one repository rather than maintaining them in different repositories.
At present, three repositories are maintained for documentations:
- https://github.com/alsa-project/alsa-gobject-docs
- https://github.com/alsa-project/libhinawa-docs
- https://github.com/alsa-project/libhitaki-doc
Let us consolidate them in one repository. For example, by referring to team name:
The documentations are expected to be public under below URL:
- https://alsa-project.github.io/gobject-introspection-docs/alsa-gobject/
- https://alsa-project.github.io/gobject-introspection-docs/hinawa/
- https://alsa-project.github.io/gobject-introspection-docs/hitaki/
I'd like to ask your opinion about the idea.
Thanks for this idea. I just noted that github allows to specify a branch for the git pages (github.io). Do you think that a 'doc' or 'docs' branch in the separate source repos will be sufficient for your work? It may be more logical than having a common doc repo (logical URLs) and things (source and generated pages) will not mix together.
Thanks for the suggestion. Indeed, we can choose the way to put documentation to specific branch in the repository. I've already investigated the way then had complexed feeling.
...To be honest, I'd like to avoid it, as much as possible, in a point of the essential concept in source control management. The branching idea forces to put several histories disconnected each other into one repository. It's surely available technically, however I feel sort of awkward somehow.
(I think I'm enough conservative when using tools. I feel something shooting myself in the foot when doing it. It perhaps comes from my experience under UNIX-like environment...)
The separated common repository for documents had room for integration of documentation. For example, I can put library documentations as well as overview page for included software such like Rust crates. It's flexible and logical in a view of top level of software stack.
It's fine for me. The gobject-introspection-docs is created now.
Jaroslav
Hi,
On Wed, May 25, 2022 at 08:37:37AM +0200, Jaroslav Kysela wrote:
On 25. 05. 22 3:42, Takashi Sakamoto wrote:
Thanks for the suggestion. Indeed, we can choose the way to put documentation to specific branch in the repository. I've already investigated the way then had complexed feeling.
...To be honest, I'd like to avoid it, as much as possible, in a point of the essential concept in source control management. The branching idea forces to put several histories disconnected each other into one repository. It's surely available technically, however I feel sort of awkward somehow.
(I think I'm enough conservative when using tools. I feel something shooting myself in the foot when doing it. It perhaps comes from my experience under UNIX-like environment...)
The separated common repository for documents had room for integration of documentation. For example, I can put library documentations as well as overview page for included software such like Rust crates. It's flexible and logical in a view of top level of software stack.
It's fine for me. The gobject-introspection-docs is created now.
Great. I pushed some documents except for index page:
* https://github.com/alsa-project/gobject-introspection-docs
Later I'd like to use Jekyll backend of github pages[1]. Would I ask you to grant my privilege in the repository so that I can add configuration for it? I think the same privilege set in libhinawa-docs is enough.
Additionally, please archive below old documentation repositories? I've already configure them to publish redirect pages. I hear that github pages service still publish pages for archived repositories.
* https://github.com/alsa-project/libhinawa-docs/ * https://github.com/alsa-project/libhitaki-doc/ * https://github.com/alsa-project/alsa-gobject-docs/
And it's helpful to change page URL in 'About' section of right pane. (I think it's good to remove it for convenience.)
* https://github.com/alsa-project/libhinawa/
Today I release new releases for libhinawa and libhitaki. Thanks for your help.
* https://github.com/alsa-project/libhitaki/releases/tag/v0.1.0 * https://github.com/alsa-project/libhinawa/releases/tag/2.5.0
[1] https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/... [2] https://github.com/alsa-project/libhinawa-docs/
Regards
Takashi Sakamoto
On 26. 05. 22 14:58, Takashi Sakamoto wrote:
Hi,
On Wed, May 25, 2022 at 08:37:37AM +0200, Jaroslav Kysela wrote:
On 25. 05. 22 3:42, Takashi Sakamoto wrote:
Thanks for the suggestion. Indeed, we can choose the way to put documentation to specific branch in the repository. I've already investigated the way then had complexed feeling.
...To be honest, I'd like to avoid it, as much as possible, in a point of the essential concept in source control management. The branching idea forces to put several histories disconnected each other into one repository. It's surely available technically, however I feel sort of awkward somehow.
(I think I'm enough conservative when using tools. I feel something shooting myself in the foot when doing it. It perhaps comes from my experience under UNIX-like environment...)
The separated common repository for documents had room for integration of documentation. For example, I can put library documentations as well as overview page for included software such like Rust crates. It's flexible and logical in a view of top level of software stack.
It's fine for me. The gobject-introspection-docs is created now.
Great. I pushed some documents except for index page:
Later I'd like to use Jekyll backend of github pages[1]. Would I ask you to grant my privilege in the repository so that I can add configuration for it? I think the same privilege set in libhinawa-docs is enough.
It seems that it's just a configuration file which is stored in the repository, so the standard github pages setup should be sufficient.
Anyway, I made you as maintainer of this gobject-introspection-docs repo, so you should do more changes in it, if you like.
Additionally, please archive below old documentation repositories? I've already configure them to publish redirect pages. I hear that github pages service still publish pages for archived repositories.
- https://github.com/alsa-project/libhinawa-docs/
- https://github.com/alsa-project/libhitaki-doc/
- https://github.com/alsa-project/alsa-gobject-docs/
And it's helpful to change page URL in 'About' section of right pane. (I think it's good to remove it for convenience.)
Today I release new releases for libhinawa and libhitaki. Thanks for your help.
- https://github.com/alsa-project/libhitaki/releases/tag/v0.1.0
- https://github.com/alsa-project/libhinawa/releases/tag/2.5.0
[1] https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/... [2] https://github.com/alsa-project/libhinawa-docs/
I've tried to follow all instructions. If something is missing, please, ping me.
Jaroslav
Hi Jaroslav,
I apologize to be late for reply to the message, but I'm under heavy load to publish Rust crates recent few months.
On Thu, May 26, 2022 at 03:35:40PM +0200, Jaroslav Kysela wrote:
On 26. 05. 22 14:58, Takashi Sakamoto wrote:
Later I'd like to use Jekyll backend of github pages[1]. Would I ask you to grant my privilege in the repository so that I can add configuration for it? I think the same privilege set in libhinawa-docs is enough.
It seems that it's just a configuration file which is stored in the repository, so the standard github pages setup should be sufficient.
Indeed. I can publish github pages with Jekyll backend with the concise way just to put `_config.yml` and markdown files without such privilege.
Anyway, I made you as maintainer of this gobject-introspection-docs repo, so you should do more changes in it, if you like.
Thanks for your arrangement, however I can see my privilege in repository settings just for archived alsa-gobject-docs...
* https://github.com/alsa-project/alsa-gobject-docs/
Anyway I'm not so eager to have the privilege now since it's enough at present.
By the way, now I published 30 Rust library crates in crates.io, enumerated in this page:
* https://alsa-project.github.io/gobject-introspection-docs/crates.html
Currently I'm an owner of the crates, while I'd like to prepare the possibility to grant ownership to the other developers for future accident. Then I'm investigating to use "team" owner feature of crates.io service.
For the feature, the service of crates.io needs to query team membership in github.com, but the service should be permitted it by github service.
* https://doc.rust-lang.org/cargo/reference/publishing.html#github-permissions
According to the above document, the way to grant the permission seems to be either to remove crates.io from the blacklist or add crates.io to the whitelist of organization's third-party access page.
If you, organization manager, don't mind OAuth access from crates.io, I'd like to request it via my github account. I guess that alsa-project organization currently has no effective configuration to third-party application access policy. When I requested it, you can see something new in the page of policy, then I'd like you to grand the access. When granted, I will operate settings for the crates to add team owner.
Thanks
Takashi Sakamoto
On 05. 08. 22 12:26, Takashi Sakamoto wrote:
Hi Jaroslav,
I apologize to be late for reply to the message, but I'm under heavy load to publish Rust crates recent few months.
On Thu, May 26, 2022 at 03:35:40PM +0200, Jaroslav Kysela wrote:
On 26. 05. 22 14:58, Takashi Sakamoto wrote:
Later I'd like to use Jekyll backend of github pages[1]. Would I ask you to grant my privilege in the repository so that I can add configuration for it? I think the same privilege set in libhinawa-docs is enough.
It seems that it's just a configuration file which is stored in the repository, so the standard github pages setup should be sufficient.
Indeed. I can publish github pages with Jekyll backend with the concise way just to put `_config.yml` and markdown files without such privilege.
Anyway, I made you as maintainer of this gobject-introspection-docs repo, so you should do more changes in it, if you like.
Thanks for your arrangement, however I can see my privilege in repository settings just for archived alsa-gobject-docs...
Anyway I'm not so eager to have the privilege now since it's enough at present.
By the way, now I published 30 Rust library crates in crates.io, enumerated in this page:
Currently I'm an owner of the crates, while I'd like to prepare the possibility to grant ownership to the other developers for future accident. Then I'm investigating to use "team" owner feature of crates.io service.
For the feature, the service of crates.io needs to query team membership in github.com, but the service should be permitted it by github service.
According to the above document, the way to grant the permission seems to be either to remove crates.io from the blacklist or add crates.io to the whitelist of organization's third-party access page.
If you, organization manager, don't mind OAuth access from crates.io, I'd like to request it via my github account. I guess that alsa-project organization currently has no effective configuration to third-party application access policy. When I requested it, you can see something new in the page of policy, then I'd like you to grand the access. When granted, I will operate settings for the crates to add team owner.
It seems that 'maintainer' priviledges are not enough - changed to 'admin' for your account in the gobject-introspection-docs repo. I have no objections for the OAuth access from crates.io .
Jaroslav
On Fri, Aug 05, 2022 at 12:42:59PM +0200, Jaroslav Kysela wrote:
On 05. 08. 22 12:26, Takashi Sakamoto wrote:
Hi Jaroslav,
I apologize to be late for reply to the message, but I'm under heavy load to publish Rust crates recent few months.
On Thu, May 26, 2022 at 03:35:40PM +0200, Jaroslav Kysela wrote:
On 26. 05. 22 14:58, Takashi Sakamoto wrote:
Later I'd like to use Jekyll backend of github pages[1]. Would I ask you to grant my privilege in the repository so that I can add configuration for it? I think the same privilege set in libhinawa-docs is enough.
It seems that it's just a configuration file which is stored in the repository, so the standard github pages setup should be sufficient.
Indeed. I can publish github pages with Jekyll backend with the concise way just to put `_config.yml` and markdown files without such privilege.
Anyway, I made you as maintainer of this gobject-introspection-docs repo, so you should do more changes in it, if you like.
Thanks for your arrangement, however I can see my privilege in repository settings just for archived alsa-gobject-docs...
Anyway I'm not so eager to have the privilege now since it's enough at present.
By the way, now I published 30 Rust library crates in crates.io, enumerated in this page:
Currently I'm an owner of the crates, while I'd like to prepare the possibility to grant ownership to the other developers for future accident. Then I'm investigating to use "team" owner feature of crates.io service.
For the feature, the service of crates.io needs to query team membership in github.com, but the service should be permitted it by github service.
According to the above document, the way to grant the permission seems to be either to remove crates.io from the blacklist or add crates.io to the whitelist of organization's third-party access page.
If you, organization manager, don't mind OAuth access from crates.io, I'd like to request it via my github account. I guess that alsa-project organization currently has no effective configuration to third-party application access policy. When I requested it, you can see something new in the page of policy, then I'd like you to grand the access. When granted, I will operate settings for the crates to add team owner.
It seems that 'maintainer' priviledges are not enough - changed to 'admin' for your account in the gobject-introspection-docs repo.
Thanks for your kindness. I can now see settings page itself and many items in it.
I have no objections for the OAuth access from crates.io .
Ok. Just now I sent the request to organization. I'm waiting for the acceptance notification.
Thanks
Takashi Sakamoto
Hi,
On Fri, Aug 05, 2022 at 07:58:56PM +0900, Takashi Sakamoto wrote:
On Fri, Aug 05, 2022 at 12:42:59PM +0200, Jaroslav Kysela wrote:
I have no objections for the OAuth access from crates.io .
Ok. Just now I sent the request to organization. I'm waiting for the acceptance notification.
This is just a reminder for the above task. I'm waiting for the change of pending state so long.
Regards
Takashi Sakamoto
On 27. 08. 22 5:43, Takashi Sakamoto wrote:
Hi,
On Fri, Aug 05, 2022 at 07:58:56PM +0900, Takashi Sakamoto wrote:
On Fri, Aug 05, 2022 at 12:42:59PM +0200, Jaroslav Kysela wrote:
I have no objections for the OAuth access from crates.io .
Ok. Just now I sent the request to organization. I'm waiting for the acceptance notification.
This is just a reminder for the above task. I'm waiting for the change of pending state so long.
Approved.
Jaroslav
On Sat, Aug 27, 2022 at 07:29:35AM +0200, Jaroslav Kysela wrote:
On 27. 08. 22 5:43, Takashi Sakamoto wrote:
Hi,
On Fri, Aug 05, 2022 at 07:58:56PM +0900, Takashi Sakamoto wrote:
On Fri, Aug 05, 2022 at 12:42:59PM +0200, Jaroslav Kysela wrote:
I have no objections for the OAuth access from crates.io .
Ok. Just now I sent the request to organization. I'm waiting for the acceptance notification.
This is just a reminder for the above task. I'm waiting for the change of pending state so long.
Approved.
Thanks for your approval.
Now 'github:alsa-project:gobject-introspection' team owns 30 crates in crates.io as well:
* https://crates.io/teams/github:alsa-project:gobject-introspection
Any member in the team can publish/yank the crates, while is not allowed to change ownership including its resignation.
* https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner
Regards
Takashi Sakamoto
participants (2)
-
Jaroslav Kysela
-
Takashi Sakamoto