Re: [webkit-dev] Removal of trailing whitespace
To digress a little, why does webkit now use a style checker based on python script instead of clang-format? In today, I feel it's more reasonable to use such a formetter. (This is just a off topic & just my interesting about history, I don’t have a intention to propose in this discussion to switch the tool to check and sort the coding style) 2023年4月13日(木) 4:40 Ryosuke Niwa via webkit-dev : > > On Apr 12, 2023, at 12:34 PM, Chris Dumez wrote: > > On Apr 12, 2023, at 10:23 AM, Ryosuke Niwa via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > > Yeah, enforcing that new or otherwise modified lines don’t have trailing > whitespaces would be good. > > > Yes, I wouldn’t mind that either. > > However, https://commits.webkit.org/262879@main has just landed and if > you look at the changes to Document.cpp, it is mostly spacing changes :( > It makes it harder to review or to identify meaningful changes in a patch > after landing. It also pollutes git blame for no great reason. > > > Yeah, it’s not great that PR got landed. In the future, it would be good > to hold off landing these code changes until the discussion settles. > > - R. Niwa > > On Apr 12, 2023, at 10:20 AM, Yusuke Suzuki wrote: > > I agree that we should not do it because it pollutes change history of > files, git-blame results, and review-diff in PR. > But at the same time, I think there is no reason to add a new trailing > whitespace via a new commit. > It is nice if we can enforce this rule only for newly added code (via > style-checker) not to add new trailing spaces. > > -Yusuke > > On Apr 12, 2023, at 10:08 AM, Ryosuke Niwa via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > > WebKi proejctt’s long term policy has been to not do this: > https://lists.webkit.org/pipermail/webkit-dev/2009-August/009665.html > > I don’t think we should change that. > > - R. Niwa > > On Apr 12, 2023, at 9:17 AM, Chris Dumez via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > > I am against this because it adds a lot of noise to patches I am trying to > review. > I have seen PRs where white space changes account for more than half the > patch I am trying to review. > > Dropping trailing spaces on the lines you’re modifying is OK but in the > whole file is too noisy IMO. > > Chris. > > On Apr 12, 2023, at 1:22 AM, Anne van Kesteren via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > > To reduce the overhead of switching between projects with different > whitespace requirements, I would like to suggest we start being > lenient when trailing whitespace is removed. In particular when a file > is being changed to fix a bug. > > I could see going even further and enforcing this via the style > checker, if there is appetite for that. > > Thanks for considering! > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removal of trailing whitespace
How about adding the trim_trailing_whitespace option to the root's .editorconfig as the first step? - https://github.com/WebKit/WebKit/blob/main/.editorconfig - https://editorconfig.org/ This does not enforce anything for all of us, so we still require some style checker mechanism, but I think it's a nice first step for this topic. -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Wed, Apr 12, 2023 at 5:22 PM Anne van Kesteren via webkit-dev wrote: > > To reduce the overhead of switching between projects with different > whitespace requirements, I would like to suggest we start being > lenient when trailing whitespace is removed. In particular when a file > is being changed to fix a bug. > > I could see going even further and enforcing this via the style > checker, if there is appetite for that. > > Thanks for considering! > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Fri, Oct 16, 2020 at 4:49 AM Konstantin Tokarev wrote: > > > Why would you want to do that? > > I think rich text in comments is evil, for the same reasons as HTML e-mail. > > Yes, with markdown you won't often see unreadably colored text (what happens > with HTML e-mail), but still there is pretty much room for abuse of formatting > (to attract attention or just because they can), or accidental formatting when > non-markdown text is interpreted as markdown resulting in a total mess > (which inexperienced users cannot fix and leave as is). > > BTW, GitHub recently added rich text UI controls to code review comments, so > even those who don't know markdown can start abusing formatting there now... Sorry, I'm not sure about that why you feel a bad emotion for rich text format... As my stance, I prefer to display a code snippet, quote and list as formatted style with a discussion with BTS. It's a bit hard to read a quote as styled `>` like this text email for me, so I'd like to read a quote block as a styled format by default. But this is my personal complaints. I would not like to say that WebKit Bugzilla must support markdown in the comment form immediately. -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Fri, Oct 16, 2020 at 4:49 AM Konstantin Tokarev wrote: > > > > 14.10.2020, 16:52, "Tetsuharu OHZEKI" : > > I feel from this discussion that everybody has their own best way and > > we’re tackling to resolve them at once in this migration process. > > I also feel it’s a bit difficult to conclude something. > > > > FWIW, I would like to write some my problems about the current > > workflow to help figure out > > what is a problem in the current workflow and what we should be > > resolved in this or other future process. > > > > This would not propose an actual solution, but I believe this would > > help to find a final solution and other people will also say your > > problems to help. > > > > 1. Code review tools > > WebKit Bugzilla’s code review tool is not a beautiful solution for today. > > I would like to get a preview for markdown file or syntax highlights. > > > > 2. Bug Tracking System > > I don’t feel a problem to use WebKit Bugzilla, and I doubt that using > > Bugzilla is really a problem to collect a feedback from the webdev > > community as other people said in this thread. > > However, I have some complaints… > > > > * I’d like to write markdown as a comment for bugs. > > Why would you want to do that? > > I think rich text in comments is evil, for the same reasons as HTML e-mail. > > Yes, with markdown you won't often see unreadably colored text (what happens > with HTML e-mail), but still there is pretty much room for abuse of formatting > (to attract attention or just because they can), or accidental formatting when > non-markdown text is interpreted as markdown resulting in a total mess > (which inexperienced users cannot fix and leave as is). > > BTW, GitHub recently added rich text UI controls to code review comments, so > even those who don't know markdown can start abusing formatting there now... > > -- > Regards, > Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
> The original goal mentionned at the start of the thread was encouraging > more people to contribute to WebKit. From that side, what's important is > trying to retain a patch submission workflow that's standardized. That can > be github/gitlab style pull requests, or Gerrit which is a different one. > There are probably others. > > If the workflow for submitting patches requires writing a changelog file, > or other similar custom operations, I think that's more likely to turn > potential contributors away (I can only speak for myself, here, of course). > Even if you automate it with a script, people will have to remember to > use the script. Then it doesn't matter if you use Git or Github or some > other tool under the hood: the patch submission process is a custom one. > > Starting from there, the question is more: > > Which of these existing workflows is more suitable? > > How much can we tweak them (with bots on Github, plugins > on Gerrit, or pre-commit/pre-push hooks on developer machines, for example) > to make them better fit the existing things that will probably be kept? > (I guess Apple internal bugtracker, possibly bugzilla as well, maybe some > parts of the existing build infrastructure and builder machines?). > > Can these changes to the workflow be done and documented so that existing > Git (and Github/Gitlab/Gerrit/...) users can handle them easily? I agree that VCS is a one of the barriers to contribute to a new project at this era which is Git is a winner of VCS share. For that means, I think it's nice goal that WebKit moves Git even if we have been able to clone a repository by git-svn or https://github.com/WebKit/webkit. By contrast, I doubt GitHub or GitLab would reduce a barrier for a new contributor. Every project has some customs and we need to know them on contributing. Especially, large projects have this tendency. As a contributor, there is no difference between learning WebKit scripts and pull requests conventions for each project hosted on GitHub. Personally, for welcome a contributor, it's important that a contributor can access a guide to such custom habit, receive a reviewer's quickly feedback, and easily find a good-first-bug, can access a design guide (This is best but I know it's hard), and etc. For these points, I feel today's WebKit goes positively. Of course, WebKit's testing has a strong habit and bunch of documents about that in trac.webkit.org are complex. However, for example, Ryosuke-san's guide was pretty helpful for me. https://bugs.webkit.org/show_bug.cgi?id=217017. Some WebKit blog's articles related to JSC are nice because they usually talk about design details (I'm a fan of them!). I have not contributed to JSC but they help me with reading code. Overall, as a newcomer contributor, I think WebKit goes positively. To be honest, I think that moving to GitHub cannot mean easily that to be welcome a new contributor. -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Wed, Oct 14, 2020 at 11:12 PM Adrien Destugues wrote: > > > 3. Changelog > > I don’t feel it's a big problem to write ChangeLog file. > > Of course, this is tired thing but I don’t have a strong alternative > > after reading this thread. > > > > However the current `prepare-Changelog` script does not fit with a > > branch -based workflow on Git, I feel. There is a room to polish on > > this Git migration. > > > > For example, I’d like to specify a branch as my working set in my > > local machine, instead of commit or staged changes. > > > > Ordinary, I do these flows but it’s a bit tired…. (if you know more > > good ways, could you tell me!): > > > > 1. Run `prepare-Changelog` > > 2. Format ChangeLog file and remove duplicated entries added by _steps 1_. > > 3. Fuse new changes into a single patch by `git add . && git commit > > --ammend` or `git commit --fixup HEAD && git rebase master -i > > --autosquash` > > 4. Upload patches by `webkit-patch upload -g HEAD` > > > > I don’t have an objection that we merge a squashed patch into trunk to > > simplify the history but we would have some chance to improve the script. > > > > The original goal mentionned at the start of the thread was encouraging > more people to contribute to WebKit. From that side, what's important is > trying to retain a patch submission workflow that's standardized. That can > be github/gitlab style pull requests, or Gerrit which is a different one. > There are probably others. > > If the workflow for submitting patches requires writing a changelog file, > or other similar custom operations, I think that's more likely to turn > potential contributors away (I can only speak for myself, here, of course). > Even if you automate it with a scri
Re: [webkit-dev] WebKit Transition to Git
I feel from this discussion that everybody has their own best way and we’re tackling to resolve them at once in this migration process. I also feel it’s a bit difficult to conclude something. FWIW, I would like to write some my problems about the current workflow to help figure out what is a problem in the current workflow and what we should be resolved in this or other future process. This would not propose an actual solution, but I believe this would help to find a final solution and other people will also say your problems to help. 1. Code review tools WebKit Bugzilla’s code review tool is not a beautiful solution for today. I would like to get a preview for markdown file or syntax highlights. 2. Bug Tracking System I don’t feel a problem to use WebKit Bugzilla, and I doubt that using Bugzilla is really a problem to collect a feedback from the webdev community as other people said in this thread. However, I have some complaints… * I’d like to write markdown as a comment for bugs. * I’d be happy if we triage more bugs. There are a bunch of non-triaged bugs. * Of course, a triage is a complex problem for us if we do it more aggressively because there are at least 2 bug tracking systems, Bugzilla and Apple’s rader… 3. Changelog I don’t feel it's a big problem to write ChangeLog file. Of course, this is tired thing but I don’t have a strong alternative after reading this thread. However the current `prepare-Changelog` script does not fit with a branch -based workflow on Git, I feel. There is a room to polish on this Git migration. For example, I’d like to specify a branch as my working set in my local machine, instead of commit or staged changes. Ordinary, I do these flows but it’s a bit tired…. (if you know more good ways, could you tell me!): 1. Run `prepare-Changelog` 2. Format ChangeLog file and remove duplicated entries added by _steps 1_. 3. Fuse new changes into a single patch by `git add . && git commit --ammend` or `git commit --fixup HEAD && git rebase master -i --autosquash` 4. Upload patches by `webkit-patch upload -g HEAD` I don’t have an objection that we merge a squashed patch into trunk to simplify the history but we would have some chance to improve the script. -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Sat, Oct 3, 2020 at 1:43 AM Jonathan Bedard wrote: > > Hello WebKit Contributors, > > This year, Apple would like to push WebKit’s source code management off of > Subversion and onto git. Our rationale for this is the rest of the industry > has settled on git as their source code management solution. We’re also > interested in moving to a hosted Git solution (namely, GitHub) to make it > easier for new contributors to interact with the project. I would like to > outline our plan so far, and solicit feedback from our contributors about > some of the pieces we’re still discussing. > > Monotonic Commit Identifiers > Of great interest to Apple’s engineers has been retaining some kind of > ordered tag we can use to refer to commits to make defending CI and bisection > easier. We’ve developed a scheme for this that assigns commits an ordered > identifier per-branch, outlined in > https://trac.webkit.org/wiki/commit-identifiers, designed to be used > alongside git hashes. These identifiers can be used in our current Subversion > repository, and we would like to start using them before the project has > transitions to git. > > Hosting the Repository > We're most likely going to be hosting the repository in public GitHub. The > rationale for choosing GitHub over alternatives (namely, GitLab) is that > GitHub has a far more active community, and Apple would like WebKit to be > more connected to the open source community. For this reason, we prefer to > place the canonical WebKit repository on public GitHub so the project is more > accessible to new contributors, although some concerns have been raised about > GitHub’s terms and conditions, which contributors of WebKit would need to > agree to in addition to the terms and conditions of the WebKit project. We > are interested in what our current community of contributors thinks about > this, and what preferences contributors may have. > > Patches to Pull Requests > In the coming months, more automation will start using the git version of the > repository instead of the Subversion version. Even immediately after we > switch, the patch review workflow will remain what it is now (EWS bots mostly > already use a git clone as their checkout). We do, however, intend to switch > from a system of patch review to a system of pull requests. This process will > be incremental and the patch review system will remain alive as long as > Bugzilla does. > > GitHub Issues > The last part of transitioning away from Subversion is to re-evaluate our bug > trac
Re: [webkit-dev] WebKit Transition to Git
I'm not sure about how many people in WebKit watches creating or updating bugs, but I'd like to mention that because this might be a regression if we move from bugzilla. If we move to GitHub Issue, compared to bugzilla, that does not have "component watching". (I don't know the case of GitLab's Issue) We only can watch all issues or not for the repository. Today's GitHub Issue can move an issue to other repositories but I don't see much that some organization hosting a large scale project hosts multiple repositories which corresponds to a _component_ of bugzilla and triage an issue by moving on each repository. Before GitHub implements to move an issue, as my memory, for example Servo project created a bot to watch some specific label and send an email to a subscriber configured by a bot settings to do like bugzilla's component watching. I'm not sure about how many people in WebKit watches creating or updating bugs, but I'd like to mention that because this might be a regression if we move from bugzilla. -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Sat, Oct 3, 2020 at 1:43 AM Jonathan Bedard wrote: > > Hello WebKit Contributors, > > This year, Apple would like to push WebKit’s source code management off of > Subversion and onto git. Our rationale for this is the rest of the industry > has settled on git as their source code management solution. We’re also > interested in moving to a hosted Git solution (namely, GitHub) to make it > easier for new contributors to interact with the project. I would like to > outline our plan so far, and solicit feedback from our contributors about > some of the pieces we’re still discussing. > > Monotonic Commit Identifiers > Of great interest to Apple’s engineers has been retaining some kind of > ordered tag we can use to refer to commits to make defending CI and bisection > easier. We’ve developed a scheme for this that assigns commits an ordered > identifier per-branch, outlined in > https://trac.webkit.org/wiki/commit-identifiers, designed to be used > alongside git hashes. These identifiers can be used in our current Subversion > repository, and we would like to start using them before the project has > transitions to git. > > Hosting the Repository > We're most likely going to be hosting the repository in public GitHub. The > rationale for choosing GitHub over alternatives (namely, GitLab) is that > GitHub has a far more active community, and Apple would like WebKit to be > more connected to the open source community. For this reason, we prefer to > place the canonical WebKit repository on public GitHub so the project is more > accessible to new contributors, although some concerns have been raised about > GitHub’s terms and conditions, which contributors of WebKit would need to > agree to in addition to the terms and conditions of the WebKit project. We > are interested in what our current community of contributors thinks about > this, and what preferences contributors may have. > > Patches to Pull Requests > In the coming months, more automation will start using the git version of the > repository instead of the Subversion version. Even immediately after we > switch, the patch review workflow will remain what it is now (EWS bots mostly > already use a git clone as their checkout). We do, however, intend to switch > from a system of patch review to a system of pull requests. This process will > be incremental and the patch review system will remain alive as long as > Bugzilla does. > > GitHub Issues > The last part of transitioning away from Subversion is to re-evaluate our bug > tracker. Bugzilla has served us well, but seems to be an impediment to > engaging with the open source community. We are interested in moving away > from Bugzilla and to GitHub Issues, allowing new developers to work with a > system they are likely already familiar with and to allow us closer > integration with repositories managed by W3C. Although GitHub Issues has had > performance problems in the past with projects that have many bugs, these > performance problems have been resolved to the satisfaction of a few large > projects hosted on GitHub that are of a comparable scale to WebKit. The > biggest blocker we are aware of is managing security bugs, since the security > advisory system used by GitHub is essentially the opposite of how WebKit > security bugs work. Moving to GitHub Issues, if it happens, will be the last > part of this transition, and we are interested in soliciting feedback from > our contributors on what the WebKit project’s integration with GitHub Issues > should look like. > > Look forward to hearing from all of you, > > Jonathan Bedard > WebKit Operations > ___ > web
Re: [webkit-dev] WebKit Transition to Git
>> I think having to create an account on a website isn't the main thing >> preventing people to contribute anyway? It's more about having to use >> project-specific tools to prepare the patch for submission (in the case >> of WebKit, having to write the commit message in the Changelog file, for >> example). > > It's about all those things. We've definitely heard of people > complaining or refusing to create a Bugzilla account to report bugs. > I've gotta say I'm very much concerned about getting rid of change > logs when we move to Git. We put a lot of useful information about > what was causing the bug, how we fixed it, and why we fixed the way we > did in a change log. I've seen a few projects which transitioned to > Git and somehow lost the rigor in maintaining an equally high quality > commit message, partly because most code review tools don't let you > add inline comments to commit messages. I'd like to tell my feelings about a ChangeLog file other than perspective for code review. As a newbie patch contributor, it's true that ChangeLog file is a *bit* tired when I update a patch. I felt repeatedly that it should be replaced by VCS' commit log to make it easier. On the other hand, ChangeLog file also helps me many times when I dig into the history of WebKit because ChangeLog file contains what functions are removed in which commit with Bugzilla id and sometimes includes detailed reason for changeset. Perhaps it may be just that I don't know the way, VCS (I think here is Git) has a powerful feature to trace when we added codes but it's hard to trace when we removed codes, and it force a tough work to me when I investigate why we introduced this line to fix a bug. By contrast, WebKit's ChangeLog file is helpful to make it easier to trace both of adding ones and removing codes. -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Sat, Oct 3, 2020 at 7:17 PM Ryosuke Niwa wrote: > > On Sat, Oct 3, 2020 at 2:25 AM Adrien Destugues > wrote: > > > > On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote: > > > > I realize that Gerrit might not integrate at all with hosting the repo > > > > on Github, but has any thought been given to this aspect of the > > > > transition? > > > > > > That sounds like it would be a significant barrier to contribution, and > > > frankly defeat the point of switching. If we have serious concerns with > > > GitHub's code review functionality (which, again, I'm not familiar with), > > > then we should just use GitLab and have everything in one place. (GitLab > > > accepts GitHub logins via OAuth, both on gitlab.com and self-hosted > > > instances, so the barrier to contributing remains low either way.) > > > > Gerrit accepts GitHub and other OAuth providers as well, so that's not a > > problem. We have been using this for Haiku code reviews for a few years > > now, and interestingly we got some complaints from people who don't want > > to have a Github account (for various reasons) and won't use our code > > review tool because of that. > > > > I think the integration referred to was rather in terms of having > > reviews synchronized between Gerrit and Github pull requests, which is > > also possible, but I think if the point is to use Github, it doesn't > > work this way: if your workflow is too different from the standard way > > to use Github, people will still be confused by it and it will still be > > a barrier to contribution. > > But using Gerrit would make that situation any better either. > > > I think having to create an account on a website isn't the main thing > > preventing people to contribute anyway? It's more about having to use > > project-specific tools to prepare the patch for submission (in the case > > of WebKit, having to write the commit message in the Changelog file, for > > example). > > It's about all those things. We've definitely heard of people > complaining or refusing to create a Bugzilla account to report bugs. > I've gotta say I'm very much concerned about getting rid of change > logs when we move to Git. We put a lot of useful information about > what was causing the bug, how we fixed it, and why we fixed the way we > did in a change log. I've seen a few projects which transitioned to > Git and somehow lost the rigor in maintaining an equally high quality > commit message, partly because most code review tools don't let you > add inline comments to commit messages. > > - R. Niwa > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
Hi Jonathan, As a contributor, I hear this change positively and I'm looking forward to transition to a new process. I have some questions and feelings: 1. Will we continue to use https://trac.webkit.org/wiki after moving to something to host the Git repository? This is just my curiosity. 2. About GitHub Issues, how will we categorize an issue? I feel GitHub issues require some techniques to manage/categorize a bug when we host a large scale project like a Web Engine on GitHub issues. I think it might be a bit harder than doing with Bugzilla. As my past experiences to collaborate with some projects, Rust and Servo project's label management was nice to categorize issues. https://github.com/rust-lang/rust-wiki-backup/blob/master/Note-tag-label-names-and-definitions.md -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Sat, Oct 3, 2020 at 1:43 AM Jonathan Bedard wrote: > > Hello WebKit Contributors, > > This year, Apple would like to push WebKit’s source code management off of > Subversion and onto git. Our rationale for this is the rest of the industry > has settled on git as their source code management solution. We’re also > interested in moving to a hosted Git solution (namely, GitHub) to make it > easier for new contributors to interact with the project. I would like to > outline our plan so far, and solicit feedback from our contributors about > some of the pieces we’re still discussing. > > Monotonic Commit Identifiers > Of great interest to Apple’s engineers has been retaining some kind of > ordered tag we can use to refer to commits to make defending CI and bisection > easier. We’ve developed a scheme for this that assigns commits an ordered > identifier per-branch, outlined in > https://trac.webkit.org/wiki/commit-identifiers, designed to be used > alongside git hashes. These identifiers can be used in our current Subversion > repository, and we would like to start using them before the project has > transitions to git. > > Hosting the Repository > We're most likely going to be hosting the repository in public GitHub. The > rationale for choosing GitHub over alternatives (namely, GitLab) is that > GitHub has a far more active community, and Apple would like WebKit to be > more connected to the open source community. For this reason, we prefer to > place the canonical WebKit repository on public GitHub so the project is more > accessible to new contributors, although some concerns have been raised about > GitHub’s terms and conditions, which contributors of WebKit would need to > agree to in addition to the terms and conditions of the WebKit project. We > are interested in what our current community of contributors thinks about > this, and what preferences contributors may have. > > Patches to Pull Requests > In the coming months, more automation will start using the git version of the > repository instead of the Subversion version. Even immediately after we > switch, the patch review workflow will remain what it is now (EWS bots mostly > already use a git clone as their checkout). We do, however, intend to switch > from a system of patch review to a system of pull requests. This process will > be incremental and the patch review system will remain alive as long as > Bugzilla does. > > GitHub Issues > The last part of transitioning away from Subversion is to re-evaluate our bug > tracker. Bugzilla has served us well, but seems to be an impediment to > engaging with the open source community. We are interested in moving away > from Bugzilla and to GitHub Issues, allowing new developers to work with a > system they are likely already familiar with and to allow us closer > integration with repositories managed by W3C. Although GitHub Issues has had > performance problems in the past with projects that have many bugs, these > performance problems have been resolved to the satisfaction of a few large > projects hosted on GitHub that are of a comparable scale to WebKit. The > biggest blocker we are aware of is managing security bugs, since the security > advisory system used by GitHub is essentially the opposite of how WebKit > security bugs work. Moving to GitHub Issues, if it happens, will be the last > part of this transition, and we are interested in soliciting feedback from > our contributors on what the WebKit project’s integration with GitHub Issues > should look like. > > Look forward to hearing from all of you, > > Jonathan Bedard > WebKit Operations > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove ENABLE_STREAMS_API compile flag?
There are no objections after 5 business days. I'll start to work this in https://bugs.webkit.org/show_bug.cgi?id=213728 -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Fri, Jun 19, 2020 at 4:21 PM youenn fablet wrote: > > This would be a nice simplification. > > Le ven. 19 juin 2020 à 01:02, Tetsuharu OHZEKI > a écrit : > > > > Hi WebKitten, > > > > As I see the following codes and grep, I seem today's all (?) ports of > > WebKit > > have enabled ENABLE_STREAMS_API flag by default. > > > > - > > https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformEnable.h?rev=263222#L466 > > - > > https://trac.webkit.org/browser/trunk/Source/cmake/OptionsFTW.cmake?rev=263222#L104 > > - > > https://trac.webkit.org/browser/trunk/Source/cmake/OptionsWin.cmake?rev=263222#L58 > > - > > https://trac.webkit.org/browser/trunk/Source/cmake/OptionsMac.cmake?rev=263222#L87 > > - > > https://trac.webkit.org/browser/trunk/Source/cmake/WebKitFeatures.cmake?rev=263222#L210 > > - > > https://trac.webkit.org/browser/trunk/Source/cmake/tools/vsprops/FeatureDefines.props?rev=263222#L276 > > > > If my assumption is right, I'd like to propose to remove this > > `ENABLE_STREAMS_API` flag. > > > > What do you think about this? > > If I missed some ports, please tell me about them. > > > > -- > > Tetsuharu OHZEKI > > tetsuharu.ohz...@gmail.com > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Can we remove ENABLE_STREAMS_API compile flag?
Hi WebKitten, As I see the following codes and grep, I seem today's all (?) ports of WebKit have enabled ENABLE_STREAMS_API flag by default. - https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformEnable.h?rev=263222#L466 - https://trac.webkit.org/browser/trunk/Source/cmake/OptionsFTW.cmake?rev=263222#L104 - https://trac.webkit.org/browser/trunk/Source/cmake/OptionsWin.cmake?rev=263222#L58 - https://trac.webkit.org/browser/trunk/Source/cmake/OptionsMac.cmake?rev=263222#L87 - https://trac.webkit.org/browser/trunk/Source/cmake/WebKitFeatures.cmake?rev=263222#L210 - https://trac.webkit.org/browser/trunk/Source/cmake/tools/vsprops/FeatureDefines.props?rev=263222#L276 If my assumption is right, I'd like to propose to remove this `ENABLE_STREAMS_API` flag. What do you think about this? If I missed some ports, please tell me about them. -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Intent to remove FileError
Hi WebKitten,
I'm not sure that we have a kind of this process,
but I think this mail might be helpful for some developers relying on
this legacy interface.
## Summary
I removed `FileError` as a web-exposed interface.
By this change, `FileReader.error` uses `DOMException` instead.
## Explanation
AFAIK, `FileError` was used in the earlier spec about 10 years ago.
https://www.w3.org/TR/2010/WD-FileAPI-20101026/
And it had been changed to `DOMError` but it was also replaced to
`DOMException` in 2017.
https://github.com/w3c/FileAPI/issues/11
Other browsers followed this spec change several years ago,
but WebKit is still exposing this interface.
* Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1120178
* Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=460725
Thus I removed FileError as a web-exposed interface in bug 213117.
https://bugs.webkit.org/show_bug.cgi?id=213117
I plan to remove internal usages for FileError.{h,cpp} in bug 213119.
https://bugs.webkit.org/show_bug.cgi?id=213119
--
Tetsuharu OHZEKI
tetsuharu.ohz...@gmail.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
