From: Eli Zaretskii <eliz@gnu.org>
To: Edward John Steere <edward.steere@gmail.com>
Cc: deng@randomsample.de, emacs-devel@gnu.org, bzg@gnu.org,
emacs-orgmode@gnu.org, kaushal.modi@gmail.com,
phillip.lord@russet.org.uk
Subject: Re: Sync up the org in emacs master to org maint branch?
Date: Sun, 05 Feb 2017 17:50:38 +0200 [thread overview]
Message-ID: <83zii07i29.fsf@gnu.org> (raw)
In-Reply-To: <871svdrov0.fsf@gmail.com> (message from Edward John Steere on Sun, 05 Feb 2017 11:03:31 +0200)
> From: Edward John Steere <edward.steere@gmail.com>
> Date: Sun, 05 Feb 2017 11:03:31 +0200
> 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>
>
> > 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? 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'm not suggesting that we
> rewrite it to make it more loosely coupled, just that it seems like a
> bad idea to continue allowing this going forward.)
How would you go about not allowing this to go forward? I don't
think I see any practical way to do that; do you?
IMO, this is up to the package developers: if they want to depend less
on the Emacs internals, and thus be more loosely coupled with a
particular Emacs version, they will need to invest the extra effort
for that, e.g., by providing some compatibility shims.
IOW, this isn't an issue that can be solved once and for all by the
way we develop the core or the packages, or by the way we integrate
packages with core, the solution is on a different level.
> > As a consequence, we
> > and also the Gnus guys decided to not do separate releases anymore. We
> > used to provide CEDET for different Emacs versions, and it was a *huge*
> > amount of work. I had a buildbot running with 7 or 8 Emacs versions to
> > run the test suite, and things broke pretty regularly.
> > Now you might say: fine, only release a package for current master. But
> > let's say we put CEDET into ELPA. Emacs 26 gets released, and work on
> > Emacs 27 starts. Now there are changes happening in Emacs 27 that
> > require changes in CEDET, which make it incompatible with Emacs 26. So
> > you have to create two packages: one for 26, one for 27? Not only is
> > this confusing, but it most definitely increases my workload.
>
> I feel like this problem isn't intractable. 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.
IF (and its a big "if") package developers want to be able to target
more than the single Emacs version on a single branch of the Emacs
repo, then they will need to provide at least 3 branches:
. "development" branch that tracks the Emacs master branch and
introduces exciting new features
. "bugfix" branch that tracks the Emacs release branch without
adding any new features
. "stable" branch that is compatible with the Emacs release branch,
but also introduces some new features, the ones that don't need
core developments available only on the Emacs master branch
I envision that some packages will want the above (or maybe even a
more elaborate scheme), because they can afford that, and because
their users expect that. These are mostly those packages whose
developers welcome the move to put more of Emacs on ELPA. Other
packages, and I guess CEDET is one of them, will not want to do this,
because it adds too much work to an already complicated and
time-consuming job.
IOW, once again the solution is not part of the way we develop the
core or integrate non-core packages, it's elsewhere.
Bottom line, I think people are bothered by aspects of the "move to
ELPA" process that are not supposed to be affected by that move in any
way. They are aspects that need to be resolved on entirely different
levels, and the resolution is up to the package maintainers. That
includes a possible decision of the developers that some package will
not move to ELPA; I don't think that if a package developers say they
want to stay in emacs.git, they will be told to get out regardless.
next prev parent reply other threads:[~2017-02-05 15:50 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 [this message]
2017-02-05 16:59 ` David Engster
2017-02-05 20:36 ` Edward John Steere
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=83zii07i29.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=bzg@gnu.org \
--cc=deng@randomsample.de \
--cc=edward.steere@gmail.com \
--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).