Dne 6.11.2018 v 01:49 Takashi Sakamoto napsal(a):

Hi Jaroslav,

On 2018/11/05 17:49, Jaroslav Kysela wrote:

...

Hi all,

URL: https://github.com/alsa-project

I finally finished the first phase of the integration with GitHub. All repositories are now on GitHub and all repositories are mirrored to alsa-project.org. The github repositories are master (developers should push changes only to those repositories). If you refer the repository as the code source (for packaging or so), please, keep to use the repositories on alsa-project.org (in case when we migrate to other service in future like GitLab or so). The mirroring is realtime, so the changes should be visible on git.alsa-project.org in few seconds after the push.

I invited few people to the GitHub team and actually Takashi has full access to all repos, Vinod Koul should have the write access to tinycompress and Takashi Sakamoto should have the write access to alsa-gi. If I omitted someone (or someone is not on github), please, let me know (and register before).

Because github adds possibility for the pull requests and issue tracking, I added notifications for them to this (alsa-devel) mailing list. The short notification should be sent when an pull request or an issue is opened or changed. I think that it would be best to handle this per request, so the developer can ask to resend the patch to the mailing list for the wider review or just push the change with the signing.

I activated Travis CI for alsa-lib and alsa-utils and I will add other repos soon, too. URL: https://travis-ci.org/alsa-project

If you have some ideas which other github applications can be used to improve the code maintenance, let me know. I will probably play with the coverity checker (http://scan.coverity.com), too.

Thanks for your arrangement. This is what I wish for a long time ;) (however, I apologize my laziness forward to it...)

Just now I sent my PR to alsa-utils[1], and a notification is sent[2]. A job of Travis-CI runs automatically on Ubuntu 14.04 LTS (probably in a docker container)[3]. In the job, alsa-lib was firstly built, then alsa-utils was built, as described in '.travis.yaml'. It takes a bit time to download tex-related packages from us mirror of repository (http://us-east-1.ec2.archive.ubuntu.com/). A few minutes later, check icon becomes green on github.com.

I have two concerns.

1. For Ubuntu 14.04 LTS (trusty), End-of-life (EOL) is scheduled April
2. A few months remained but it's better to use recent LTSs such as

18.04 (bionic) to reduce future maintenance cost. (I guess packages except on 'main' pocket are not already maintained for security updates.)

I think that we have limited choices:

https://docs.travis-ci.com/user/reference/overview/

2. Message for PR

In my opinion, notification to alsa-devel list is an alternative of cover-letters in the past. But in this time it doesn't includes change summary, like:

Takashi Sakamoto (3):
   aplay: delete paragraph for obsoleted '--sleep-min' ('-s') option from
     aplay manual
   aplay: add a paragraph for '--samples' ('-s') option to aplay manual
   aplay: improve available conditions for '--samples' and '--duration'
     options

  aplay/aplay.1 | 10 +++++++---
  1 file changed, 7 insertions(+), 3 deletions(-)

If it's difficult to include the change summary automatically into the notification, it's worth to discuss that PR senders should include it handy to PR message.

Actually, I can work directly only with the information from the webhooks:

https://developer.github.com/v3/activity/events/types/#pullrequestevent

The webhook code used on my server is in python, so we can probably fetch the patch from github and generate the diffstat from it.

Jaroslav

Dne 8.11.2018 v 15:20 Takashi Sakamoto napsal(a):

Hi Jaroslav,

Thanks for your reply.

On 2018/11/06 18:20, Jaroslav Kysela wrote:

...

...

I have two concerns.

1. For Ubuntu 14.04 LTS (trusty), End-of-life (EOL) is scheduled April
2. A few months remained but it's better to use recent LTSs such as

18.04 (bionic) to reduce future maintenance cost. (I guess packages except on 'main' pocket are not already maintained for security updates.)

I think that we have limited choices:

https://docs.travis-ci.com/user/reference/overview/

Oh, indeed. It's reasonable currently, but I continue to take care of travis-ci action against the EOF.

...

...

2. Message for PR

In my opinion, notification to alsa-devel list is an alternative of cover-letters in the past. But in this time it doesn't includes change summary, like:

Takashi Sakamoto (3):
    aplay: delete paragraph for obsoleted '--sleep-min' ('-s') option from
      aplay manual
    aplay: add a paragraph for '--samples' ('-s') option to aplay manual
    aplay: improve available conditions for '--samples' and '--duration'
      options

   aplay/aplay.1 | 10 +++++++---
   1 file changed, 7 insertions(+), 3 deletions(-)

If it's difficult to include the change summary automatically into the notification, it's worth to discuss that PR senders should include it handy to PR message.

Actually, I can work directly only with the information from the webhooks:

https://developer.github.com/v3/activity/events/types/#pullrequestevent

The webhook code used on my server is in python, so we can probably fetch the patch from github and generate the diffstat from it.

Sounds good, but I don't mind to postpone the idea because this is not so critical issue. Readers of posted issue can see diffstat in github.com.

Well, I have another concern when having conversation with Daniel Baluta[1]. He post his 'Reviewed-by' tag to the github issue. In this case, how can we apply the tag to commit history? I don't know exactly services in github.com have good solution for this issue, or not...

[1] https://github.com/alsa-project/alsa-utils/pull/1#issuecomment-436164565

I believe that the maintainer who signs and pushes the commits should handle those tags, too.

It means that we are not allowed to use the github web merge button! (no signing - seems like on github's issue list - https://github.com/todogroup/gh-issues/issues/50)

Jaroslav

Hi Jaroslav,

Sorry for late reply.

On Thu, 8 Nov 2018, Jaroslav Kysela wrote:

...

Well, I have another concern when having conversation with Daniel Baluta[1]. He post his 'Reviewed-by' tag to the github issue. In this case, how can we apply the tag to commit history? I don't know exactly services in github.com have good solution for this issue, or not...

[1] https://github.com/alsa-project/alsa-utils/pull/1#issuecomment-436164565

I believe that the maintainer who signs and pushes the commits should handle those tags, too.

It means that we are not allowed to use the github web merge button! (no signing - seems like on github's issue list - https://github.com/todogroup/gh-issues/issues/50)

Thank you. It's completely against out maintainance policy that we can handle no tag such as 'Reviewed-by:' and 'Signed-off-by:', thus the web merge button in github.com can not be used. I'm OK to avoid pushing the button.

I think it good to push a small guideline message for userspace work to somewhere for smooth communication between people, like:

1. contributors * prepare change history so that fast-forward to remote repository * each of commit should have 'Signed-off-by:' tag * For bug fix, additional 'Fixes:' tag is preferable * two communication paths; 'git format-patch/send-email' to alsa-devel list, or PR on github.com * put enough information in cover-letter of email or PR comment so that reviers/maintainers can get purpose of this work 2. reviewers * any review action is welcome and expected * after review work, send comments with 'Reviewed-by:', 'Tested-by:' tags as reply to the list or PR so that contributors and reviewers can catch 3. maintainers * apply the patches from contributor to local repository by hand without web UI of github.com so that the history has no merge commits * add reviewer's tags to applied commits * add 'Signed-off-by:' tag to applied commits * reply to list or PR when push to remote repository

Any thoughts?

Thanks

Takashi Sakamoto