Lars Ingebrigtsen writes:
> John Wiegley writes:
>
>> We're moving toward a future where Emacs.git will represent "core
>> Emacs", and only contain what core needs (plus a few historical bits,
>> I'm sure). There should be no argument for keeping a project in core
>> just to gain auxiliary benef
>> - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
>>released; CEDET is at
>> - we update a registry somewhere indicating that Emacs 22.0 works with
>> and 22.1 works with
>>
>> - When we make updates to CEDET we mark 22.1 as working with
>> but we don't
>>> they are extremely dependend on
>>> many obscure Emacs internals (not sure about Org).
>>
>> Shouldn't we be trying to avoid this situation? It's sure to come back
>> and bite us in the future. If we continue to develop a package
>> (wherever it ends up being developed) which is so tightly co
>
> DE> This is a misunderstanding. I said I wanted to move support for certain
> DE> languages and project types into ELPA, not CEDET core. I'm still of the
> DE> opinion that moving it completely to ELPA is a mistake.
>
> It would only be a mistake if other parts of core need to use it. If only
>
> It's not like packages communicate with Emacs over a well
> defined RESTful interface. In other words: CEDET and Gnus are not
> loosely coupled, quite the opposite: they are extremely dependend on
> many obscure Emacs internals (not sure about Org).
Shouldn't we be trying to avoid this situation
> AFAIU, the main motivation for the "drive to ELPA" comes from
> developers of individual packages, not from those working on the core
Not sure what you mean exactly by "drive to ELPA". If you mean "drive
to put packages in GNU ELPA rather than in core", then this drive is
linked to various aspe
> From: John Wiegley
> Date: Sat, 11 Feb 2017 18:46:09 -0800
> Cc: Bastien Guerry , Emacs developers ,
> Phillip Lord ,
> emacs-org list ,
> Kaushal Modi
>
> I hear your other points, so I'm curious now as to what more people think
> about this who work on Emacs core: Do you wa
> "DE" == David Engster writes:
DE> I find this whole core vs package argument strange. If you ship Emacs with
DE> Org, Gnus and CEDET, they are part of Emacs, so it's in the interest of
DE> all Emacs developers that they work well, whether they use them or not.
DE> The users won't care if th
> "PL" == Phillip Lord writes:
PL> The alternative proposal is, essentially, to copy files into the Emacs
PL> core build structure and move from there.
PL> Reading the discussion reinforces my feeling that the latter is the wrong
PL> approach, because it reinforces a distinction between pack
Edward John Steere writes:
> - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
>released; CEDET is at
> - we update a registry somewhere indicating that Emacs 22.0 works with
> and 22.1 works with
>
> - When we make updates to CEDET we mark 22.1 as working with
John Wiegley writes:
>> "KM" == Kaushal Modi writes:
>
> KM> If we are able the release the new packaging method in emacs 26.x, then we
> KM> can remove org from emacs master completely, but if not, then at least as
> KM> backup we have a newer org version to go out with that release.
>
> Fo
Edward John Steere writes:
>> It's not like packages communicate with Emacs over a well
>> defined RESTful interface. In other words: CEDET and Gnus are not
>> loosely coupled, quite the opposite: they are extremely dependend on
>> many obscure Emacs internals (not sure about Org).
>
> Shouldn't we
> From: Edward John Steere
> Date: Sun, 05 Feb 2017 11:03:31 +0200
> Cc: Bastien Guerry , Emacs developers ,
> Phillip Lord ,
> emacs-org list ,
> Kaushal Modi
>
> > It's not like packages communicate with Emacs over a well
> > defined RESTful interface. In other words: CEDET a
John Wiegley writes:
> Many software projects have package ecosystems surrounding them that deal with
> similar issues, and I can't, off-hand, think of cases where the answer was
> "let's move some of those packages into core development to ease
> ___".
Just from the software I worked with over th
John Wiegley writes:
>> "DE" == David Engster writes:
>
> DE> So if you don't get convinced, we'll just move again, right? No big deal.
>
> I suppose I'm asking that of you, yes.
Sorry, but I rather wait.
> DE> You are insinuating that my motivation is to delegate CEDET development to
> DE>
> "DE" == David Engster writes:
DE> So if you don't get convinced, we'll just move again, right? No big deal.
I suppose I'm asking that of you, yes.
DE> You are insinuating that my motivation is to delegate CEDET development to
DE> the core Emacs developers. This is simply not true, and I d
> "EJS" == Edward John Steere writes:
EJS> What I think that we shouldn't lose sight of (if I may suggest it): is
EJS> that packaging CEDET, Org Mode and other packages like them in a process
EJS> which integrates them only when producing the tarball would serve to
EJS> simplify things for ev
> From: David Engster
> Cc: emacs-de...@gnu.org, b...@gnu.org, emacs-orgmode@gnu.org,
> kaushal.m...@gmail.com, la...@gnus.org, phillip.l...@russet.org.uk
> Date: Thu, 02 Feb 2017 21:57:02 +0100
>
> > Ask the package maintainers, they see significant advantages in being
> > able to release
Eli Zaretskii writes:
>> From: David Engster
>> Cc: Lars Ingebrigtsen , b...@gnu.org,
>> emacs-de...@gnu.org, phillip.l...@russet.org.uk,
>
>> which implies that they are not supposed to be present at a "normal"
>> checkout.
>
> I don't see how it implies that. Release tarballs are prepared
> spe
> From: David Engster
> Cc: Lars Ingebrigtsen , b...@gnu.org, emacs-de...@gnu.org,
> phillip.l...@russet.org.uk, emacs-orgmode@gnu.org, kaushal.m...@gmail.com
> Date: Thu, 02 Feb 2017 18:47:49 +0100
>
> > I believe the intent is to make it so that checking out and building
> > Emacs also ch
> So let me try again: What I find completely misguided is to move
> packages out of core *but still putting them into the release*. In other
> words, in my opinion there are really just two options that make sense:
> you either keep a package in core, or you kick it out and don't ship it
> with th
Eli Zaretskii writes:
>> From: Lars Ingebrigtsen
>> Date: Thu, 02 Feb 2017 13:10:07 +0100
>> Cc: Bastien Guerry , Emacs developers ,
>
>> Phillip Lord ,
>> emacs-org list ,
>> Kaushal Modi
>>
>> If Django had traditionally always been distributed along with Python,
>> and maintain
> From: Lars Ingebrigtsen
> Date: Thu, 02 Feb 2017 13:10:07 +0100
> Cc: Bastien Guerry , Emacs developers ,
> Phillip Lord ,
> emacs-org list ,
> Kaushal Modi
>
> If Django had traditionally always been distributed along with Python,
> and maintained in the Python repo, and the
John Wiegley writes:
>> "DE" == David Engster writes:
>
> DE> Also, I currently have no idea how to continue with CEDET, as the future
> DE> where development should happen is unclear, and I get the feeling we're
> DE> just waisting our time with the ongoing merge.
>
> Until the dust has settl
John Wiegley writes:
> OK, to continue the analogy, what is the right answer? Technically it
> doesn't seem as though Django belongs there, even if culturally it
> sounds hard to separate. Should it stay indefinitely, or should the
> development model change?
If somebody genuinely offered to tak
On 02.02.2017 14:10, Lars Ingebrigtsen wrote:
If Django had traditionally always been distributed along with Python,
and maintained in the Python repo,
I'm pretty sure the first versions of Emacs came without Gnus. Later, it
got bundled. Some time after that, Org and CEDET joined too.
All o
> "LI" == Lars Ingebrigtsen writes:
LI> If Django had traditionally always been distributed along with Python, and
LI> maintained in the Python repo, and the suggestion now would be to move
LI> Django to a part of the Python repo that very few developers look at, but
LI> Django would continue
John Wiegley writes:
> In fact, what we're doing feels like if Python included Django in its main
> repository, just to solve Django's problems of compatibility, testing, and
> making its bugs known to the main Python developers.
I guess that would be a fair comparison.
If Django had traditiona
> "DE" == David Engster writes:
DE> Also, I currently have no idea how to continue with CEDET, as the future
DE> where development should happen is unclear, and I get the feeling we're
DE> just waisting our time with the ongoing merge.
Until the dust has settled, please proceed, assuming not
On Wed, February 1, 2017 6:51 pm, Lars Ingebrigtsen wrote:
> Aaron Ecay writes:
>
>
>> If ELPA made available (on the server for downloading, and in the
>> client for installing) old versions of packages, then users could always
>> be offered the latest compatible version, but not later incompatib
Aaron Ecay writes:
> If ELPA made available (on the server for downloading, and in the
> client for installing) old versions of packages, then users could
> always be offered the latest compatible version, but not later
> incompatible ones.
I don't think having Emacs developers fixing bugs in a
Stephen Leake writes:
>> I'm massively unenthusiastic about this future. Things in ELPA has to
>> be backwards-and-forwards compatible with a wide Emacs version range,
>
> no, they don't.
>
> That is one possible policy, but each package decides for itself whether
> to follow it. You can have
>
Hi Lars,
2017ko urtarrilak 31an, Lars Ingebrigtsen-ek idatzi zuen:
>
> John Wiegley writes:
>
>> We're moving toward a future where Emacs.git will represent "core
>> Emacs", and only contain what core needs (plus a few historical bits,
>> I'm sure). There should be no argument for keeping a pro
John Wiegley writes:
>> "DE" == David Engster writes:
>
> DE> It is a mistake because you are creating more moving targets and bring
> DE> them together very late in the release process. This reduces the amount of
> DE> testing that is done for those packages, so bugs will be noticed later and
> It is a mistake because you are creating more moving targets and bring
> them together very late in the release process. This reduces the amount
> of testing that is done for those packages, so bugs will be noticed
> later and the quality of the relases suffer. It moves even more work
> into the
David Engster writes:
>> (Except perhaps CEDET. There seems to be a lot of merging problems
>> there.)
>
> This is precisely why we're currently moving all development to Emacs
> and abandon the external repo. At least we were planning to...
Oh, great. One less thing that would be helped by mo
Lars Ingebrigtsen writes:
> The question is: What is the most effective way for Emacs developers to
> spend their time? I can't really see that anybody has made the case
> that shifting stuff from Emacs core to ELPA will mean less work for...
> well, anybody.
>
> (Except perhaps CEDET. There seem
John Wiegley writes:
> So far, all of these arguments against a tighter development integration with
> ELPA have been predicated on the way that ELPA is used today. ELPA is under
> our control; we can adjust our process to suit the needs of Emacs development.
Yes, but external packages lose much
> "LI" == Lars Ingebrigtsen writes:
LI> I'm massively unenthusiastic about this future. Things in ELPA has to be
LI> backwards-and-forwards compatible with a wide Emacs version range, which
LI> makes maintaining things much more work. When you develop things in "Emacs
LI> core", you have one
John Wiegley writes:
> We're moving toward a future where Emacs.git will represent "core
> Emacs", and only contain what core needs (plus a few historical bits,
> I'm sure). There should be no argument for keeping a project in core
> just to gain auxiliary benefits.
I'm massively unenthusiastic
> "DE" == David Engster writes:
DE> It is a mistake because you are creating more moving targets and bring
DE> them together very late in the release process. This reduces the amount of
DE> testing that is done for those packages, so bugs will be noticed later and
DE> the quality of the relas
John Wiegley writes:
>> "DE" == David Engster writes:
>
> DE> This is a misunderstanding. I said I wanted to move support for certain
> DE> languages and project types into ELPA, not CEDET core. I'm still of the
> DE> opinion that moving it completely to ELPA is a mistake.
>
> It would only be
> "DE" == David Engster writes:
DE> This is a misunderstanding. I said I wanted to move support for certain
DE> languages and project types into ELPA, not CEDET core. I'm still of the
DE> opinion that moving it completely to ELPA is a mistake.
It would only be a mistake if other parts of cor
John Wiegley writes:
>> "KM" == Kaushal Modi writes:
>
> KM> If we are able the release the new packaging method in emacs 26.x, then we
> KM> can remove org from emacs master completely, but if not, then at least as
> KM> backup we have a newer org version to go out with that release.
>
> For
> "KM" == Kaushal Modi writes:
KM> If we are able the release the new packaging method in emacs 26.x, then we
KM> can remove org from emacs master completely, but if not, then at least as
KM> backup we have a newer org version to go out with that release.
For Emacs 26, I intend the new ELPA
> "EZ" == Eli Zaretskii writes:
EZ> AFAIR, we have never released a major version so quickly, and I don't see
EZ> why this one would be different. A year at least, I'd say, probably more.
This was my feeling as well.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B8
> From: Kaushal Modi
> Date: Thu, 26 Jan 2017 16:01:24 +
> Cc: emacs-org list ,
> Stefan Monnier ,
> Rasmus , Emacs developers
>
> I don't believe that the target date has yet been set for releasing 26.1. We
> are currently on the release
> candidate testing stage of 25.2. So I
On Thu, Jan 26, 2017 at 10:39 AM Kyle Meyer wrote:
> Kaushal Modi writes:
>
> > On Thu, Jan 26, 2017 at 1:19 AM Kyle Meyer wrote:
> >
> >> We'd want at least one more release from maint, I think, so that'd be
> >> 9.0.5.
> >
> > Would it be OK to sync the current stable 9.0.4,
>
> I don't think
Kaushal Modi writes:
> On Thu, Jan 26, 2017 at 1:19 AM Kyle Meyer wrote:
>
>> We'd want at least one more release from maint, I think, so that'd be
>> 9.0.5.
>
> Would it be OK to sync the current stable 9.0.4,
I don't think that's a good idea. Since 9.0.4, I've backported one
remaining commit
On Thu, Jan 26, 2017 at 1:19 AM Kyle Meyer wrote:
> Rasmus writes:
> We'd want at least one more release from maint, I think, so that'd be
> 9.0.5.
>
Would it be OK to sync the current stable 9.0.4, and keep on updating with
each stable release as time comes? We never know, we might end up with
Rasmus writes:
> Hi,
Hi,
> *AFAIR* it was too late and would thus not have received enough test from
> the general Emacs community.
org-mode comes with some hundred ert test cases. It would be great if
they'll land also in the Emacs master branch; this will give much more
testing.
> Thanks,
>
Rasmus writes:
> Kaushal Modi writes:
[...]
>> As a precaution that that does not repeat when emacs 26.x is released,
>> should the org version in emacs master be synced with the now latest stable
>> org version 9.0.4?
>
> Yes.
We'd want at least one more release from maint, I think, so that'
> From: Rasmus
> Date: Wed, 25 Jan 2017 17:54:48 +0100
> Cc: emacs-de...@gnu.org
>
> What is the current status? I am a bit confused about the policy at this
> point. I'm happy to try to update master to 9.0.4, but I was somehow
> under the impression that we were waiting for a solution to incl
Hi,
Kaushal Modi writes:
> I am aware that in emacs 26, there are plans to change the way in how
> certain packages can be moved out of the emacs master and still can be
> installed seamlessly using the tarballs of those.
Indeed.
> Currently the org-mode version in emacs master is 8.2.10 and t
Hi all,
I am aware that in emacs 26, there are plans to change the way in how
certain packages can be moved out of the emacs master and still can be
installed seamlessly using the tarballs of those.
Currently the org-mode version in emacs master is 8.2.10 and that it too
old (> 2 years, ref: http
55 matches
Mail list logo
