[webkit-dev] WebKit Tree Closure - Revised Time Window

2024-02-24 Thread Chris Gibb via webkit-dev
WebKit Tree Closure - Revised Time Window What: WebKit tree closure When: 11pm PT 2/24/2024 until 7am PT 2/25/2024 Impact Affected services: github.com/webkit/webkit The default (main) branch of WebKit will be closed during the above time window. It will not be possible to commit changes to this

Re: [webkit-dev] WebKit Tree Closure

2024-02-23 Thread Jonathan Bedard via webkit-dev
This tree closure has been canceled. ‘main’ will remain open for commits for the duration of 2/23 and 2/24. Thank you for your patience! Jonathan Bedard WebKit Continuous Integration > What: WebKit tree closure > When: 8pm PT 2/23/2024 until 12pm PT 2/24/2024 > > Impact > Affected services: >

[webkit-dev] WebKit Tree Closure

2024-02-23 Thread Chris Gibb via webkit-dev
What: WebKit tree closure When: 8pm PT 2/23/2024 until 12pm PT 2/24/2024 Impact Affected services: github.com/webkit/webkit The default (main) branch of WebKit will be closed during the above time window. It will not be possible to commit changes to this branch during the specified time period.

Re: [webkit-dev] webkit-unassigned

2023-12-18 Thread Michael Catanzaro via webkit-dev
On Mon, Dec 18 2023 at 09:58:14 PM +00:00:00, Alexey Proskuryakov wrote: Are you thinking of scraping Bugzilla? No plans to further limit public access at all (we do have some rate limiting already though, to protect service availability). I don't think that "it's in principle possible to

Re: [webkit-dev] webkit-unassigned

2023-12-18 Thread Alexey Proskuryakov via webkit-dev
> 18 дек. 2023 г., в 1:44 PM, Michael Catanzaro > написал(а): > > On Mon, Dec 18 2023 at 09:16:21 PM +00:00:00, Alexey Proskuryakov > wrote: >> Same thing - limiting the ability to trivially watch for security bugs that >> are initially filed in a wrong component, > > You can currently

Re: [webkit-dev] webkit-unassigned

2023-12-18 Thread Michael Catanzaro via webkit-dev
On Mon, Dec 18 2023 at 09:16:21 PM +00:00:00, Alexey Proskuryakov wrote: Same thing - limiting the ability to trivially watch for security bugs that are initially filed in a wrong component, You can currently follow all public activity on the Bugzilla. Are you planning to limit that too?

Re: [webkit-dev] webkit-unassigned

2023-12-18 Thread Alexey Proskuryakov via webkit-dev
blic mailing list seems good. > > Michael > > > ___ > 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-unassigned

2023-12-18 Thread Michael Catanzaro via webkit-dev
On Mon, Dec 18 2023 at 06:07:48 PM +00:00:00, Alexey Proskuryakov via webkit-dev wrote: I'm still inclined to break the scenario of watching webkit-unassigned. What do others think? I don't think there's any need to disable the ability to watch the Bugzilla account? It shouldn't give anybody

Re: [webkit-dev] webkit-unassigned

2023-12-18 Thread Alexey Proskuryakov via webkit-dev
mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev> ___ webkit-dev mailing list webkit-dev@lists.webkit.org <mai

Re: [webkit-dev] webkit-unassigned

2023-12-15 Thread Fujii Hironori via webkit-dev
. > > - Alexey > > 15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev < > webkit-dev@lists.webkit.org> написал(а): > > I check it every day. Can I receive the same mails by setting my user > watching to webkit-unassig...@lists.webkit.org? > > On Sat, D

Re: [webkit-dev] webkit-unassigned

2023-12-15 Thread Alexey Proskuryakov via webkit-dev
mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev> ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] webkit-unassigned

2023-12-15 Thread Fujii Hironori via webkit-dev
I check it every day. Can I receive the same mails by setting my user watching to webkit-unassig...@lists.webkit.org? On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev < webkit-dev@lists.webkit.org> wrote: > Hello, > > Does anybody make use of the webkit-unassign

[webkit-dev] webkit-unassigned

2023-12-15 Thread Alexey Proskuryakov via webkit-dev
Hello, Does anybody make use of the webkit-unassigned mailing list? I'd like to disable it, to reduce exposure of spam and accidental postings. - Alexey ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] WebKit Documentation

2023-03-15 Thread Simon Fraser via webkit-dev
> On Mar 9, 2023, at 10:48 AM, Brandon Stewart via webkit-dev > wrote: > > Hello, > > Sorry for the delay on the documentation update. > > For getting the documentation system online, we were trying to settle on a > subdomain. > > What would people prefer we use as the official

Re: [webkit-dev] WebKit Documentation

2023-03-15 Thread Carlos Alberto Lopez Perez via webkit-dev
On 09/03/2023 19:48, Brandon Stewart via webkit-dev wrote: > What would people prefer we use as the official documentation location: > (1) docs.webkit.org > (2) developer.webkit.org > (3) documentation.webkit.org > (4) Other +1 for docs.webkit.org (shorter is better)

Re: [webkit-dev] WebKit Documentation

2023-03-13 Thread Adrian Perez de Castro via webkit-dev
Hi all, On Thu, 09 Mar 2023 10:48:27 -0800 Brandon Stewart via webkit-dev wrote: > Sorry for the delay on the documentation update. > For getting the documentation system online, we were trying to settle on a > subdomain. Looking forward to have the documentation online ^_^ > What would

Re: [webkit-dev] WebKit Documentation

2023-03-12 Thread Vitor Ribeiro Roriz via webkit-dev
: Friday, March 10, 2023 at 6:41 AM To: Brandon Stewart Cc: Ling Ho via webkit-dev Subject: Re: [webkit-dev] WebKit Documentation     On Mar 9, 2023, at 10:48 AM, Brandon Stewart via webkit-dev wrote:   Sorry for the delay on the documentation update.   For getting

Re: [webkit-dev] WebKit Documentation

2023-03-12 Thread Brent Fulgham via webkit-dev
Subject: Re: [webkit-dev] WebKit Documentation     On Mar 9, 2023, at 10:48 AM, Brandon Stewart via webkit-dev wrote:   Sorry for the delay on the documentation update.   For getting the documentation system online, we were trying to settle on a subdomain.   What would people

Re: [webkit-dev] WebKit Documentation

2023-03-09 Thread Kirsling, Ross via webkit-dev
I’d vote for (1) since it’s easy to type! Thanks, Ross From: Ryosuke Niwa via webkit-dev Reply-To: Ryosuke Niwa Date: Friday, March 10, 2023 at 6:41 AM To: Brandon Stewart Cc: Ling Ho via webkit-dev Subject: Re: [webkit-dev] WebKit Documentation On Mar 9, 2023, at 10:48 AM, Brandon

Re: [webkit-dev] WebKit Documentation

2023-03-09 Thread Ryosuke Niwa via webkit-dev
>> like the best candidate. It says that new documentation should live there >> instead of being added to Trac. But on the other hand when WebKit >> Documentation was announced some people advocated for keep using the GH Wiki >> but that idea was discarded. I

[webkit-dev] WebKit Documentation using MkDocs

2023-03-09 Thread Brandon Stewart via webkit-dev
Hello, I got feedback that people would prefer not to add Swift as a requirement for building the documentation. Since WebKit relies heavily on Python for large parts of its tooling, I decided to port it over to a popular Python documentation system MkDocs. This provides a few benefits over

Re: [webkit-dev] WebKit Documentation

2023-03-09 Thread Brandon Stewart via webkit-dev
s like WebKit GitHub Wiki is were new documents should be > published until WebKit Documentation site is not available? Please confirm > whether this assumption is correct or not. > > -- > > Diego > > ___ > 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 Documentation

2023-02-28 Thread dpino via webkit-dev
On 9/20/22 05:28, Brandon Stewart via webkit-dev wrote: > Hi WebKit Developers, > > Documentation is an important part of any open source project, especially for > a larger project like WebKit. Being able to ramp up during the onboarding > process, reading up on architectural decisions, and

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

2022-09-30 Thread Elliott Williams via webkit-dev
> On Sep 29, 2022, at 18:54, Ryosuke Niwa via webkit-dev > wrote: > >> Introduction.md is definitely not the right place for much of this, so that >> leaves the GitHub Wiki (which, I might point out, was never discussed as a >> community either, I started it so we could discuss migrating

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

2022-09-29 Thread Ryosuke Niwa via webkit-dev
> On Sep 29, 2022, at 5:26 PM, Jonathan Bedard wrote: > >> On Sep 29, 2022, at 4:28 PM, Ryosuke Niwa wrote: >> >>> On Sep 29, 2022, at 11:48 AM, Jonathan Bedard via webkit-dev >>> mailto:webkit-dev@lists.webkit.org>> wrote: >>> > On Sep 20, 2022, at 1:52 PM, Brent Fulgham

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

2022-09-29 Thread Jonathan Bedard via webkit-dev
> On Sep 29, 2022, at 4:28 PM, Ryosuke Niwa wrote: > > > >> On Sep 29, 2022, at 11:48 AM, Jonathan Bedard via webkit-dev >> mailto:webkit-dev@lists.webkit.org>> wrote: >> >> On Sep 20, 2022, at 1:52 PM, Brent Fulgham >>> > wrote: > On Sep 20,

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

2022-09-29 Thread Ryosuke Niwa via webkit-dev
> On Sep 29, 2022, at 11:48 AM, Jonathan Bedard via webkit-dev > wrote: > > >>> On Sep 20, 2022, at 1:52 PM, Brent Fulgham wrote: >>> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev wrote: > On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev >

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

2022-09-29 Thread Jonathan Bedard via webkit-dev
>> On Sep 20, 2022, at 1:52 PM, Brent Fulgham wrote: >> >>> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev >>> wrote: >>> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev mailto:webkit-dev@lists.webkit.org>> wrote: Documentation is an important part

Re: [webkit-dev] WebKit Documentation

2022-09-21 Thread Ryosuke Niwa via webkit-dev
> On Sep 21, 2022, at 6:50 AM, Michael Catanzaro wrote: > > On Tue, Sep 20 2022 at 08:03:12 PM -0700, Ryosuke Niwa via webkit-dev > wrote: >> (2) is particularly important because many people who are new to WebKit >> often don´t know what they don´t know. This is why, for example, memory

Re: [webkit-dev] WebKit Documentation

2022-09-21 Thread Michael Catanzaro via webkit-dev
On Tue, Sep 20 2022 at 08:03:12 PM -0700, Ryosuke Niwa via webkit-dev wrote: (2) is particularly important because many people who are new to WebKit often don’t know what they don’t know. This is why, for example, memory management section appears towards the beginning of the document and the

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Ryosuke Niwa via webkit-dev
> On Sep 20, 2022, at 1:52 PM, Brent Fulgham wrote: > >> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev >> wrote: >> >>> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev >>> mailto:webkit-dev@lists.webkit.org>> wrote: >>> >>> Documentation is an important part of any

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Brent Fulgham via webkit-dev
> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev > wrote: > > >> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev >> mailto:webkit-dev@lists.webkit.org>> wrote: >> >> Documentation is an important part of any open source project, especially >> for a larger project

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Ryosuke Niwa via webkit-dev
> On Sep 20, 2022, at 6:04 AM, Michael Catanzaro wrote: > > On Tue, Sep 20 2022 at 01:16:53 AM -0700, Ryosuke Niwa via webkit-dev > wrote: >> I´ve been working on >> https://github.com/WebKit/WebKit/blob/main/Introduction.md for the past >> couple of years, and I´d would have preferred to

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Michael Catanzaro via webkit-dev
On Tue, Sep 20 2022 at 01:16:53 AM -0700, Ryosuke Niwa via webkit-dev wrote: I’ve been working on https://github.com/WebKit/WebKit/blob/main/Introduction.md for the past couple of years, and I’d would have preferred to have a collaboration rather than a competition here. This

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Konstantin Tokarev via webkit-dev
> Why not double-down on the GitHub wiki? It's very easy to learn to use, > and there are edit buttons everywhere so there is no "distance" between > the docs and the ability to edit them. The easier it is to edit docs, > the better we'll do at keeping them up to date. > > I like Markdown, and

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Ryosuke Niwa via webkit-dev
> On Sep 19, 2022, at 2:58 PM, Michael Catanzaro via webkit-dev > wrote: > > Why not double-down on the GitHub wiki? It's very easy to learn to use, and > there are edit buttons everywhere so there is no "distance" between the docs > and the ability to edit them. The easier it is to edit

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Ryosuke Niwa via webkit-dev
> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev > wrote: > > Documentation is an important part of any open source project, especially for > a larger project like WebKit. Being able to ramp up during the onboarding > process, reading up on architectural decisions, and learning

Re: [webkit-dev] WebKit Documentation

2022-09-20 Thread Ryosuke Niwa via webkit-dev
> On Sep 19, 2022, at 4:48 PM, Fujii Hironori via webkit-dev > wrote: > > Why not double-down on WebKit Git repository? > The closer the document is to the source code, the easier to keep them > up-to-date. > We can modify both the source code and the document in a single commit > through

Re: [webkit-dev] WebKit Documentation

2022-09-19 Thread Ling Ho via 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] WebKit Documentation

2022-09-19 Thread Fujii Hironori via webkit-dev
Why not double-down on WebKit Git repository? The closer the document is to the source code, the easier to keep them up-to-date. We can modify both the source code and the document in a single commit through our review process. Do you plan to shutdown https://trac.webkit.org/wiki ?

Re: [webkit-dev] WebKit Documentation

2022-09-19 Thread Michael Catanzaro via webkit-dev
Why not double-down on the GitHub wiki? It's very easy to learn to use, and there are edit buttons everywhere so there is no "distance" between the docs and the ability to edit them. The easier it is to edit docs, the better we'll do at keeping them up to date. I like Markdown, and am OK

[webkit-dev] WebKit Documentation

2022-09-19 Thread Brandon Stewart via webkit-dev
Hi WebKit Developers, Documentation is an important part of any open source project, especially for a larger project like WebKit. Being able to ramp up during the onboarding process, reading up on architectural decisions, and learning how to perform common procedures are all features the

Re: [webkit-dev] webkit-changes substitute

2022-08-10 Thread Alexey Proskuryakov via webkit-dev
t; the webkit-changes mailing list? > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______ webkit-dev mailing list webkit-dev@lists.we

[webkit-dev] webkit-changes substitute

2022-08-08 Thread Dan Bernstein via webkit-dev
Hello, Is there some way to receive full webkit commits in email form, similar to the webkit-changes mailing list? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit is now on GitHub

2022-06-27 Thread Alex Christensen via webkit-dev
d. > > Sounds like you already have this under control. > > Michael > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit is now on GitHub

2022-06-23 Thread Michael Catanzaro via webkit-dev
On Thu, Jun 23 2022 at 03:21:59 PM -0700, Jonathan Bedard wrote: I’m aware of the WebKitGTK branches, please reach out about the WPE ones, I’m not sure which ones those are. The WPE releases actually use the WebKitGTK branches! They are shared branches. I suppose that is pretty confusing,

Re: [webkit-dev] WebKit is now on GitHub

2022-06-23 Thread Jonathan Bedard via webkit-dev
I’m aware of the WebKitGTK branches, please reach out about the WPE ones, I’m not sure which ones those are. Absolutely will make sure we’ve migrated everything before delete SVN for good, and there will be plenty of warning before we do anything destructive. Jonathan > On Jun 23, 2022, at

Re: [webkit-dev] WebKit is now on GitHub

2022-06-23 Thread Adrian Perez de Castro via webkit-dev
Hi Michael, On Thu, 23 Jun 2022 16:01:11 -0500 Michael Catanzaro via webkit-dev wrote: > On Thu, Jun 23 2022 at 10:29:55 AM -0700, Jonathan Bedard via > webkit-dev wrote: > > Let me know if there is any fallout, > > As far as I know, WebKitGTK and WPE WebKit stable branches have not yet >

Re: [webkit-dev] WebKit is now on GitHub

2022-06-23 Thread Michael Catanzaro via webkit-dev
On Thu, Jun 23 2022 at 10:29:55 AM -0700, Jonathan Bedard via webkit-dev wrote: Let me know if there is any fallout, As far as I know, WebKitGTK and WPE WebKit stable branches have not yet been migrated and are now read-only? Let's make sure not to delete SVN until we're certain they have

[webkit-dev] WebKit is now on GitHub

2022-06-23 Thread Jonathan Bedard via webkit-dev
r295779 is the last commit to WebKit’s Subversion repository. https://github.com/WebKit/WebKit is now the canonical home of the WebKit project! All commits must now go through Commit-Queue, Merge-Queue or Unsafe-Merge-Queue. For the next few weeks, svn.webkit.org and trac.webkit.org will

Re: [webkit-dev] webkit-patch land behavior change

2022-04-27 Thread Jonathan Bedard via webkit-dev
For now, `webkit-patch land-unsafe` would be the answer. In the future, new contributors would need an existing committer to add the `merge-queue` label to a PR which adds the new contributor to contributors.json Jonathan > On Apr 27, 2022, at 12:16 AM, Manuel Rego Casasnovas wrote: > > >

Re: [webkit-dev] webkit-patch land behavior change

2022-04-27 Thread Manuel Rego Casasnovas via webkit-dev
On 26/04/2022 21:58, Jonathan Bedard via webkit-dev wrote: > As we move closer to transitioning away from Subversion, I’ve change > ‘webkit-patch land’ to use commit-queue instead of directly committing a > local change from a contributor’s machine >

[webkit-dev] webkit-patch land behavior change

2022-04-26 Thread Jonathan Bedard via webkit-dev
Hey folks, As we move closer to transitioning away from Subversion, I’ve change ‘webkit-patch land’ to use commit-queue instead of directly committing a local change from a contributor’s machine (https://github.com/WebKit/WebKit/pull/392). ‘git-webkit land-unsafe’ will allow contributors to

Re: [webkit-dev] WebKit and GitHub Update

2022-04-12 Thread Michael Catanzaro via webkit-dev
I guess I should create a feedback issue: https://bugs.webkit.org/show_bug.cgi?id=239124 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit and GitHub Update

2022-04-12 Thread Michael Catanzaro via webkit-dev
On Mon, Apr 11 2022 at 03:55:36 PM -0700, Jonathan Bedard via webkit-dev wrote: start creating some pull requests! Hi, For pull requests to find interested reviewers, we need a way to subscribe to labels. E.g. I want to receive notifications for pull requests with a WebKitGTK or WPE label.

[webkit-dev] WebKit and GitHub Update

2022-04-11 Thread Jonathan Bedard via webkit-dev
It is now the time to start widespread testing of pure git checkouts for WebKit. Commit queue has been reimplemented for GitHub, so you don't need a Subversion or git-svn checkout for changes to trunk/main that aren’t modifying SVN properties. Over the past few months, we’ve been working on

Re: [webkit-dev] WebKit Style: Whitespace for Objective-C protocols

2022-03-02 Thread Myles Maxfield via webkit-dev
I’ve posted a patch to make these changes official: https://bugs.webkit.org/show_bug.cgi?id=237406 > On Feb 24, 2022, at 9:09 AM, Darin Adler wrote: > > I personally prefer id, and would be happy to standardize on > that. I don’t really care that much about statistics about usage in our >

Re: [webkit-dev] WebKit Style: Whitespace for Objective-C protocols

2022-02-24 Thread Darin Adler via webkit-dev
I personally prefer id, and would be happy to standardize on that. I don’t really care that much about statistics about usage in our existing code. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] WebKit Style: Whitespace for Objective-C protocols

2022-02-23 Thread Kimmo Kinnunen via webkit-dev
ng annoying you? Or would the spacing help you > understand that Baz is a protocol but Bar is supplied as a generic type? > Maybe the * characters already make that clear? > > What should the style guide say here? > > Thanks, > Myles > __

[webkit-dev] WebKit Style: Whitespace for Objective-C protocols

2022-02-21 Thread Myles Maxfield via webkit-dev
Hello! I was working on a patch recently where I wanted to give an Objective-C variable a type of “id that conforms to protocol Foo.” Should this be spelled like this: id myVariable Or like this: id myVariable I don’t see anything about this in the WebKit style guide

Re: [webkit-dev] WebKit Objective-C++ style, pointer and reference placement

2021-12-21 Thread Michael Catanzaro via webkit-dev
On Tue, Dec 21 2021 at 02:08:42 PM +0200, Kimmo Kinnunen via webkit-dev wrote: * All C and Objective-C code should be formatted with rules consistent to the C++ rules Unfortunately all of the WPE/GTK C code intentionally uses a space between the type and the asterisk * (for example,

[webkit-dev] WebKit Objective-C++ style, pointer and reference placement

2021-12-21 Thread Kimmo Kinnunen via webkit-dev
Currently we have this: https://webkit.org/code-style-guidelines/#pointers-and-references Pointers and References Pointer types in non-C++ code Pointer types should be written with a space between the type and the * (so the *

[webkit-dev] WebKit SVN tree clousures (April 2021)

2021-03-26 Thread Ling Ho via webkit-dev
Hello WebKit, One of the infrastruture maintenance works that was planned for early March has been rescheduled for the weekend starting April 2nd. Our critical continuous integration services (EWS, post-commit bots, etc.) will be unavailable during: *Begin*: Friday, April 2nd, 2021. 5pm

[webkit-dev] WebKit SVN tree clousures (March 2021)

2021-02-24 Thread Ling Ho via webkit-dev
Hello WebKit, Due to planned infrastructure maintenance, our critical continuous integration services (EWS and post-commit bots) will be unavailable during the following weekends: *Dates*: *Begin*: Friday, March 5th, 2021. 5pm (PST) *End*: Monday, March 8th, 2021. No later than 6pm (PST)

Re: [webkit-dev] Webkit MediaRecorder Timeslice functionality on Safari 14.0.2 Mojave

2021-02-01 Thread youenn fablet via webkit-dev
by default. On the most recent BigSur and iOS versions, MediaRecorder should be enabled by default and timeslice should be supported. Hope this helps, Y Le lun. 1 févr. 2021 à 17:29, Gallery via webkit-dev < webkit-dev@lists.webkit.org> a écrit : > Hi Folks > > We are develop

[webkit-dev] Webkit MediaRecorder Timeslice functionality on Safari 14.0.2 Mojave

2021-02-01 Thread Gallery via webkit-dev
Hi Folks We are developing a streaming system which uses MediaRecorder with timeslice. It's clear that Safari only has MediaRecorder as developer experiment, and that older versions of Safari dont support timeslice anyway. However, a recent WebKit thread

[webkit-dev] WebKit SVN Tree clousure (Dec 23, 2020 - Jan 5, 2021)

2020-12-10 Thread Ling Ho via webkit-dev
Hello WebKit, Some of our critical continuous integration services will be unavailable due to planned underlying infrastructure maintenance. Most EWS and post-commit bots will be down, so we will be closing the WebKit SVN tree to avoid accumulating difficult to diagnose regressions during

[webkit-dev] WebKit SVN Tree clousure (Nov 22nd - Nov 26th, 2020)

2020-11-11 Thread Ling Ho via webkit-dev
Hello WebKit, Some of our critical continuous integration services will be unavailable due to planned underlying infrastructure maintenance. Most EWS and post-commit bots will be down, so we will be closing the WebKit SVN tree to avoid accumulating difficult to diagnose regressions during

Re: [webkit-dev] WebKit Transition to Git

2020-10-28 Thread Maciej Stachowiak
> On Oct 13, 2020, at 2:37 PM, Konstantin Tokarev wrote: > > > > 13.10.2020, 22:33, "Maciej Stachowiak" : >>> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro >>> wrote: >>> >>> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand wrote: Would you also consider preventing merge commits

Re: [webkit-dev] WebKit Transition to Git

2020-10-16 Thread Fujii Hironori
According to this Jonathan's bugzilla comment, a new git repository will be reconstructed. https://bugs.webkit.org/show_bug.cgi?id=214957#c12 It'd be nice if commit-qu...@webkit.org is replaced by real authors. ___ webkit-dev mailing list

Re: [webkit-dev] WebKit Transition to Git

2020-10-16 Thread Tetsuharu OHZEKI
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

Re: [webkit-dev] WebKit Transition to Git

2020-10-15 Thread Konstantin Tokarev
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

Re: [webkit-dev] WebKit Transition to Git

2020-10-14 Thread Tetsuharu OHZEKI
> 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

Re: [webkit-dev] WebKit Transition to Git (Merge Workflows)

2020-10-14 Thread Jonathan Bedard
To point something out with the squash merge vs rebase merge policies, we will definitely be enforcing squash merges at least initially because rebase merges require some extra EWS and commit-queue infrastructure. Recall that WebKit does regression testing for every commit, even if these

Re: [webkit-dev] WebKit Transition to Git

2020-10-14 Thread Adrien Destugues
> 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

Re: [webkit-dev] WebKit Transition to Git

2020-10-14 Thread Tetsuharu OHZEKI
> 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] WebKit Transition to Git

2020-10-13 Thread Ken Russell
On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev wrote: > > > 13.10.2020, 22:33, "Maciej Stachowiak" : > >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro > wrote: > >> > >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand > wrote: > >>> Would you also consider preventing merge commits in

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Manuel Rego Casasnovas
On 14/10/2020 03:12, Ken Russell wrote: > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev > wrote: > 1. Workflow 1 - "Squash merge" policy > > * Whole PR is considered to be a single atomic change of WebKit > source tree. If work is supposed to be

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 4:12 PM Konstantin Tokarev wrote: > > > > 14.10.2020, 02:01, "Ryosuke Niwa" : > > On Tue, Oct 13, 2020 at 3:53 PM Konstantin Tokarev > > wrote: > >> 14.10.2020, 01:45, "Ryosuke Niwa" : > >> > On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev > >> wrote: > >> >>

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Konstantin Tokarev
14.10.2020, 02:01, "Ryosuke Niwa" : > On Tue, Oct 13, 2020 at 3:53 PM Konstantin Tokarev wrote: >>  14.10.2020, 01:45, "Ryosuke Niwa" : >>  > On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev >> wrote: >>  >> 14.10.2020, 01:30, "Ryosuke Niwa" : >>  >> > On Tue, Oct 13, 2020 at 2:37 PM

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 3:53 PM Konstantin Tokarev wrote: > > > 14.10.2020, 01:45, "Ryosuke Niwa" : > > On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev > > wrote: > >> 14.10.2020, 01:30, "Ryosuke Niwa" : > >> > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev > >> wrote: > >> >>

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 3:19 PM Michael Catanzaro wrote: > > Detailed descriptions are very important. I don't think function-level > changelogs are; documenting changes in individual functions is > generally busywork to say what you can plainly see by just looking at > the diff. They certainly

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Konstantin Tokarev
14.10.2020, 01:45, "Ryosuke Niwa" : > On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev wrote: >>  14.10.2020, 01:30, "Ryosuke Niwa" : >>  > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev >> wrote: >>  >> 13.10.2020, 22:33, "Maciej Stachowiak" : >>  >> >> On Oct 2, 2020, at 10:59 AM,

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev wrote: > > 14.10.2020, 01:30, "Ryosuke Niwa" : > > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev > > wrote: > >> 13.10.2020, 22:33, "Maciej Stachowiak" : > >> >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro > >> wrote: > >> >> > >>

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 3:19 PM Michael Catanzaro wrote: > > I suppose what I'm describing is Konstantin's Workflow 2, which is > overwhelmingly popular. > > On Tue, Oct 13, 2020 at 2:19 pm, Ryosuke Niwa wrote: > > Not squashing only helps if each commit can stand on its own. At that > > point,

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Konstantin Tokarev
14.10.2020, 01:30, "Ryosuke Niwa" : > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev wrote: >>  13.10.2020, 22:33, "Maciej Stachowiak" : >>  >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro >> wrote: >>  >> >>  >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand >> wrote: >>  >>> Would

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev wrote: > > > 13.10.2020, 22:33, "Maciej Stachowiak" : > >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro > >> wrote: > >> > >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand wrote: > >>> Would you also consider preventing merge commits

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Michael Catanzaro
I suppose what I'm describing is Konstantin's Workflow 2, which is overwhelmingly popular. On Tue, Oct 13, 2020 at 2:19 pm, Ryosuke Niwa wrote: Not squashing only helps if each commit can stand on its own. At that point, I'd suggest such a sequence of commits be made into multiple PRs

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Konstantin Tokarev
13.10.2020, 22:33, "Maciej Stachowiak" : >>  On Oct 2, 2020, at 10:59 AM, Michael Catanzaro wrote: >> >>  On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand wrote: >>>  Would you also consider preventing merge commits in order to keep a >>>  clean mainline branch? >> >>  Big +1 to blocking merge

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 1:57 PM Michael Catanzaro wrote: > > On Tue, Oct 13, 2020 at 12:32 pm, Maciej Stachowiak > wrote: > > I’m assuming your objection is to regular merges, but how do you > > feel about squash merges? Or do you think all PRs should be landed by > > rebasing? > > If we want a

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Michael Catanzaro
On Tue, Oct 13, 2020 at 12:32 pm, Maciej Stachowiak wrote: I’m assuming your objection is to regular merges, but how do you feel about squash merges? Or do you think all PRs should be landed by rebasing? If we want a linear history (we do), all PRs ultimately have to land as fast-forward

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Maciej Stachowiak
ount 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

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Maciej Stachowiak
ub will make this worse. > That's not an issue with the GitHub platform, though. Just something to stay > on top of. > > Michael > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Michael[tm] Smith
Adrian Perez de Castro , 2020-10-08 00:49 +0300: > ... > Also with Git{Hub,Lab} it's an annoyance that one has to go through the web > interface to create a “pull request”. But it’s not hard to create tooling that completely eliminates the need to ever use the GitHub web UI to create pull

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Adrian Perez de Castro
On Tue, 06 Oct 2020 11:15:05 -0700 Jonathan Bedard wrote: > Seems like most large projects are using some sort of bot or action to solve > this problem: https://github.com/isaacs/github/issues/581 > . Wow, “there's a bot for that” seems to be the

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Adrian Perez de Castro
Hi there, There is one more annoyance I am adding below Konstantin's list… On Tue, 06 Oct 2020 03:13:32 +0300 Konstantin Tokarev wrote: > 05.10.2020, 23:41, "Yusuke Suzuki" : > > I think security component is special in terms of how to handle it already > > (e.g. not posting a test with the

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Adrian Perez de Castro
On Sun, 04 Oct 2020 02:00:02 +0300 Konstantin Tokarev wrote: > 03.10.2020, 21:49, "Adrien Destugues" : > > Yes that's why I didn't elaborate much. Whichever tool you pick, there > > will always be people unhappy about it. > > Right. For example, I have negative bias against GitLab, because

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Adrian Perez de Castro
Hello, On Fri, 02 Oct 2020 13:48:56 -0700 Ken Russell wrote: > Excited about this migration! One comment inline. > > On Fri, Oct 2, 2020 at 9:43 AM Jonathan Bedard wrote: > > > *Patches to Pull Requests* > > In the coming months, more automation will start using the git version of > > the

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Adrian Perez de Castro
Hello, On Sun, 04 Oct 2020 01:57:56 -0700 Yusuke Suzuki wrote: > GitHub is planning to have review revisions in 2020/Q4. > So, when WebKit repository is migrated, we already have that in GitHub > builtin review tool :) > > https://github.com/github/roadmap/issues/54 >

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Adrian Perez de Castro
Hi, On Tue, 06 Oct 2020 03:42:11 +0300 Konstantin Tokarev wrote: > 05.10.2020, 13:26, "Frédéric Wang" : > > One thing to take into account is that WebKit's repository is big and > > public GitHub/GitLab prevent creating large repository by default. This > > means it might not be possible for

  1   2   3   4   5   6   7   8   9   10   >