EWW bugs should be fixed on emacs-25 branch

EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

Lars,

It seems that you've fixed a large number of bugs in EWW, but you did
that on master.  That is a mistake, please cherry-pick the
corresponding changesets to emacs-25, and in the future fix bugs on
emacs-25, unless the fix has some potentially dangerous parts or
requires infrastructure that is only available on master.

We want the upcoming Emacs 25.1 to have all these bugs fixed.

Thanks.

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> Date: Fri, 25 Dec 2015 09:52:16 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> please cherry-pick the corresponding changesets to emacs-25

Oh, and when you do that, please mention "backport" in the commit
message, so that these commits won't be merged back to master.

Thanks.

Re: EWW bugs should be fixed on emacs-25 branch

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 25 Dec 2015 09:52:16 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> please cherry-pick the corresponding changesets to emacs-25
>
> Oh, and when you do that, please mention "backport" in the commit
> message, so that these commits won't be merged back to master.

Commits created with "git cherry-pick" are considered equivalent with
the original for Git with regard to merge histories.  Whatever Git
itself does for checking them in that manner should likely be part of
the manual procedures for "merging back to master", possibly by using
only commits mentioned in "git log --cherry-pick ...".

That way, we need not rely on manual additions to the commit message.

-- 
David Kastrup

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 09:26:46 +0100
> 
> Commits created with "git cherry-pick" are considered equivalent with
> the original for Git with regard to merge histories.  Whatever Git
> itself does for checking them in that manner should likely be part of
> the manual procedures for "merging back to master", possibly by using
> only commits mentioned in "git log --cherry-pick ...".
> 
> That way, we need not rely on manual additions to the commit message.

Actually, I was talking about what git-merge.el does.

Re: EWW bugs should be fixed on emacs-25 branch

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> That way, we need not rely on manual additions to the commit message.
> Actually, I was talking about what git-merge.el does.

I'm wondering then if git-merge.el is doing the wrong thing. I'll need to take
a deeper look at it to see if that is the case.

In general, Git handles "not duplicating work you've cherry-picked into a
branch" quite well.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: David Kastrup <dak@gnu.org>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 08:58:31 -0800
> 
> In general, Git handles "not duplicating work you've cherry-picked into a
> branch" quite well.

AFAIK, Git doesn't track cherry-picks in the DAG.

Re: EWW bugs should be fixed on emacs-25 branch

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> In general, Git handles "not duplicating work you've cherry-picked into a
>> branch" quite well.

> AFAIK, Git doesn't track cherry-picks in the DAG.

What it does track are "patch ids", that is, the SHA of the diff represented
by a given commit against its parent:

    https://www.kernel.org/pub/software/scm/git/docs/git-patch-id.html

This allows the merging algorithm to know whether it's attempting to bring in
a change that has already been seen on the target branch.

  "git cherry can compare a branch with its upstream branch and find which
  commits have been upstreamed and which haven’t. This command is particularly
  clever because, thanks to git patch-id, it can correctly spot when a commit
  has been upstreamed, even when the upstreaming process resulted in changes
  to the commit message, line numbers, or whitespace."

    (from http://blog.adamspiers.org/2013/09/19/easier-upstreaming-with-git/)

So the theory is, you _should_ be able to cherry pick commits from one branch
to another, and then act as though it never happened with respect to merging.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: dak@gnu.org,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 09:23:44 -0800
> 
> > AFAIK, Git doesn't track cherry-picks in the DAG.
> 
> What it does track are "patch ids", that is, the SHA of the diff represented
> by a given commit against its parent:
> 
>     https://www.kernel.org/pub/software/scm/git/docs/git-patch-id.html
> 
> This allows the merging algorithm to know whether it's attempting to bring in
> a change that has already been seen on the target branch.

Since what Git version?

>   "git cherry can compare a branch with its upstream branch and find which
>   commits have been upstreamed and which haven’t. This command is particularly
>   clever because, thanks to git patch-id, it can correctly spot when a commit
>   has been upstreamed, even when the upstreaming process resulted in changes
>   to the commit message, line numbers, or whitespace."
> 
>     (from http://blog.adamspiers.org/2013/09/19/easier-upstreaming-with-git/)

How does "git cherry" enter the picture?  We were talking about
cherry-pick and merge commands.

Re: EWW bugs should be fixed on emacs-25 branch

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> What it does track are "patch ids", that is, the SHA of the diff represented
>> by a given commit against its parent:
>> 
>> https://www.kernel.org/pub/software/scm/git/docs/git-patch-id.html> 
>> This allows the merging algorithm to know whether it's attempting to bring in
>> a change that has already been seen on the target branch.

> Since what Git version?

That's a command since 2.6, but the concept has been there for years.  I've
run into this while doing heavy-duty, daily merge work on other projects.

> How does "git cherry" enter the picture? We were talking about cherry-pick
> and merge commands.

Oops, misread when I injected that link. But it should still be relevant for
merging.

Anyway, I guess what I mean to say is: I think gitmerge.el might be trying to
do things that Git itself would handle for us.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: dak@gnu.org,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 11:55:43 -0800
> 
> Anyway, I guess what I mean to say is: I think gitmerge.el might be trying to
> do things that Git itself would handle for us.

Maybe so, but better be safe than sorry.  Given the number of times I
saw Git experts here make mistakes about what does and doesn't work, I
will trust gitmerge.el and our experience more than I trust what we
think we know about Git.  Also, gitmerge.el should DTRT no matter
which version of Git is installed (I hear that some systems still have
Git 1.7.1 or something like that).

Re: EWW bugs should be fixed on emacs-25 branch

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Maybe so, but better be safe than sorry. Given the number of times I saw Git
> experts here make mistakes about what does and doesn't work, I will trust
> gitmerge.el and our experience more than I trust what we think we know about
> Git. Also, gitmerge.el should DTRT no matter which version of Git is
> installed (I hear that some systems still have Git 1.7.1 or something like
> that).

I suppose then that I would like to understand exactly what gitmerge.el is
adding to the picture. I've managed some pretty crazy merge scenarios as a
contractor, and it never required building custom merging tools before.

So we run the opposite risk of people "just using gitmerge.el", but not
understanding what is actually happening. If it works for you, that's great;
but if I properly understand what is being done, then I can find a workflow
that might suit me better.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: dak@gnu.org,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 12:09:10 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe so, but better be safe than sorry. Given the number of times I saw Git
> > experts here make mistakes about what does and doesn't work, I will trust
> > gitmerge.el and our experience more than I trust what we think we know about
> > Git. Also, gitmerge.el should DTRT no matter which version of Git is
> > installed (I hear that some systems still have Git 1.7.1 or something like
> > that).
> 
> I suppose then that I would like to understand exactly what gitmerge.el is
> adding to the picture. I've managed some pretty crazy merge scenarios as a
> contractor, and it never required building custom merging tools before.

How about taking a look at the code (it's only 500-odd lines)?  Maybe
also try it -- e.g., merge emacs-25 with master in your sandbox, just
to see how it feels.  I think that will provide a much better answer
than I could ever hope to give.

> So we run the opposite risk of people "just using gitmerge.el", but not
> understanding what is actually happening.

When you run GDB via the Emacs front-end, do you understand what
happens behind the scenes to make all these nice gdb-ui windows
possible?  I bet you don't, because _a_lot_ is going on that you don't
see, and will never understand unless you are an expert in GDB/MI
interface Emacs uses and in GDB itself.

That's what Emacs front-ends (or any front-ends) do: they allow you to
know less about the details and still be productive and avoid
mistakes.

> If it works for you, that's great; but if I properly understand what
> is being done, then I can find a workflow that might suit me better.

You are encouraged to understand what's going on, but please do make a
point of using gitmerge.el when merging between Emacs development
branches.  We don't want to risk people making mistakes if they can be
avoided.

Thanks.

Re: EWW bugs should be fixed on emacs-25 branch

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> How about taking a look at the code (it's only 500-odd lines)? Maybe also
> try it -- e.g., merge emacs-25 with master in your sandbox, just to see how
> it feels. I think that will provide a much better answer than I could ever
> hope to give.

I did read it, but I will have to give it a try.

> When you run GDB via the Emacs front-end, do you understand what happens
> behind the scenes to make all these nice gdb-ui windows possible? I bet you
> don't, because _a_lot_ is going on that you don't see, and will never
> understand unless you are an expert in GDB/MI interface Emacs uses and in
> GDB itself.

Maybe a bad example, because using GDB directly is exactly what I do most of
the time, so that I do know it's direct connection with the Emacs UI . :)

> You are encouraged to understand what's going on, but please do make a point
> of using gitmerge.el when merging between Emacs development branches. We
> don't want to risk people making mistakes if they can be avoided.

OK, but once I understand what exactly is being done, there may in fact be
better ways to do it.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: dak@gnu.org,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 12:44:16 -0800
> 
> > When you run GDB via the Emacs front-end, do you understand what happens
> > behind the scenes to make all these nice gdb-ui windows possible? I bet you
> > don't, because _a_lot_ is going on that you don't see, and will never
> > understand unless you are an expert in GDB/MI interface Emacs uses and in
> > GDB itself.
> 
> Maybe a bad example, because using GDB directly is exactly what I do most of
> the time, so that I do know it's direct connection with the Emacs UI . :)

I very much doubt that you interact with GDB in GDB/MI.  Most
probably, you use CLI, which is a different language and a different
interpreter in GDB.

> > You are encouraged to understand what's going on, but please do make a point
> > of using gitmerge.el when merging between Emacs development branches. We
> > don't want to risk people making mistakes if they can be avoided.
> 
> OK, but once I understand what exactly is being done, there may in fact be
> better ways to do it.

If there are better ways, we should improve gitmerge.el to use them.

Re: EWW bugs should be fixed on emacs-25 branch

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I very much doubt that you interact with GDB in GDB/MI. Most probably, you
> use CLI, which is a different language and a different interpreter in GDB.

Ah, true enough.

>> OK, but once I understand what exactly is being done, there may in fact be
>> better ways to do it.

> If there are better ways, we should improve gitmerge.el to use them.

Ok, that sounds like a good idea.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: EWW bugs should be fixed on emacs-25 branch

[David Engster]

John Wiegley writes:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> How about taking a look at the code (it's only 500-odd lines)? Maybe also
>> try it -- e.g., merge emacs-25 with master in your sandbox, just to see how
>> it feels. I think that will provide a much better answer than I could ever
>> hope to give.
>
> I did read it, but I will have to give it a try.

gitmerge.el will detect cherry-picks through the cherry-mark. However,
since git is the C++ of version control, this works only 99% of the
time. It does not work when the cherry-pick could not be applied
cleanly, since then the patch-id changes. It also does not work when the
same commit is also merged later (see the beginning of the emacs-25
branch for an example, where first a bunch of commits was cherry-picked
and later 'master' was also merged).

-David

Having a custom merge process (was: EWW bugs should be fixed on emacs-25 branch)

[John Wiegley]

>>>>> David Engster <deng@randomsample.de> writes:

> gitmerge.el will detect cherry-picks through the cherry-mark. However, since
> git is the C++ of version control, this works only 99% of the time. It does
> not work when the cherry-pick could not be applied cleanly, since then the
> patch-id changes. It also does not work when the same commit is also merged
> later (see the beginning of the emacs-25 branch for an example, where first
> a bunch of commits was cherry-picked and later 'master' was also merged).

OK, that's understandable. What I'd like to avoid -- as much as feasible -- is
having so much of a custom merge process, apart from what most other projects
using Git do, that it becomes difficult to teach newcomers about our process.

I've used Git in many scenarios, on many projects, but some of the practices
we're using here for Emacs development I've never seen before. This simply
makes me wonder how much of that difference is truly necessary, or is a result
of having evolved to this point from CVS and then Bazaar.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Having a custom merge process

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> I've used Git in many scenarios, on many projects, but some of the practices
> we're using here for Emacs development I've never seen before. This simply
> makes me wonder how much of that difference is truly necessary, or is a result
> of having evolved to this point from CVS and then Bazaar.

I think the latter is probably true.  There are many people here who
aren't that fond of git.  (I'm one of them.  :-))  And that's probably
somewhat unusual, these days.

But as I see it, other projects just accept gits many, many
peculiarities and live with them, but in the Emacs toolchain we've (I
mean, not me; I had nothing to do with it) tried to create a layer of
sanity and reliability over the gittishness...

Hey!  It's time for a new 500+ article VC thread!

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Having a custom merge process

[David Engster]

Lars Ingebrigtsen writes:
> John Wiegley <jwiegley@gmail.com> writes:
>
>> I've used Git in many scenarios, on many projects, but some of the practices
>> we're using here for Emacs development I've never seen before. This simply
>> makes me wonder how much of that difference is truly necessary, or is a result
>> of having evolved to this point from CVS and then Bazaar.
>
> I think the latter is probably true.  There are many people here who
> aren't that fond of git.  (I'm one of them.  :-))  And that's probably
> somewhat unusual, these days.
>
> But as I see it, other projects just accept gits many, many
> peculiarities and live with them, but in the Emacs toolchain we've (I
> mean, not me; I had nothing to do with it) tried to create a layer of
> sanity and reliability over the gittishness...
>
> Hey!  It's time for a new 500+ article VC thread!

Nah, this script does not really have much to do with Git. We had pretty
much the same script for Bazaar, I just rewrote it. The main point is
still that you want to do a full merge of 'emacs-25', but you want to
skip the content of certain commits along the way (in other words: you
want to use the merge strategy 'ours' for those commits). Git does not
directly support this, and neither did Bazaar. At least Git can often
detect cherry-picks, but as I've written, it sometimes fails, and not
every commit we want to skip is a backport.

The usual way to deal with this is to have one person who does the
merges ("the Merge Master"), who needs to have a good overview of
development and the used VCS and hence simply knows what to do. The
point of gitmerge.el is that pretty much anyone should be able to do the
merge.

-David

Re: Having a custom merge process

[John Wiegley]

>>>>> David Engster <deng@randomsample.de> writes:

> The usual way to deal with this is to have one person who does the merges
> ("the Merge Master"), who needs to have a good overview of development and
> the used VCS and hence simply knows what to do. The point of gitmerge.el is
> that pretty much anyone should be able to do the merge.

I'll make a point of getting comfortable with gitmerge.el this weekend, since
I will be acting as that "Merge Master" so others can focus on emacs-25.
However, the ability for others to pick up the process easily is a definite
bonus.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Having a custom merge process

[Paul Eggert]

David Engster wrote:
> The usual way to deal with this is to have one person who does the
> merges ("the Merge Master"), who needs to have a good overview of
> development and the used VCS and hence simply knows what to do. The
> point of gitmerge.el is that pretty much anyone should be able to do the
> merge.

For what it's worth, I've done git merges for Emacs both with gitmerge.el and 
without, and although gitmerge.el is nicer it's not clear that it's worth the 
trouble. That is, it should be OK to use gitmerge.el to merge, and it should 
also be OK to not use it. Either way, you need to know what you're doing.

Re: Having a custom merge process

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 26 Dec 2015 00:40:24 +0100
> 
> John Wiegley <jwiegley@gmail.com> writes:
> 
> > I've used Git in many scenarios, on many projects, but some of the practices
> > we're using here for Emacs development I've never seen before. This simply
> > makes me wonder how much of that difference is truly necessary, or is a result
> > of having evolved to this point from CVS and then Bazaar.
> 
> I think the latter is probably true.  There are many people here who
> aren't that fond of git.  (I'm one of them.  :-))  And that's probably
> somewhat unusual, these days.

But the merge policies and what gitmerge.el does (and bzrmerge.el did
before it) were defined by people who are neither non-lovers of Git
nor are prisoners of the CVS-like way of thinking.  Those policies are
determined by the project needs first and foremost, not by what the
tools can or cannot do well.

So I don't see how this conclusion could be right.

But again, without having a list of "surprising" practices, it's hard
to reason about this.

> Hey!  It's time for a new 500+ article VC thread!

Yes.  Long time no seen.

Re: Having a custom merge process (was: EWW bugs should be fixed on emacs-25 branch)

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 15:35:30 -0800
> 
> >>>>> David Engster <deng@randomsample.de> writes:
> 
> > gitmerge.el will detect cherry-picks through the cherry-mark. However, since
> > git is the C++ of version control, this works only 99% of the time. It does
> > not work when the cherry-pick could not be applied cleanly, since then the
> > patch-id changes. It also does not work when the same commit is also merged
> > later (see the beginning of the emacs-25 branch for an example, where first
> > a bunch of commits was cherry-picked and later 'master' was also merged).
> 
> OK, that's understandable. What I'd like to avoid -- as much as feasible -- is
> having so much of a custom merge process, apart from what most other projects
> using Git do, that it becomes difficult to teach newcomers about our process.

Newcomers are told to use gitmerge.el, so how that could be a problem?

Eventually, what gitmerge.el does is invoke "git merge" to merge
ranges of commits that were selected in a semi-automatic way; see
gitmerge-apply.  There's nothing mysterious or magic in that command
that I could spot; I don't even think that it's a particularly
advanced way of doing merges with Git.  Just more or less standard
stuff.

> I've used Git in many scenarios, on many projects, but some of the practices
> we're using here for Emacs development I've never seen before. This simply
> makes me wonder how much of that difference is truly necessary, or is a result
> of having evolved to this point from CVS and then Bazaar.

Can you point out those practices that surprised you?

EWW To Elpa? Re: Having a custom merge process

[raman]

Given that EWW is a relatively stand-alone package, should it also be
available via elpa  -- in addition to being bundled? 

This would allow bug-fixes etc to perculate faster to end-users --
rather than coupling EWW to the Emacs launch train.

Asking specifically because recent fixes have only landed in Master --
not the 25.1 branch, and at this point, there are things in 25.1 that
are not in Master -- so even for those building from git@head, it's hard
to get all the goodness in one build.
-- 

Re: EWW To Elpa? Re: Having a custom merge process

[Lars Ingebrigtsen]

raman <raman@google.com> writes:

> Given that EWW is a relatively stand-alone package, should it also be
> available via elpa  -- in addition to being bundled? 

No, that would make eww much more awkward to develop.  Making a package
usable in one single environment (well, two with a release branch and
trunk) is way, way, way less work than making it work over a larger
range of environments.

> Asking specifically because recent fixes have only landed in Master --
> not the 25.1 branch, and at this point, there are things in 25.1 that
> are not in Master -- so even for those building from git@head, it's hard
> to get all the goodness in one build.

Well, the mergings from 25.1 to the trunk should happen more frequently
from now on, according to rumblings on this mailing list...  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: EWW To Elpa? Re: Having a custom merge process

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On 26 Dec 2015 3:51 pm, "Lars Ingebrigtsen" <larsi@gnus.org> wrote:
>
> raman <raman@google.com> writes:
>
> > Given that EWW is a relatively stand-alone package, should it also be
> > available via elpa  -- in addition to being bundled?
>
> No, that would make eww much more awkward to develop.  Making a package
> usable in one single environment (well, two with a release branch and
> trunk) is way, way, way less work than making it work over a larger
> range of environments.

Elpa packages don't have to target a large range of environments. They can
be aimed at just the latest stable.

[-- Attachment #2: Type: text/html, Size: 817 bytes --]

Re: EWW To Elpa? Re: Having a custom merge process

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Elpa packages don't have to target a large range of environments. They can
> be aimed at just the latest stable.

Correct, and given that, I think "core ELPA" is the right place for a package
like EWW.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: EWW To Elpa? Re: Having a custom merge process

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On 26 Dec 2015 3:00 pm, "raman" <raman@google.com> wrote:
>
> Given that EWW is a relatively stand-alone package, should it also be
> available via elpa  -- in addition to being bundled?

I think it can be made available as a :core elpa package (this means it
would still be developed in Emacs core, and automatically made available in
elpa by the scripts).
As far as eww is concerned, we would only have to add a Package-Requires
header and bump the version number once in a while.

[-- Attachment #2: Type: text/html, Size: 602 bytes --]

Re: EWW To Elpa? Re: Having a custom merge process

[raman]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

That would be nice!> On 26 Dec 2015 3:00 pm, "raman" <raman@google.com> wrote:
>>
>> Given that EWW is a relatively stand-alone package, should it also be
>> available via elpa -- in addition to being bundled?
>
> I think it can be made available as a :core elpa package (this means it would still be developed in Emacs core, and automatically made available in elpa by the scripts).
> As far as eww is concerned, we would only have to add a Package-Requires header and bump the version number once in a while.
>
>

-- 

Re: Having a custom merge process (was: EWW bugs should be fixed on emacs-25 branch)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Newcomers are told to use gitmerge.el, so how that could be a problem?

There is no file gitmerge.el in the Emacs release.  Where is gitmerge.el
distributed?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Having a custom merge process (was: EWW bugs should be fixed on emacs-25 branch)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: jwiegley@gmail.com, larsi@gnus.org, deng@randomsample.de,
> 	emacs-devel@gnu.org
> Date: Sat, 26 Dec 2015 21:52:30 -0500
> 
>   > Newcomers are told to use gitmerge.el, so how that could be a problem?
> 
> There is no file gitmerge.el in the Emacs release.  Where is gitmerge.el
> distributed?

It's part of Emacs, and lives in admin/.

You don't see it in a released Emacs because we didn't yet release
Emacs since we switched to Git; gitmerge.el was written as part of
that switch.  The next Emacs release will include it.

Re: EWW bugs should be fixed on emacs-25 branch

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It seems that you've fixed a large number of bugs in EWW, but you did
> that on master.  That is a mistake, please cherry-pick the
> corresponding changesets to emacs-25, and in the future fix bugs on
> emacs-25, unless the fix has some potentially dangerous parts or
> requires infrastructure that is only available on master.
>
> We want the upcoming Emacs 25.1 to have all these bugs fixed.

Oh, there's a 25.1 scheduled soon?

I've now cherry-picked away.  Let me know if there was something wrong
with those picks...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: EWW bugs should be fixed on emacs-25 branch

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 25 Dec 2015 17:07:09 +0100
> 
> > We want the upcoming Emacs 25.1 to have all these bugs fixed.
> 
> Oh, there's a 25.1 scheduled soon?

We hope so.  That's why most of the work (bugfixes and documentation
updates) is focusing on the emacs-25 branch.

> I've now cherry-picked away.  Let me know if there was something wrong
> with those picks...

Looks good to me, thanks,