Re: A reminder about commit messages: they should be useful

[Alexander Surkov]

On Tuesday, April 18, 2017 at 6:53:14 PM UTC-4, smaug wrote:
> On 04/18/2017 04:24 PM, Ehsan Akhgari wrote:
> > On 2017-04-18 12:30 AM, Mike Hommey wrote:
> >>> I've yet to see that to happen. What is crucial is fast way to browse
> >>> through the blame in time. So commit messages should be short and
> >>> descriptive. Telling what and why. (I very often need to go back to CVS 
> >>> era
> >>> code). I won't spend time reading several paragraphs of commit messages.
> >>> Those are just too long.
> >>> Basically first line should tell the essentials 'what' and maybe the most 
> >>> obvious 'why' and the next couple of lines explaining 'why' more 
> >>> precisely.
> >>> Don't write stories which will make blame-browsing slower.
> >>
> >> What sort of blame-browsing makes more than the first line of the commit
> >> message a burden? I'm curious, because that doesn't match my use of
> >> blame.
> >
> > I can't say I have had this issue, and I also do a lot of code
> > archaeology as well.  I suppose to a large extent this does depend on
> > what tools you use, perhaps.  These days I use searchfox.org for a lot
> > of blame browsing that I do, which displays only the first line in the
> > default UI and only displays the full commit message when you look at
> > the full commit.  I find this a pretty good balance.
> >
> >> And I've done my share of archeology and for old enough stuff you often
> >> end up with one of:
> >> - a completely useless commit message *and* useless bug (if there's even
> >>   a bug number)
> >> - a mostly useless commit message and some information in the bug.
> >>   You're lucky if it's all contained in a few sentences.
> >> - a mostly useless commit message and tons of information in the bug,
> >>   that you have to spend quite some time parsing through.
> >>
> >> In *all* cases, you have to go switch between your blame and bugzilla.
> >> It's a PITA. Now, when you have everything in VCS, you just work with
> >> your blame. Obviously, CVS-era commits are not going to change, but do
> >> you really want to keep things in the same state for commits done now,
> >> when you (or someone else) goes through blame in a few years?
> >
> > Agreed.
> >
> > Also even for newer code you often end up in the third category.  Maybe
> > it's just me but I spend a lot of time reading old bugs, and I find it a
> > huge time sink to read through tons of comments just to find where the
> > actual discussion about why the fix was done in the way that it was done
> > happened in the bug.  Sometimes I have to really read 100+ comments.
> > And the sad reality is that all too often I find very questionable
> > things in patches happen in bugs without any discussion whatsoever which
> > means that sometimes one can spend half an hour reading those 100+
> > comments very carefully to find out in the end that they have just
> > wasted their time and the bug actually did not contain the interesting
> > information in the first place.
> >
> > I think I would probably sympathize more with the side of the argument
> > arguing for bugs as the source of the truth if this wasn't really true,
> > but I think part of the reason why people don't bother writing good
> > commit messages is that they assume that the reasons behind the
> > approaches they take and the design decisions and the like are obvious,
> > and while that may be true *now* and to them and the code reviewer, it
> > will not be true to everyone and in the future, and because of that if
> > you're not careful the important information is just not captured
> > anywhere.  I hope we can all agree that it's important that we capture
> > this information for the maintainability of our code, even if we can't
> > agree where the information needs to be captured.  :-)
> >
> 
> The important part of documentation should be in code comments, not commit 
> messages.
> We aren't too good commenting code.
> 
> 
> Another thing, today I was looking at a bug which has several patches, and 
> realized one can't really understand the big picture by looking at commit 
> messages of some particular commit. There needs to be some centralized place 
> for that, and it is the bug. Going through each patches individually and 
> looking at the commit messages would be really painful way to see what and 
> why was changed.

As a guy who stayed with Mozilla for a while, here's my two cents. I thumb up 
for Olli's descriptive short what and why commit messages in favor to long 
stories stretched over multiple patches. I'm also keen on going to the bug for 
details if a commit doesn't look quite clear with me.

I realize that bugs might be of thousands of comments, which makes them hard to 
read, but that's probably a case of bugs organization: one meta and several 
small dependent bugs might help here. I don't want to affirm that this approach 
suites every Mozilla module, but it seems be working well in relatively small 
modules like accessibility one.
___

Re: A reminder about commit messages: they should be useful

[Alexander Surkov]

On Tuesday, April 25, 2017 at 11:11:28 AM UTC-4, Boris Zbarsky wrote:
> On 4/25/17 10:50 AM, Alexander Surkov wrote:
> > I don't want to affirm that this approach suites every Mozilla module, but 
> > it seems be working well in relatively small modules like accessibility one.
> 
> Just as a counterpoint... as non-regular contributor to the 
> accessibility module, I have a _very_ hard time making sense of 
> accessibility commits, precisely because the commit messages are not 
> often not very descriptive and the bugs are often hard to make sense of 
> for a non-expert.
> 
> I don't have this problem in cases where I'm similarly out of my depth 
> but commit messages contain more information.

I bet there's always room for improvements, and I hope this was a counterpoint 
for the example only, not for the bug organization approach.

Overall it feels with me that long comments vs check-the-bug is rather 
different styles, with their own benefits and disadvantages, and different 
people prefer one over another one.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: A reminder about commit messages: they should be useful

[Alexander Surkov]

On Tuesday, April 25, 2017 at 1:20:29 PM UTC-4, Boris Zbarsky wrote:
> On 4/25/17 1:07 PM, Alexander Surkov wrote:
> > I bet there's always room for improvements, and I hope this was a 
> > counterpoint for the example only, not for the bug organization approach.
> 
> Sort of.
> 
> It was a counterpoint to "just check the bug; all the info is there". 
> Often it's not there, or not there in usable form.
> 
> If people included a summary of the discussion in the bug right about 
> when they commit, or had bugs that actually explained what's going on 
> clearly. I would be a lot more OK with the "check the bug" approach.
> 
> > Overall it feels with me that long comments vs check-the-bug is rather 
> > different styles
> 
> To be clear, I don't think commit messages need to be _long_.  They need 
> to be _useful_.  A commit message pointing to a particular bug comment 
> that explains all the ins and outs is no worse, from my point of view, 
> than a commit message that explains the ins and outs.
> 
> The problem I started this thread to address is things like a commit 
> message that says "flip this bit" and references a bug entitled "flip 
> this bit", with no explanation of what the bit does or why it should be 
> flipped.  I hope we can all agree that _that_ is not OK.  And it's far 
> too common.
> 
> -Boris

Maybe we should have a style guide, explaining what makes a good commit message 
and what makes a good and descriptive bug, with number of (good and bad) 
examples.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ARIA membership and role="password"

[Alexander Surkov]

Hi, Jonathan.

As far as I can tell, no one in Mozilla is super active in ARIA
nowadays; I personally (among others I think) skim through ARIA email
threads and provide occasional feedback on feature by feature basis.

One of reasons keeping me off I think is I'm worried about direction
taken in ARIA 1.1, which looks with me as to turn ARIA into universal
markup language for web page semantics description, so that ARIA
vocabulary can be used to describe whole HTML and more. I feel like
every single feature from HTML gets added to ARIA eventually, and I
not always convinced that each requested feature has a real use case
on the web. I expressed these worries, but my voice probably wasn't
strong enough to turn the wheel back.

So I'm not confident about role='password' too. While I don't have
strong objections, but I never heard the web authors complaining about
the missing feature. I would say if we do have strong concerns, and
cannot negotiate with the group to keep the feature off the spec, then
it shouldn't mean we have to implement the feature in Gecko. After all
if the feature doesn't get two implementation, then it gets removed
from the spec afaik.

Thanks.
Alexander.

On Thu, Jun 2, 2016 at 8:55 AM, Jonathan Kingston  wrote:
> Hey,
>
> So I was just informed that Mozilla isn't a member of the ARIA working group
> which shocked me, we have however had a hand in the spec over the years (I
> have cc'd those mentioned).
>
> I notice over the years some disappointment with the spec as it being a
> separate module to semantics in HTML itself however I don't see a real
> opposition not to be in the group. This seems more of a formality when the
> group split into two working groups.
>
> It appears that ARIA 1.1 is moving to be resolved in the next few weeks so
> if we had any objections we would need to move now I have been told.
>
> role="password" has been added to the spec:
> https://rawgit.com/w3c/aria/master/aria/aria.html#password and I jotted my
> objections in a post:
> https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/
>
> My post was largely dismissed in this mail:
> https://lists.w3.org/Archives/Public/public-aria/2016May/0126.html
>
> Is it worth us joining? Can we discuss the wider use of ARIA itself? Rushing
> to standardise features seems a shame.
>
> Thanks
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the XUL grid implementation

[Alexander Surkov]

On Friday, April 24, 2020 at 1:34:25 PM UTC-4, Tim Nguyen wrote:
> Hello folks,
> 
> After a year of work, all XUL grid usages have been removed from Firefox!
> The Thunderbird team also has been doing a lot of hard work on their side.
> 
> This means the XUL grid implementation can now be removed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1525737
> 
> I'm planning to remove the XUL grid implementation at the beginning of the
> Firefox 78 cycle to leave time to address potential regressions from the last
> removal  and for the
> Thunderbird team to remove their last usage
> .
> 
> Thanks to everyone who reviewed my grid removal patches and to Daniel
> Holbert and Emilio Cobos Àlvarez for the platform work that made this
> possible!
> 
> Please let me know if you have any questions or concerns.
> 
> Cheers,
> Tim

Great piece of work! Glad to hear you managed to take it down.
Alex.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype HTML:inert

[Alexander Surkov]

/Summary/: HTML:inert is attribute that reflects inert subtree concept 
(https://html.spec.whatwg.org/multipage/interaction.html#inert-subtrees). 
It helps to solve a bunch problem on the web including accessibility 
ones. For example, it allows to create hidden but accessible content on 
a web page. See explainer with more examples 
(https://github.com/WICG/inert/blob/master/explainer.md).


/Bug/: https://bugzilla.mozilla.org/show_bug.cgi?id=921504

/Standard/: https://github.com/whatwg/html/pull/4288 (not yet merged, 
awaits for the second implementation)


/Platform coverage/: web

/Preference/: html5.inert.enabled (please let me know if there's a 
better match)


/DevTools bug/: no extra effort should be required

/Other browsers/:

* Chrome shipped behind a flag (May 2017, 
https://bugs.chromium.org/p/chromium/issues/detail?id=692360)


/web-platform-tests/: 
https://searchfox.org/mozilla-central/source/testing/web-platform/meta/inert


/Secure contexts/: no concerns to the best of my knowledge

/Is this feature enabled by default in sandboxed iframes?/ yes


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform