From: Edward John Steere <edward.steere@gmail.com>
To: David Engster <deng@randomsample.de>
Cc: Bastien Guerry <bzg@gnu.org>,
Emacs developers <emacs-devel@gnu.org>,
Phillip Lord <phillip.lord@russet.org.uk>,
emacs-org list <emacs-orgmode@gnu.org>,
Kaushal Modi <kaushal.modi@gmail.com>
Subject: Re: Sync up the org in emacs master to org maint branch?
Date: Sun, 05 Feb 2017 22:36:48 +0200 [thread overview]
Message-ID: <871svcxtlr.fsf@gmail.com> (raw)
In-Reply-To: <871svcinf3.fsf@engster.org> (David Engster's message of "Sun, 05 Feb 2017 17:59:28 +0100")
>>> 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 coupled that
>> any kind of re factoring in core becomes a nightmare, because we have to
>> consider the umpteen ways in which it'll break the package, then surely
>> that's a bad methodology to continue?
>
> I don't know what you have in mind. All I can say is: CEDET couldn't do
> what it does if we'd restrict ourselves to some subset of Emacs.
In particular I was worried by the phrasing "extremely dependent". I
agree that in order to make a system like CEDET without re-inventing the
wheel and without running into performance problems it's necessary to
depend on more primitive parts of Emacs. Perhaps we can improve the
relationship(?) Perhaps this is a discussion to be had when all of this
is done though.
>> I feel like this problem isn't intractable.
>
> I didn't say it's intractable. I just said it means more work for me.
>
>> We can mark some state of CEDET as being stable under the various
>> versions of Emacs (because it was at the time) and then only support
>> the current release for the latest package. This would most likely
>> require changes to package to ensure that you get an appropriate
>> version of the package when you download it.
>
> As I said: we did that. It was a huge amount of work. Please understand
> where I'm coming from: if you look through the CEDET history, you will
> see that in the past few years I almost exclusively did infrastructure
> work and no real coding. All I can say is: *I* won't do this anymore,
> and I don't want to be part in something which will increase grunt
> work. We did not make this decision lightly. But with the amount of
> developers we have, I'm convinced it's the right thing to do.
Fair enough. I don't have the experience here. It just seems like we
could meet both goals without increasing the work load in this regard.
To be clear I agree that, whatever decision this discussion arrives at,
we definitely don't want to we waste the time of any developer with
grunt work.
Continuing this line of thought. I'm not sure that we're thinking of
the same process here. What I'm suggesting is as follows:
- Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
released; CEDET is at <some-hash-from-master-on-git>
- we update a registry somewhere indicating that Emacs 22.0 works with
<some-hash-from-master-on-git> and 22.1 works with
<some-hash-from-master-on-git>
- When we make updates to CEDET we mark 22.1 as working with
<some-new-hash-from-master-on-git> but we don't change that reference
for 22.0 (or any older versions)
- When someone complains that there's a bug in CEDET for 22.0 we
indicate that it's no longer supported and that they should update
Emacs to receive updates
This process would almost be the same as what you get just by bundling
CEDET with Emacs except that:
- You can get the latest CEDET *if* you have the latest Emacs
- The version of CEDET for any particular version of Emacs is as far as
CEDET got before the next release of Emacs came out
If this is what you were thinking of then please could you elaborate on
what ended up being the problem which added more work.
Also, would this be a problem for our users? i.e. would we be inundated
with emails requesting continued support on older versions or would
users generally accept this kind of change. I mostly work on back end
systems so I don't have a good feeling for how this would go down with
users (I would find this reasonable as a user).
> Bug fixes can go with point release, which we should have every
> year. But yes, if you want the latest, greatest and buggiest, you'll
> have to use Emacs master. But that goes for a lot of Emacs features, so
> I don't see why it's particularly bad for CEDET.
I feel like there are aspects of CEDET which are still under
development. Perhaps I'm just unlucky in my particular usage patterns
of upstream and the way things are going this will be fine (with the
un-merged parts going into packages.)
>> I'm interested in exploring more with regards to how the subtree
>> approach would work. In particular how it would impact the Makefiles
>> and build process. I don't think that introducing features like this
>> necessarily increases the burden of maintaining our tooling. If we get
>> it right it could reduce it.
>
> Well, we cannot really discuss this since there's no real plan how this
> all should work. I can only speak from experience.
We can still put ideas forward though. Haven't come up with anything
myself yet though.
>> I think that it's a worthwhile goal to make core smaller. It may not be
>> a gigantic enterprise system with tens of thousands of source files,
>> like some of us are accustomed to working on, but I think that it
>> becomes easier to reason about the features and behaviour of core when
>> it's smaller.
>
> How does CEDET, Gnus and Org affect the rest of Emacs? They strongly
> depend on Emacs "core" (whatever exactly that is), not the other way
> round.
I believe that one of the intentions of the move is to enforce this so
we can't build bad dependencies -- am I wrong?
>> I think that the distinction becomes clearer when you consider what
>> other parts of Emacs ought to be able to depend on. If mode-x started
>> building dependencies on CEDET because the author discovered some useful
>> functions in CEDET. Then mode-x would build a dependency which is
>> difficult to maintain because changes in CEDET might have unintended
>> effects on mode-x. If the function really is useful, then I think
>> that we should instead consider extracting it from CEDET and placing it
>> into some core library. As far as I can tell this has already happened
>> with numerous functions which originated from CEDET.
>
> Aside from EIEIO, I wouldn't know any. And with EIEIO it had exactly the
> opposite effect: CEDET has to adapt, not the other way round.
I think that we missed each other here. I was saying that moving EIEIO
out of CEDET and giving it a home where other packages could depend on
it was a good thing and that CEDET has to adapt to changes in EIEIO is
the way it should be. I can think of one other function off the top of
my head: `locate-dominating-file'. I believe that it came from EDE.
>> I don't think that anyone is suggesting that we "copy them over and hope
>> for the best." This would have to form part of the QA process. As for
>> testing -- I would be surprised if CEDET in core has really received the
>> amount of testing it needs to declare that it's a stable release.
>
> Well, that's precisely why I want to move development to the Emacs
> repository.
Perhaps I'm wrong, but to my mind the package approach would afford us
with more testing before we get to the point of another release of
Emacs.
Kind regards,
Edward Steere
next prev parent reply other threads:[~2017-02-05 20:36 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 16:39 Sync up the org in emacs master to org maint branch? Kaushal Modi
2017-01-25 16:54 ` Rasmus
2017-01-25 20:31 ` Eli Zaretskii
[not found] ` <874m0maq9e.fsf@gmx.us>
[not found] ` <jwvwpdhj43d.fsf-monnier+gmane.emacs.devel@gnu.org>
2017-01-26 15:01 ` Kaushal Modi
2017-01-26 15:39 ` Kyle Meyer
2017-01-26 16:01 ` Kaushal Modi
2017-01-26 16:36 ` Eli Zaretskii
2017-01-29 19:06 ` John Wiegley
2017-01-26 6:19 ` Kyle Meyer
2017-01-26 8:26 ` Michael Albinus
2017-01-29 19:15 ` John Wiegley
2017-01-30 1:07 ` Stefan Monnier
2017-01-30 7:47 ` David Engster
2017-01-30 15:59 ` John Wiegley
2017-01-30 18:51 ` Edward John Steere
2017-02-03 2:01 ` John Wiegley
2017-02-04 16:30 ` David Engster
2017-01-30 19:28 ` David Engster
2017-01-30 21:52 ` John Wiegley
2017-01-31 14:22 ` Lars Ingebrigtsen
2017-01-31 15:08 ` John Wiegley
2017-01-31 15:15 ` Lars Ingebrigtsen
2017-01-31 15:31 ` David Engster
2017-01-31 15:33 ` Lars Ingebrigtsen
2017-01-31 21:55 ` Stephen Leake
2017-02-01 18:48 ` Lars Ingebrigtsen
2017-01-31 23:19 ` Aaron Ecay
2017-02-01 18:51 ` Lars Ingebrigtsen
2017-02-01 23:21 ` Phillip Lord
2017-02-02 14:37 ` Stefan Monnier
2017-01-31 15:45 ` David Engster
2017-02-02 2:56 ` John Wiegley
2017-02-02 12:10 ` Lars Ingebrigtsen
2017-02-02 14:09 ` John Wiegley
2017-02-02 14:34 ` Lars Ingebrigtsen
2017-02-02 14:23 ` Dmitry Gutov
2017-02-02 17:32 ` Eli Zaretskii
2017-02-02 17:47 ` David Engster
2017-02-02 20:37 ` Eli Zaretskii
2017-02-02 20:57 ` David Engster
2017-02-02 21:13 ` Eli Zaretskii
2017-02-02 14:50 ` Stefan Monnier
2017-02-03 1:55 ` Using CEDET modules from Emacs core John Wiegley
2017-02-03 4:24 ` Stefan Monnier
2017-02-05 7:40 ` Edward John Steere
2017-02-12 2:15 ` John Wiegley
2017-02-12 3:33 ` Stefan Monnier
2017-02-12 16:00 ` Dmitry Gutov
2017-02-14 22:51 ` Eric Ludlam
2017-02-14 23:45 ` Stefan Monnier
2017-02-02 16:30 ` Sync up the org in emacs master to org maint branch? David Engster
2017-02-02 18:17 ` Stefan Monnier
2017-02-03 1:54 ` John Wiegley
2017-02-03 4:41 ` Stefan Monnier
2017-02-03 16:05 ` David Engster
2017-02-05 9:03 ` Edward John Steere
2017-02-05 15:50 ` Eli Zaretskii
2017-02-05 16:59 ` David Engster
2017-02-05 20:36 ` Edward John Steere [this message]
2017-02-06 22:03 ` David Engster
2017-02-07 17:18 ` Edward John Steere
2017-02-12 2:46 ` John Wiegley
2017-02-12 15:34 ` Eli Zaretskii
2017-02-12 23:33 ` Stefan Monnier
2017-01-31 14:42 ` Stefan Monnier
[not found] ` <WM!417e241b26f9ffab5c4a5fb52e8ccb8dd78efd1b242df281924e708a87f0c07486b9d0c1eee555fb39c40d66f9d657b3!@mailhub-mx4.ncl.ac.uk>
2017-02-06 10:00 ` Phillip Lord
2017-02-12 2:22 ` John Wiegley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871svcxtlr.fsf@gmail.com \
--to=edward.steere@gmail.com \
--cc=bzg@gnu.org \
--cc=deng@randomsample.de \
--cc=emacs-devel@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=kaushal.modi@gmail.com \
--cc=phillip.lord@russet.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).