> 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
> 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 contributors to actually fork
> WebKit's repository on their account and then create a pull request
> (which is the
On Sat, Oct 03, 2020 at 08:43:40PM +0300, Konstantin Tokarev wrote:
> >> 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
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,
> Github's code review UI has a couple of feature gaps in my opinion. It's
> difficult to look at earlier versions of the pull request, in particular to
> verify that issues found during code review have been fixed. I remember it
> also being difficult to figure out whether all comments on earlier
>Also, sadly ICU does not maintain a stable API or ABI. So every
>application and library using ICU would need to be rebuilt and updated
>at the same time. Then the update would break any custom software that
>users have using the system ICU. Such an update would go badly...
>I don’t think anyone is arguing that we’d eventually need to move to
>Python3. I’m arguing that it’s not okay to require random WebKit
>contributor to know some obscure python insanity to install Python 3,
>have a script that installs Python 3 and breaks all other python
On Mon, Jun 10, 2019 at 09:37:06AM +0300, Noam Rosenthal wrote:
> ~ (reposting from webkit email)
I should pprobably give a little more context here, as the maintainer of
the WebKitLegacy port for Haiku.
Our main concern, as Rajagopalan mentionned, is that Haiku does not have
We are already in contact and the work will indeed be based on the Haiku fork.
While I can mentor the Haiku side of the project, I think it is a good idea to
rely on you all for the WebKit side of things.
I hope this will allow us toget one second developer working on the Haiku port,
The Haiku ports uses its own implementation of HTTP, relying on the
libraries provided in Haiku for that. We will probably not be switching
back to curl.
However, we have used only WebKitLegacy so far so it is expected that
some parts of our network backend will be missing (everything that
On Sun, Feb 24, 2019 at 10:52:53AM -0800, Sam Weinig wrote:
> Hi Adrien,
> Would you mind adding the compiler output when this happens? I’d like to see
> exactly what the error you are seeing is.
Sorry, here is the compiler output:
In file included from
We are finally starting to look into moving the Haiku port to WebKit2.
We have hit one little problem I'm not sure how to solve. Our pid_t on
32bit Haiku is declared as a signed long integer (this is for legacy
reasons and not something we can fix easily). Our uint32_t is a signed
The commit which restores this may serve as a reference (but may not
apply directly to current sources):
Adrien Destugues / PulkoMandy
eally doesn't support them.
Adrien Destugues / PulkoMandy
webkit-dev mailing list
Mail list logo