Hi TC members, Infrastructure team and community members,
Recently there are many issues about adding dependencies or new
packages [1][2][3].
As a linux operating system, it is extremely critical to manage the
dependencies. As we know, Technical committee is managing the packages
management policy, however who maintain the new packages is not clear.
I have draft idea on this. Please give your advice, opinions on how to
maintain the dependencies.
- policy. Dependencies are still packages, thus they follow the flow
on how to introduce the packages into openEuler community.
- Who to maintain: if the packages are new and only dependencies,
probably one specific team is an option to do this.
- How to automate: Infrastructure should provide a function on getting
update from upstream automatically
- Dependencies management: an expert should maintain the detailed work
on how to choose for ISO and yum for each specific version of release.
[1] https://gitee.com/openeuler/community-issue/issues/I1CBYV?from=project-issue
[2] https://gitee.com/openeuler/community-issue/issues/I1BHND?from=project-issue
[3] https://gitee.com/openeuler/community-issue/issues/I1CBW5?from=project-issue
--
Regards
Fred Li (李永乐)
Hi Dear TC,
We are so pleased to propose to apply a new SIG UKUI, please check it out
at PR https://gitee.com/openeuler/community/pulls/291 .
Please let me have a brief introduction on UKUI for you.
UKUI is designed by KylinSoft Co., Ltd. UKUI is a lightweight desktop
environment based on pluggable framework for Linux and other Unix-like
Distributions. It provides a simpler and more enjoyable experience for
browsing, searching, and managing your computer.It is developed using GTK
and Qt. It's comprised of ukui-panel, ukui-sidecar and many other
components. Please see the official site http://ukui.org/ for more
information.
The UKUI SIG will work on making UKUI available to all of openEuler users.
Looking forward to hearing from you. Thanks and take care.
Regards,
Joey
Hi all:
I’m Joey and from infrastructure team of openEuler. So glad to see you guys and hope everybody is doing well.
I’m writing here to have a brief introduction to the new features provided by ci-bot. We believe they would be helpful for your repository management.
As it’s known to us, ci-bot is an automation system to handle lots of infrastructure stuff, such as gitee web hook events, repository management, owner management and etc. For more details about our lovely ci-bot, please refer to https://gitee.com/openeuler/ci-bot <https://gitee.com/openeuler/ci-bot>. For now, please let me elaborate how you can make use of the two features to ease the repository management.
1. Add commentable property for repository definition in openeuler.yaml or src-openeuler.yaml under openeuler/community. PR is: https://gitee.com/openeuler/ci-bot/pulls/26 <https://gitee.com/openeuler/ci-bot/pulls/26> .
> Previously users could leave a comment at the index page of the project, which is a great feature provided by Gitee. While as we all know, the more conventional way is posting an issue request for questions/bugs/features. So after discussion, we finally consider to disable the comment-to-repository feature for all repositories. So here comes to this functionality, which adds an extra commentable property. If it’s not specified, the default value is false of boolean type.
> Actually, you DO NOT need to pay any attention to this new property since non-commentable repository is strongly recommended. Just think it never exists. The example is shown as below,
```yaml
community: openeuler
repositories:
- name: A-Tune
description: ""
type: public
commentable: false # User CAN NOT see or leave comment to repository
- name: ci-bot
description: ""
type: public
commentable: true # Users CAN see and leave comment to repository
- name: community
description: ""
type: public
# User CAN NOT see or leave comment to repository
```
2. Add rename_from property for repository definition in openeuler.yaml or src-openeuler.yaml under openeuler/community. PR is: https://gitee.com/openeuler/ci-bot/pulls/27 <https://gitee.com/openeuler/ci-bot/pulls/27> .
> Please let me take a real case for example. In PR https://gitee.com/openeuler/community/pulls/128 <https://gitee.com/openeuler/community/pulls/128>, iSulad team wants to change the names of three repositories:
iSulad-kit ===> iSulad-img
iSulad-lxcfs-toolkit ===> lxcfs-tools
iSulad-tools ===> syscontainer-tools
> As the PR is shown to us, the code diff is as below, which leaded ci-bot to completely remove the old repository and create a new empty one with the new name, causing loss of all the existing issues and PRs.
```diff
- - name: iSulad-kit
+ - name: iSulad-img
description: ""
- - name: iSulad-lxcfs-toolkit
+ - name: lxcfs-toolkit
description: ""
- - name: iSulad-tools
+ - name: syscontainer-tools
description: ""
```
> While after the PR has been merged, the diff would be like the following. This could make use of the newly supported renaming-repository Gitee OpenAPI to keep all the issues and PRs unchanged.
```diff
- - name: iSulad-kit
+ - name: iSulad-img
description: ""
+ rename_from: iSulad-kit
- - name: iSulad-lxcfs-toolkit
+ - name: lxcfs-toolkit
description: ""
+ rename_from: iSulad-lxcfs-toolkit
- - name: iSulad-tools
+ - name: syscontainer-tools
description: ""
+ rename_from: iSulad-tools
```
> While it should noted that rename_from is not declarative but imperative cause it will take effect only for once and not stored in DB. So if we remove it from repository definition after renaming operation has been finished, nothing will happen.
Hopefully I have explained clear enough. Currently the new functionalities are not in production yet and your feedback is rather important to us. So please reply this email for further discussion as soon as you have any doubt. Looking forward to your feedback.
Take care!
Best regards,
Joey
Hi all,
As you know, openEuler community uses Mulan PSL v1 now as the open
source license.
Because Mulan PSL v2 was just approved by OSI, it is proposed to
upgrade the license from v1 to v2 for the projects which use Mulan PSL
v1 now. If you have different opinion on this, please send email to
community(a)openeuler.org by March 19th, 2020.
The license updating will not be valid until March 19th, 2020.
Find the details below:
[1] http://blog.openeuler.org/post/fred_li/2020-03-03-license-update/
--
Regards
Fred Li (李永乐)
Version 1.0 of user role definition [3] has been output, including user role definition, data access definition, key indicators and statistical analysis dimensions. Welcome to confirm if v1.0 content is OK.
@infra, Please focus on the attachment in [3], We can start the discussion of implementation design.
Thank you.
[3] https://gitee.com/openeuler/community/issues/I1BSJ4?from=project-issue
-----邮件原件-----
发件人: Haolijuan
发送时间: 星期一, 2020年3月16日 16:20
收件人: 'Fred Li' <yongle.li(a)gmail.com>; community <community(a)openeuler.org>; infra <infra(a)openeuler.org>
主题: Re: [Infra] [metrics] welcome to join the task to design and implement community operation metrics
Hi all,
First, thanks Fred Li, imjoey, zhongjun and maquanyi for the contribution.
For the role definition in the user funnel model, I created a new issue[3] for review. Welcome to provide your review comments before March 19,2020.
Thank you in advance.
[3] https://gitee.com/openeuler/community/issues/I1BSJ4?from=project-issue
-----邮件原件-----
发件人: Fred Li [mailto:yongle.li@gmail.com]
发送时间: 星期四, 2020年3月12日 22:47
收件人: community <community(a)openeuler.org>; infra <infra(a)openeuler.org>
主题: [Infra] [metrics] welcome to join the task to design and implement community operation metrics
Hi all,
@ivye has opened [1] to start analyze the requirement about community operation metrics.
[2] is the shared document to collect your idea.
@zhongjun2 is joining this task and will implement the requirements.
@imjoey and I (@zerodefect) have drafted some in [2].
It is an interesting topic, and if you would like to try, join us.
Sorry for the content is in Chinese so far, and if anyone needs English, please let me know.
[1] https://gitee.com/openeuler/community/issues/I1BAO0
[2] https://docs.qq.com/doc/DRmlaYnZSbEViRm5G
--
Regards
Fred Li (李永乐)
_______________________________________________
Infra mailing list -- infra(a)openeuler.org To unsubscribe send an email to infra-leave(a)openeuler.org
Hi all,
First, thanks Fred Li, imjoey, zhongjun and maquanyi for the contribution.
For the role definition in the user funnel model, I created a new issue[3] for review. Welcome to provide your review comments before March 19,2020.
Thank you in advance.
[3] https://gitee.com/openeuler/community/issues/I1BSJ4?from=project-issue
-----邮件原件-----
发件人: Fred Li [mailto:yongle.li@gmail.com]
发送时间: 星期四, 2020年3月12日 22:47
收件人: community <community(a)openeuler.org>; infra <infra(a)openeuler.org>
主题: [Infra] [metrics] welcome to join the task to design and implement community operation metrics
Hi all,
@ivye has opened [1] to start analyze the requirement about community operation metrics.
[2] is the shared document to collect your idea.
@zhongjun2 is joining this task and will implement the requirements.
@imjoey and I (@zerodefect) have drafted some in [2].
It is an interesting topic, and if you would like to try, join us.
Sorry for the content is in Chinese so far, and if anyone needs English, please let me know.
[1] https://gitee.com/openeuler/community/issues/I1BAO0
[2] https://docs.qq.com/doc/DRmlaYnZSbEViRm5G
--
Regards
Fred Li (李永乐)
_______________________________________________
Infra mailing list -- infra(a)openeuler.org To unsubscribe send an email to infra-leave(a)openeuler.org