Hello Jonathan,
Probably you are aware of that but
https://github.com/WebKit/WebKit#contribute /
https://webkit.org/contributing-code/ still mentions the ChangeLogs and
old workflow.
Le 16/05/2022 à 22:46, Jonathan Bedard via webkit-dev a écrit :
Starting tomorrow, Tuesday May 17th, WebKit
On Mon, Apr 25, 2022 at 9:49 AM Jonathan Bedard via webkit-dev
wrote:
>
> .. or robust solution. Bots need maintenance and intervention, and a bot with
> commit access has another set of issues. Repository admins occasionally
> rotating ChangeLogs is going to be less expensive than a bot doing
> It seems to me that you can write a script that just applies a patch while
> ignoring changes to each change log file, then separately prepend each
> change log entry. I don't see why such a script would behave differently
> for reverting multiple commits or rebasing a feature onto a branch. In
I spent some time discussing this offline with Yusuke to better understand his
proposal.
It sounds like Yusuke’s proposal is:
1. Have a separate COMMIT_MESSAGE file as part of the PR
2. When the merge queue commits the PR, it uses that COMMIT_MESSAGE content as
commit log message and then drops
I am strongly in favor of dropping the ChangeLog files and relying on the GIT
commit message instead. Not having to update ChangeLog files was actually a big
motivator for me to switch to GitHub, as I thought until now we didn’t have to
update ChangeLog files when switching Github PRs.
With
On Tue, Apr 19, 2022 at 9:33 AM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:
>
> > To: Jonathan Bedard
> > Cc: WebKit Development
> > Subject: Re: [webkit-dev] ChangeLog Deprecation Plans
> > Message-ID:
> > <
cabnrm
>> Commit message is tied to a commit, so editing commit without breaking
>> commit-message is hard (how to revert one change from one commit without
>> rewriting commit message? It requires some git hack). Separate independent
>> COMMIT_MESSAGE file can solve this problem and makes local
> Message: 2
> Date: Mon, 18 Apr 2022 10:33:03 -0700
> From: Ryosuke Niwa
> To: Jonathan Bedard
> Cc: WebKit Development
> Subject: Re: [webkit-dev] ChangeLog Deprecation Plans
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
>
&g
> On Apr 18, 2022, at 5:38 PM, Michael Catanzaro wrote:
>
>
> On Mon, Apr 18 2022 at 02:55:08 PM -0700, Yusuke Suzuki
> wrote:
>> I think this is important. We are using commit message / ChangeLog as a
>> document tied to the change, and we are writing very detailed description to
>> make
On Mon, Apr 18, 2022 at 18:50 Fujii Hironori via webkit-dev <
webkit-dev@lists.webkit.org> wrote:
>
> On Tue, Apr 19, 2022 at 6:55 AM Yusuke Suzuki via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
>> I think this is important. We are using commit message / ChangeLog as a
>> document tied
I think we need both of these things, and I don't think they should be mutually
exclusive. Having motivation/design/details/gotchas go into a "changelog"
accompanying a commit is very useful when blaming code.
- Saam
> On Apr 18, 2022, at 6:49 PM, Fujii Hironori via webkit-dev
> wrote:
>
>
On Tue, Apr 19, 2022 at 6:55 AM Yusuke Suzuki via webkit-dev <
webkit-dev@lists.webkit.org> wrote:
> I think this is important. We are using commit message / ChangeLog as a
> document tied to the change, and we are writing very detailed description
> to make the intention / design of the change
On Mon, Apr 18 2022 at 02:55:08 PM -0700, Yusuke Suzuki
wrote:
I think this is important. We are using commit message / ChangeLog as
a document tied to the change, and we are writing very detailed
description to make the intention / design of the change clear and
making it as a good
> On Apr 18, 2022, at 12:51 PM, Michael Catanzaro via webkit-dev
> wrote:
>
> On Mon, Apr 18 2022 at 08:30:04 AM -0700, Jonathan Bedard via webkit-dev
> wrote:
>> 2) We need a way to comment on commit messages in review
>> Current tooling sets the pull request description as the commit
On Mon, Apr 18, 2022 at 13:34 Ryosuke Niwa wrote:
>
> On Mon, Apr 18, 2022 at 08:30 Jonathan Bedard via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
>> As we migrate WebKit from Subversion to git, I would like to migrate the
>> project away from ChangeLogs. The reason for this is that
On Mon, Apr 18 2022 at 08:30:04 AM -0700, Jonathan Bedard via
webkit-dev wrote:
2) We need a way to comment on commit messages in review
Current tooling sets the pull request description as the commit
message, “Quote Reply” kind of provides a way to inline comment,
although it’s not the
On Mon, Apr 18, 2022 at 8:30 AM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:
> As we migrate WebKit from Subversion to git, I would like to migrate the
> project away from ChangeLogs. The reason for this is that ChangeLogs make
> some of the features of git hard to use,
On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
carlo...@webkit.org wrote:
El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió:
Hi,
[...]
Separately, I'd like to know whether people liked the new
El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org
wrote:
On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
carlo...@webkit.org wrote:
El mié, 21-08-2013 a las 14:04 -0700,
+1 for the old format.
-F
On Aug 21, 2013, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org
wrote:
On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia
On Wed, Aug 21, 2013 at 11:11 PM, Carlos Garcia Campos
carlo...@webkit.orgwrote:
El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org
wrote:
On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
I see, I thought ChangeLog parser was used everywhere. So, I guess the
solution would be to find a format most people like and adapt all
scripts to it. I personally think it's not worth it, though. The oneline
git
El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
I see, I thought ChangeLog parser was used everywhere. So, I guess the
solution would be to find a format most people like and adapt all
scripts to it. I
On 2013-08-22, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:
El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
I see, I thought ChangeLog parser was used everywhere. So, I guess the
solution
From the new format, I like the shorter bug URL and the angle brackets, but I
don't care much either way about putting the bug URL and title on the same
line.
One downside though is that, if you're composing a ChangeLog more manually,
it's more awkward to construct the new-style URL since you
On Aug 22, 2013, at 12:48 AM, Mark Rowe mr...@apple.com wrote:
On 2013-08-22, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:
El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org
wrote:
I see, I
On Aug 22, 2013, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:
El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
I see, I thought ChangeLog parser was used everywhere. So, I guess the
On Wed, Aug 21, 2013 at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
I have noticed that the change log format has recently been changed.
Unfortunately, this didn't work well with all webkitpy tools we have, and
has been rolled out in http://trac.webkit.org/changeset/154406.
*I
On Aug 21, 2013, at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
Separately, I'd like to know whether people liked the new format and it's
worth my time making webkitpy adopt the new format.
I personally didn't like the old format because it made the first line of
each change log too
I’m a bit of a luddite and edit my change log entries by hand.
The old format is more amenable to this, the new format is a regression.
cheers,
G.
On Aug 21, 2013, at 2:25 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 21, 2013 at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
I
El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió:
Hi,
[...]
Separately, I'd like to know whether people liked the new format and
it's worth my time making webkitpy adopt the new format.
I prefer the old format.
I personally didn't like the old format because it made the first
On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
carlo...@webkit.orgwrote:
El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió:
Hi,
[...]
Separately, I'd like to know whether people liked the new format and
it's worth my time making webkitpy adopt the new format.
I
Run
WebKitTools/Scripts/resolve-ChangeLogs
each time you rebase.
PS: try webkit-patch help --all-commands, from that same directory;
in particular webkit-patch post-commits automates attaching your
patch to a bug.
On Tue, Feb 23, 2010 at 1:27 PM, arno a...@renevier.net wrote:
Hi,
I've
On Tue, Feb 23, 2010 at 4:27 AM, arno a...@renevier.net wrote:
Hi,
I've recently submitted a few patches.
My workflow is as follow:
I use git repository.
Once I've made my modifications, I run WebKitTools/Scripts/prepare-ChangeLog,
then I git-commit changeset in a private branch, then I
On 23/2/10 13:31 , Evan Martin wrote:
Run
WebKitTools/Scripts/resolve-ChangeLogs
each time you rebase.
Or run once:
git config merge.changelog.driver resolve-ChangeLogs --merge-driver %O
%A %B
tor arne
___
webkit-dev mailing list
On Jul 3, 2009, at 10:44 AM, Jeremy Orlow wrote:
I agree that the ChangeLog really is duplicate information [...]
The WebKit project change log was inspired by GNU project change logs:
http://www.gnu.org/prep/standards/html_node/Change-Logs.html.
I don’t like ChangeLog specifically.
My
On Fri, Jul 3, 2009 at 10:55 AM, Darin Adler da...@apple.com wrote:
It's backwards to say that the ChangeLog is a workaround for lack of tools.
Some day we may see a tool that works so well that we’d be willing to forgo
change logs, but we need to see that tool in action first to see that it
To be more clear: Rietveld + gcl (the way Chromium does reviews/checkins)
has you specify a group of files which is called a change list. Part of
each change list is a description. Reviewers use and critique this
description, which is much like what's done with the ChangeLog.
Nothing lists out
On Jul 3, 2009, at 12:04 PM, Jeremy Orlow wrote:
Nothing lists out the modified functions like in your ChangeLog, but
I guess that's just not something people commonly need.
I often search for old relevant changes by searching for function
names. At least once a week for the last 5 years.
On Fri, Jul 3, 2009 at 12:29 PM, Darin Adler da...@apple.com wrote:
On Jul 3, 2009, at 12:04 PM, Jeremy Orlow wrote:
Nothing lists out the modified functions like in your ChangeLog, but I
guess that's just not something people commonly need.
I often search for old relevant changes by
Darin Adler wrote:
My experience on other projects that don’t use ChangeLog is that many
check-ins don’t have clear comments or descriptions, and the fact that
these are missing is considerably easier to overlook. Source code
control comments can be tricky if you can never delete or edit them.
On Jul 3, 2009, at 12:29 PM, Darin Adler wrote:
On Jul 3, 2009, at 12:04 PM, Jeremy Orlow wrote:
Nothing lists out the modified functions like in your ChangeLog,
but I guess that's just not something people commonly need.
I often search for old relevant changes by searching for function
Maciej Stachowiak wrote:
I'm not sure why making an extra copy of the info on update is better
than doing it on checkin. People update their tree more often than they
commit, so prima facie this seems like a backwards way to do it. Also,
svn2cl is much slower than a one-time copy of the latest
On Friday, July 3, 2009 1:01:33 PM, Joe Mason wrote:
Even if sticking with svn, you just need to run svn2cl once when
you update to get a local copy of the changelog.
If each developer had to run that command to get a local changelog, I can't
imagine the svn server would be very
44 matches
Mail list logo
