[webkit-dev] Recovering admin password for webkit-gtk mailing list

[Gustavo Noronha Silva]

Hey,

It looks like we lost the password for the administrative interface for
the webkit-gtk mailing list. Could we get it resent to the admins or
reset?

Thanks!

-- 
Gustavo Noronha Silva 
GNOME Project

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[Ryosuke Niwa]

Hi Alex,

I think this refactoring makes a lot of sense.  This is very close to
what I wanted to do with MathML four years ago so I'm very happy to
hear that you're taking the initiative here.

- R. Niwa

On Wed, Dec 9, 2015 at 3:35 AM, Alejandro Garcia Castro  wrote:
>
> Hi,
>
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
>
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community.  If so, we will start pushing the initial patches from our
> branch to upstream.
>
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
>
>- Reduce code complexity: Adapting FlexBox layout (which is already
>  complex) in order to create the MahtML layout made the code too
>  complex, a big technical debt that made the improvement of MathML
>  more difficult every day.
>
>- Avoid just another FlexBox dependent code: When we had to add
>  general layout alignment support we had a lot of problems trying
>  to solve some the MathML issues because it was not clear how it
>  worked with the FlexBox.
>
>- Improve performance: We do not need all the features FlexBox
>  layout adds for most of the MathML blocks but we are executing
>  all that code. We also can simplify the render tree structures
>  that were created to make the FlexBox layout work.
>
>- Make easier to improve the MathML implementation: Using
>  independent renderer classes gives more flexibility to get exact
>  positioning and spacing required to get high-quality math
>  rendering based on TeX rules and the OpenType MATH table.  (cf
>  http://www.mathml-association.org/MathMLinHTML5/)
>
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
>
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
>
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
>
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
>keep the RenderTree structure. This is basically done, and we just
>need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
>created to make FlexBox work and all the code that it was
>required. We already have the Fractions and Underover implemented
>and the code is much clearer. This will break the tests relying on
>a PNG image or a render tree reference. Hence we will do it also
>per renderer and rebasing the tests after each commit.
>
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
>
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
>
> Greetings,
>
> Alex
> ___
> 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] Use the 'EasyFix' and 'GoodFirstBug' Bugzilla keywords to mentor WebKit newcomers!

[Brian Burg]

Hello WebKittens,

At the WebKit contributors meeting, we held a session to brainstorm ways to 
increase the size of the WebKit community.
(You can see our notes on the wiki: 
http://trac.webkit.org/wiki/November%202015%20Meeting 
)

One thing that we really liked about some other projects, particularly Mozilla 
projects such as Servo, Rust, and Firefox,
is that there are bugs explicitly marked as being “Easy” or a “Good First Bug” 
in Bugzilla. I think we should try this.

Here are some reasons why this works well (and what we should try to emulate):

- Bugs are flagged by experienced contributors who are familiar with the 
feature or component in question. Identifying
a good place to start is a big deal: in practice, most Bugzilla instances are 
chockfull of stale, misleading, or outright wrong
bug reports and tasks, and WebKit’s Bugzilla is no exception. Even if 
components and bugs were always current, there
are simply thousands of real, actionable tasks which are hard for new 
contributors to judge without domain expertise.
In WebKit’s Bugzilla instance, we are going to use the GoodFirstBug and EasyFix 
keywords to track such bugs.

Once some mentored bugs exist, we may want to think about setting up a gateway 
like Bugs Ahoy! to make searching easier.

- Every bug marked GoodFirstBug or EasyFix has a designated “bug mentor” who 
can help a new contributor get up to speed.
There is a lot of process to be learned to fix even a trivial bug: getting the 
code, building, making changes, writing tests,
creating and uploading a patch, going through review, and getting changes in 
the tree. In my experience, new folks are happy
to read and write code, but are easily discouraged from finishing a patch 
because of these barriers. A mentor helps coach
and encourage a new contributor through these parts of the process. Some 
Bugzilla instances have a field for this; for
now, just ensure a mentor (you or someone else) is CC’d and responsive to 
questions from the contributor on Bugzilla.

- A potential fix for a good first bug should be straightforward, described in 
Bugzilla, and be covered by new or existing tests.
This allows a new contributor to achieve a development feedback loop as to 
whether their changes have correct behavior without
requiring extra effort on the part of mentors. It also educates and instills 
good habits, like writing tests alongside (or even before!) making changes.

- Patches from new contributors are reviewed quickly and regularly. Getting 
quick feedback is essential to retaining interest
and momentum, especially for contributors without an economic motivation (i.e, 
a job) or long-term history with the project.
Feedback should be actionable and constructive. It’s much better to mark a 
patch as review- unless it’s ready to land, than to
let a patch linger with open questions and the review? flag set. This 
discourages new contributors since the next step is unclear.

Remember, good first bugs serve primarily as an introduction to the process of 
contributing code changes, so they may not
be particularly interesting to an experienced contributor. Ramping up new 
contributors takes time and effort, but it’s worth it.


Have any questions? Feel free to respond, find us on #webkit IRC, or contact 
myself or Jon Davis.

-Brian

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[Zalan Bujtas]

It’s great to hear that MathML is getting some proper cleanup. I think the 
proposal sounds good and I am looking forward to the patches. 

Minor observation: I noticed that, since MathML block is no longer a flexbox, 
but it still needs some of the flexbox functionality, the following pattern has 
been introduced to the generic renderbox/block code. 
-if (parent()->isFlexibleBox()) {
+if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
I just wish there was another way to handle this.

Zalan.

> On Dec 9, 2015, at 3:35 AM, Alejandro Garcia Castro  wrote:
> 
> 
> Hi,
> 
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
> 
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community.  If so, we will start pushing the initial patches from our
> branch to upstream.
> 
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
> 
>   - Reduce code complexity: Adapting FlexBox layout (which is already
> complex) in order to create the MahtML layout made the code too
> complex, a big technical debt that made the improvement of MathML
> more difficult every day.
> 
>   - Avoid just another FlexBox dependent code: When we had to add
> general layout alignment support we had a lot of problems trying
> to solve some the MathML issues because it was not clear how it
> worked with the FlexBox.
> 
>   - Improve performance: We do not need all the features FlexBox
> layout adds for most of the MathML blocks but we are executing
> all that code. We also can simplify the render tree structures
> that were created to make the FlexBox layout work.
> 
>   - Make easier to improve the MathML implementation: Using
> independent renderer classes gives more flexibility to get exact
> positioning and spacing required to get high-quality math
> rendering based on TeX rules and the OpenType MATH table.  (cf
> http://www.mathml-association.org/MathMLinHTML5/)
> 
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
> 
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
> 
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
> 
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
>   keep the RenderTree structure. This is basically done, and we just
>   need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
>   created to make FlexBox work and all the code that it was
>   required. We already have the Fractions and Underover implemented
>   and the code is much clearer. This will break the tests relying on
>   a PNG image or a render tree reference. Hence we will do it also
>   per renderer and rebasing the tests after each commit.
> 
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
> 
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
> 
> Greetings,
> 
> Alex
> ___
> 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] MathML layout refactor proposal

[Frédéric WANG]

Le 14/12/2015 19:39, Zalan Bujtas a écrit :
> It’s great to hear that MathML is getting some proper cleanup. I think the 
> proposal sounds good and I am looking forward to the patches. 
>
> Minor observation: I noticed that, since MathML block is no longer a flexbox, 
> but it still needs some of the flexbox functionality, the following pattern 
> has been introduced to the generic renderbox/block code. 
> -if (parent()->isFlexibleBox()) {
> +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> I just wish there was another way to handle this.
>
> Zalan.
Alex will correct me if I'm wrong, but I think the changes in RenderBox
are just a temporary solution to avoid breaking tests while we continue
to rewrite the MathML layout code. Hopefully, these won't be needed
anymore when we are done.

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[Alejandro Garcia Castro]

On Mon, Dec 14, 2015 at 08:03:12PM +0100, Frédéric WANG wrote:
> Le 14/12/2015 19:39, Zalan Bujtas a écrit :
> > It’s great to hear that MathML is getting some proper cleanup. I think the 
> > proposal sounds good and I am looking forward to the patches. 
> >
> > Minor observation: I noticed that, since MathML block is no longer a 
> > flexbox, but it still needs some of the flexbox functionality, the 
> > following pattern has been introduced to the generic renderbox/block code.  
> >
> > -if (parent()->isFlexibleBox()) {
> > +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> > I just wish there was another way to handle this.
> >
> > Zalan.
> Alex will correct me if I'm wrong, but I think the changes in RenderBox
> are just a temporary solution to avoid breaking tests while we continue
> to rewrite the MathML layout code. Hopefully, these won't be needed
> anymore when we are done.
> 

Exactly, we need those to keep the width and height overrides working
like the flexbox did. This is the way layouts such us the flexbox or
the grid can force sizes in the children even if they do not request
it. Until we remove the old nodes structure in every renderer we have
to keep it, but I think we can remove all of them because MathML is
not a general layout so we control every layout and we can change its
size based on what their parent sets, even if that means using the
size of a sibling.

Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[Javier Fernandez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 12/14/2015 08:03 PM, Frédéric WANG wrote:
> Le 14/12/2015 19:39, Zalan Bujtas a écrit :
>> It’s great to hear that MathML is getting some proper cleanup. I 
>> think the proposal sounds good and I am looking forward to the 
>> patches.
>> 
>> Minor observation: I noticed that, since MathML block is no 
>> longer a flexbox, but it still needs some of the flexbox 
>> functionality, the following pattern has been introduced to the 
>> generic renderbox/block code. -if
>> (parent()->isFlexibleBox()) { +if (parent()->isFlexibleBox()
>> || parent()->isRenderMathMLBlock()) { I just wish there was
>> another way to handle this.
>> 
>> Zalan.
> Alex will correct me if I'm wrong, but I think the changes in 
> RenderBox are just a temporary solution to avoid breaking tests 
> while we continue to rewrite the MathML layout code. Hopefully, 
> these won't be needed anymore when we are done.
> 

Fred is totally right. That's just legacy code from the old Flexbox
functionality, which we had to adopt temporary in order to keep
passing the current layout tests. We won't need it anymore in the new
layout logic.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZvKusACgkQoNRbE6zycrm/QACeMthQoiPUoVL7KBBLn1c9+irj
1SQAnj4703KlHyMnsxLzKDmMSN8KW5wJ
=MBbI
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev