* Re: Periodical releases
2012-01-02 19:05 ` Drew Adams
@ 2012-01-02 19:54 ` chad
2012-01-02 21:36 ` Carsten Mattner
2012-01-02 20:29 ` Eric Schulte
` (3 subsequent siblings)
4 siblings, 1 reply; 38+ messages in thread
From: chad @ 2012-01-02 19:54 UTC (permalink / raw)
To: Emacs developers
As far as I can tell, the primary motivator for more frequent releases of emacs itself is `so emacs doesn't drift so far from its sub-parts', like as Gnus, Org, CEDET, CC-mode (in the past), etc. This is a laudable goal, but emacs doesn't seem to currently have the developer cycles necessary to handle this - releases are frequently held up by documentation changes and reviews even now, with the infrequent releases we have.
Hopefully, the included package system can cover this gap, once it's fully spread through the userbase; users will be able to easily opt-in to newer Gnus releases (for example) via elpa(s)/packages. If we get this working reliably, we could even remove some packages from the emacs core, in favor of more frequent package-based releases. While this model might have once seemed burdensome to users, several years of such systems (for example, in web browser extension updates) will have already trained them to deal with such things before emacs starts doing something similar.
That's my hope, anyway.
*Chad
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-02 19:54 ` chad
@ 2012-01-02 21:36 ` Carsten Mattner
0 siblings, 0 replies; 38+ messages in thread
From: Carsten Mattner @ 2012-01-02 21:36 UTC (permalink / raw)
To: chad; +Cc: Emacs developers
On Mon, Jan 2, 2012 at 8:54 PM, chad <yandros@gmail.com> wrote:
> As far as I can tell, the primary motivator for more frequent releases
> of emacs itself is `so emacs doesn't drift so far from its sub-parts', like
> as Gnus, Org, CEDET, CC-mode (in the past), etc. This is a laudable
> goal, but emacs doesn't seem to currently have the developer cycles
> necessary to handle this - releases are frequently held up by documentation
> changes and reviews even now, with the infrequent releases we have.
>
> Hopefully, the included package system can cover this gap, once it's fully spread
> through the userbase; users will be able to easily opt-in to newer Gnus releases
> (for example) via elpa(s)/packages. If we get this working reliably, we could even
> remove some packages from the emacs core, in favor of more frequent
> package-based releases. While this model might have once seemed burdensome
> to users, several years of such systems (for example, in web browser extension
> updates) will have already trained them to deal with such things before emacs
> starts doing something similar.
>
> That's my hope, anyway.
I fully support removing non-essential modes from emacs, now that
packaging is supported officially in a consistent way.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-02 19:05 ` Drew Adams
2012-01-02 19:54 ` chad
@ 2012-01-02 20:29 ` Eric Schulte
2012-01-02 21:31 ` Carsten Mattner
2012-01-02 20:41 ` Lluís
` (2 subsequent siblings)
4 siblings, 1 reply; 38+ messages in thread
From: Eric Schulte @ 2012-01-02 20:29 UTC (permalink / raw)
To: Drew Adams
Cc: 'Eli Zaretskii', emacs-devel, 'Carsten Mattner',
monnier
>> I would have less of a need to build emacs manually if
>> there were more release and therefore standard emacs
>> Linux distros was more up to date.
>
> The problem you raise here is apparently one of the difficulty/nuisance of
> building Emacs. It is not about how often to publish releases.
>
> Publishing non-release MS Windows binaries periodically has been _very_ helpful
> (thank you again to those who have created and posted the builds). At least on
> that platform, that is a solution to the problem you raise.
>
It seems that the fix here is not to change the Emacs development and
release process, but rather to encourage package maintainers to provide
packages tracking the Emacs trunk. The debian emacs-snapshot package
described as "The GNU Emacs editor (development snapshot)" returns the
following which is certainly many months (maybe years?) out of date.
$ emacs --version
GNU Emacs 23.2.1
Best,
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-02 20:29 ` Eric Schulte
@ 2012-01-02 21:31 ` Carsten Mattner
0 siblings, 0 replies; 38+ messages in thread
From: Carsten Mattner @ 2012-01-02 21:31 UTC (permalink / raw)
To: Eric Schulte; +Cc: Eli Zaretskii, monnier, Drew Adams, emacs-devel
On Mon, Jan 2, 2012 at 9:29 PM, Eric Schulte <eric.schulte@gmx.com> wrote:
>>> I would have less of a need to build emacs manually if
>>> there were more release and therefore standard emacs
>>> Linux distros was more up to date.
>>
>> The problem you raise here is apparently one of the difficulty/nuisance of
>> building Emacs. It is not about how often to publish releases.
>>
>> Publishing non-release MS Windows binaries periodically has been _very_ helpful
>> (thank you again to those who have created and posted the builds). At least on
>> that platform, that is a solution to the problem you raise.
>>
>
> It seems that the fix here is not to change the Emacs development and
> release process, but rather to encourage package maintainers to provide
> packages tracking the Emacs trunk. The debian emacs-snapshot package
> described as "The GNU Emacs editor (development snapshot)" returns the
> following which is certainly many months (maybe years?) out of date.
>
> $ emacs --version
> GNU Emacs 23.2.1
This is one of the things which I always hoped Gentoo, Exherbo or rPath
would solve. Of those Gentoo and Exherbo seem to be the most likely
solution.
Fedora stable is a good way to get current software while not having
to rely on Debian sid.
Debian has the advantage of doko releasing gcc-snapshot regularly
as a nice way to check for future warnings in unreleased gcc versions.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-02 19:05 ` Drew Adams
2012-01-02 19:54 ` chad
2012-01-02 20:29 ` Eric Schulte
@ 2012-01-02 20:41 ` Lluís
2012-01-02 21:23 ` Carsten Mattner
2012-01-05 2:34 ` Dave Abrahams
4 siblings, 0 replies; 38+ messages in thread
From: Lluís @ 2012-01-02 20:41 UTC (permalink / raw)
To: Drew Adams
Cc: 'Eli Zaretskii', emacs-devel, 'Carsten Mattner',
monnier
Drew Adams writes:
[...]
>> I would have less of a need to build emacs manually if
>> there were more release and therefore standard emacs
>> Linux distros was more up to date.
> The problem you raise here is apparently one of the difficulty/nuisance of
> building Emacs. It is not about how often to publish releases.
> Publishing non-release MS Windows binaries periodically has been _very_ helpful
> (thank you again to those who have created and posted the builds). At least on
> that platform, that is a solution to the problem you raise.
> If the same cannot be done for other platforms then the solution would be to
> somehow simplify the difficulty/nuisance of building Emacs on those platforms.
> But in no case should that difficulty/nuisance of building be an excuse for
> releasing the product before it is fully baked.
If building is the only problem, then you might like this (note: debian only):
http://emacs.naquadah.org/
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-02 19:05 ` Drew Adams
` (2 preceding siblings ...)
2012-01-02 20:41 ` Lluís
@ 2012-01-02 21:23 ` Carsten Mattner
2012-01-02 22:14 ` Drew Adams
2012-01-05 2:34 ` Dave Abrahams
4 siblings, 1 reply; 38+ messages in thread
From: Carsten Mattner @ 2012-01-02 21:23 UTC (permalink / raw)
To: Drew Adams; +Cc: Eli Zaretskii, monnier, emacs-devel
On Mon, Jan 2, 2012 at 8:05 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> Don't wait until "perfection" and release trunk more often
>> with bug releases if needed.
>
> No, no, no, please. Just the opposite.
> Bake Emacs _more_ fully before releasing it.
>
> Get it right. Document it well. Mention all user-visible changes in NEWS. Fix
> outstanding bugs.
>
> Richard had exactly the right approach to releasing Emacs, IMO. He was attacked
> by some because they felt the release cycle was too short. I, for one,
> appreciated his thoroughness and insistence on high quality.
>
>> Emacs trunk has never been unstable for me.
>
> Oh. So please continue to use the trunk.
>
> It's been quite unstable (not to mention incomplete) at various times for
> others; believe me. And that's been true forever. It's normal. To expect
> anything else is naive, IMHO.
>
>> I'm even using the NS port and it's still stable.
>
> So please continue to use it.
>
>> I would have less of a need to build emacs manually if
>> there were more release and therefore standard emacs
>> Linux distros was more up to date.
>
> The problem you raise here is apparently one of the difficulty/nuisance of
> building Emacs. It is not about how often to publish releases.
>
> Publishing non-release MS Windows binaries periodically has been _very_ helpful
> (thank you again to those who have created and posted the builds). At least on
> that platform, that is a solution to the problem you raise.
>
> If the same cannot be done for other platforms then the solution would be to
> somehow simplify the difficulty/nuisance of building Emacs on those platforms.
>
> But in no case should that difficulty/nuisance of building be an excuse for
> releasing the product before it is fully baked.
I don't mind building my emacs.
It's a nuisance to have years old Emacs version in distributions.
To get a less buggy Emacs a better approach is releasing it
more often so that there are more testers who wouldn't even consider
building manually or install a prebuilt snapshot from trunk.
^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: Periodical releases
2012-01-02 21:23 ` Carsten Mattner
@ 2012-01-02 22:14 ` Drew Adams
2012-01-02 22:27 ` Carsten Mattner
0 siblings, 1 reply; 38+ messages in thread
From: Drew Adams @ 2012-01-02 22:14 UTC (permalink / raw)
To: 'Carsten Mattner'; +Cc: 'Eli Zaretskii', monnier, emacs-devel
> > But in no case should that difficulty/nuisance of building
> > be an excuse for releasing the product before it is fully baked.
>
> I don't mind building my emacs.
Great. But you did cite "less of a need to build emacs manually" as an argument
why releases should be more frequent.
> It's a nuisance to have years old Emacs version in distributions.
Why? What's the nuisance? Anyway, you build Emacs yourself from trunk as often
as you like, and you don't mind doing so. Where's the beef?
> To get a less buggy Emacs a better approach is releasing it
> more often so that there are more testers who wouldn't even consider
> building manually or install a prebuilt snapshot from trunk.
Bon sang mais c'est bien sur! Ye olde cathedrale vs bazaar song...
There are already plenty of pre-release bugs reported, needing to be fixed.
Maybe when they are fixed you can argue that Emacs should be released to get
more testers. For now, there seem to be enough people using pre-release builds
that give rise to bug reports. More input is always welcome of course, but
Emacs users are not _only_ testers and fixers.
FWIW, where I work the default, prebuilt Emacs for developers on GNU/Linux is
Emacs 21.3.1! And my impression is that few of them bother to build a more
recent version. They are seemingly not clamouring for a new version, especially
since there are already 6 (!) releases available more recent than the one they
use. (Some of them still use XEmacs, and apparently happily so.)
It's sometimes good to step back a bit and imagine that not all, or even most,
Emacs users are involved in, or even interested in, Emacs development.
Ponder... Hard to fathom, I know.
Many, probably most, users use Emacs the way I use my car: just to get around
and do the things I need to do. I don't work on the engine; I don't want to
understand the electrical system; and I upgrade only when the old horse just
can't make it around the block anymore even with a little coaxing.
Now I'm sure carmakers do not consider me their prime marketing target, and I'm
perhaps not a typical car owner. But they really do need to sell new cars, to
stay in business. They need new models each year - periodic releases.
We're not selling cars, and we're not even in business. We're not in a race or
a competition for market share. We cannot go out of business. We improve Emacs
only because we want it to be better or we enjoy improving it or both -
intrinsic reward. And there's no hurry in that.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-02 22:14 ` Drew Adams
@ 2012-01-02 22:27 ` Carsten Mattner
0 siblings, 0 replies; 38+ messages in thread
From: Carsten Mattner @ 2012-01-02 22:27 UTC (permalink / raw)
To: Drew Adams; +Cc: Eli Zaretskii, monnier@iro.umontreal.ca, emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]
On Monday, January 2, 2012, Drew Adams <drew.adams@oracle.com> wrote:
>> > But in no case should that difficulty/nuisance of building
>> > be an excuse for releasing the product before it is fully baked.
>>
>> I don't mind building my emacs.
>
> Great. But you did cite "less of a need to build emacs manually" as an
argument
> why releases should be more frequent.
So that distros don't carry ancient emacs versions.
>> It's a nuisance to have years old Emacs version in distributions.
>
> Why? What's the nuisance? Anyway, you build Emacs yourself from trunk
as often
> as you like, and you don't mind doing so. Where's the beef?
I'd like to use the packaged emacs if it wasn't too old (for me).
>> To get a less buggy Emacs a better approach is releasing it
>> more often so that there are more testers who wouldn't even consider
>> building manually or install a prebuilt snapshot from trunk.
>
> Bon sang mais c'est bien sur! Ye olde cathedrale vs bazaar song...
>
> There are already plenty of pre-release bugs reported, needing to be
fixed.
> Maybe when they are fixed you can argue that Emacs should be released to
get
> more testers. For now, there seem to be enough people using pre-release
builds
> that give rise to bug reports. More input is always welcome of course,
but
> Emacs users are not _only_ testers and fixers.
Not much to argue here.
> FWIW, where I work the default, prebuilt Emacs for developers on
GNU/Linux is
> Emacs 21.3.1! And my impression is that few of them bother to build a
more
> recent version. They are seemingly not clamouring for a new version,
especially
> since there are already 6 (!) releases available more recent than the one
they
> use. (Some of them still use XEmacs, and apparently happily so.)
>
> It's sometimes good to step back a bit and imagine that not all, or even
most,
> Emacs users are involved in, or even interested in, Emacs development.
> Ponder... Hard to fathom, I know.
>
> Many, probably most, users use Emacs the way I use my car: just to get
around
> and do the things I need to do. I don't work on the engine; I don't want
to
> understand the electrical system; and I upgrade only when the old horse
just
> can't make it around the block anymore even with a little coaxing.
>
> Now I'm sure carmakers do not consider me their prime marketing target,
and I'm
> perhaps not a typical car owner. But they really do need to sell new
cars, to
> stay in business. They need new models each year - periodic releases.
>
> We're not selling cars, and we're not even in business. We're not in a
race or
> a competition for market share. We cannot go out of business. We
improve Emacs
> only because we want it to be better or we enjoy improving it or both -
> intrinsic reward. And there's no hurry in that.
If we sold cars, looks would b more important than function. It's good this
ain't a car.
[-- Attachment #2: Type: text/html, Size: 3388 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-02 19:05 ` Drew Adams
` (3 preceding siblings ...)
2012-01-02 21:23 ` Carsten Mattner
@ 2012-01-05 2:34 ` Dave Abrahams
2012-01-05 2:58 ` Chong Yidong
` (2 more replies)
4 siblings, 3 replies; 38+ messages in thread
From: Dave Abrahams @ 2012-01-05 2:34 UTC (permalink / raw)
To: emacs-devel
on Mon Jan 02 2012, "Drew Adams" <drew.adams-AT-oracle.com> wrote:
>> Don't wait until "perfection" and release trunk more often
>> with bug releases if needed.
>
> No, no, no, please. Just the opposite.
> Bake Emacs _more_ fully before releasing it.
>
> Get it right. Document it well. Mention all user-visible changes in
> NEWS. Fix outstanding bugs.
>
> Richard had exactly the right approach to releasing Emacs, IMO. He
> was attacked by some because they felt the release cycle was too
> short. I, for one, appreciated his thoroughness and insistence on
> high quality.
Is it not possible to have thorougness and high quality with more
frequent releases of smaller scope? Maybe the problem (if there is one)
is that trunk is allowed to drift too far from a releasable state. I'm
just saying.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 2:34 ` Dave Abrahams
@ 2012-01-05 2:58 ` Chong Yidong
2012-01-05 3:36 ` Dave Abrahams
2012-01-05 9:31 ` Bastien
2012-01-05 5:43 ` Eli Zaretskii
2012-01-05 15:34 ` Drew Adams
2 siblings, 2 replies; 38+ messages in thread
From: Chong Yidong @ 2012-01-05 2:58 UTC (permalink / raw)
To: Dave Abrahams; +Cc: emacs-devel
Dave Abrahams <dave@boostpro.com> writes:
> Is it not possible to have thorougness and high quality with more
> frequent releases of smaller scope? Maybe the problem (if there is
> one) is that trunk is allowed to drift too far from a releasable
> state. I'm just saying.
Features like bidi can't really be added piecemeal, and this goes back
to Eli's point about bit-rotting feature trees.
Frankly, I'm not convinced there's any problem. Emacs 23.3 was released
less than one year ago, and we are already well into the pretest for
24.1. Doing considerably better would require resources we don't have.
Note that all those projects that are being held up as models for their
periodic release systems have people working on them full time!
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 2:58 ` Chong Yidong
@ 2012-01-05 3:36 ` Dave Abrahams
2012-01-05 4:23 ` Óscar Fuentes
2012-01-05 13:25 ` Eli Zaretskii
2012-01-05 9:31 ` Bastien
1 sibling, 2 replies; 38+ messages in thread
From: Dave Abrahams @ 2012-01-05 3:36 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
on Wed Jan 04 2012, Chong Yidong <cyd-AT-gnu.org> wrote:
> Dave Abrahams <dave@boostpro.com> writes:
>
>> Is it not possible to have thorougness and high quality with more
>> frequent releases of smaller scope? Maybe the problem (if there is
>> one) is that trunk is allowed to drift too far from a releasable
>> state. I'm just saying.
>
> Features like bidi can't really be added piecemeal, and this goes back
> to Eli's point about bit-rotting feature trees.
>
> Frankly, I'm not convinced there's any problem. Emacs 23.3 was released
> less than one year ago, and we are already well into the pretest for
> 24.1. Doing considerably better would require resources we don't have.
> Note that all those projects that are being held up as models for their
> periodic release systems have people working on them full time!
For what it's worth, Boost has no full-time people, and it releases four
times yearly. It wasn't always that way, though: for a while there we
had a period of painfully slow multi-year releases.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 3:36 ` Dave Abrahams
@ 2012-01-05 4:23 ` Óscar Fuentes
2012-01-05 13:25 ` Eli Zaretskii
1 sibling, 0 replies; 38+ messages in thread
From: Óscar Fuentes @ 2012-01-05 4:23 UTC (permalink / raw)
To: emacs-devel
Dave Abrahams <dave@boostpro.com> writes:
> For what it's worth, Boost has no full-time people, and it releases four
> times yearly. It wasn't always that way, though: for a while there we
> had a period of painfully slow multi-year releases.
Boost is anything but similar to Emacs from the project manager POV.
After using the development sources of Emacs for years with great
pleasure (it is, possibly, the most stable piece of software after the
OS kernel itself on any of my machines, if we take into account its
complexity and rate of defects) one is tempted to ask for more frequent
releases, as it is on a release-ready state most of the time, mainly if
we accept the quality level of other popular software that is well below
Emacs'. But then one wonders if that semi-permanent release-ready state
is not caused by the long feature-freeze periods which stabilizing
effect pervades the subsequent years of development.
The fact that Emacs is used by its own developers helps a lot to its
stability, but going into a permanent feature-frenzy mode probably would
cause a steady deterioration on Emacs' quality.
As mentioned on a previous message, IMO offloading some of the big Lisp
packages from the Emacs distribution would benefit the developers and
the users.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 3:36 ` Dave Abrahams
2012-01-05 4:23 ` Óscar Fuentes
@ 2012-01-05 13:25 ` Eli Zaretskii
2012-01-05 13:41 ` Dave Abrahams
1 sibling, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2012-01-05 13:25 UTC (permalink / raw)
To: Dave Abrahams; +Cc: cyd, emacs-devel
> From: Dave Abrahams <dave@boostpro.com>
> Date: Wed, 04 Jan 2012 22:36:24 -0500
> Cc: emacs-devel@gnu.org
>
> For what it's worth, Boost has no full-time people, and it releases four
> times yearly.
How tightly are the various libraries in Boost connected? I.e., if
one of them is broken, how many others will become broken as result?
Core features in Emacs are likely to break many different and
unrelated features. Emacs is a program, not a library.
The "People" page of the Boost site shows 48 developers. How
intensely does each one of them work on Boost? For that matter, how
many hours do you personally spend on Boost weekly, if I may ask?
I would be surprised if Emacs had more than 10 to 15 active
maintainers at any given time. I don't know how many hours others
spend, but I can only devote about maybe 5 hours or less each week.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 13:25 ` Eli Zaretskii
@ 2012-01-05 13:41 ` Dave Abrahams
0 siblings, 0 replies; 38+ messages in thread
From: Dave Abrahams @ 2012-01-05 13:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, emacs-devel
on Thu Jan 05 2012, Eli Zaretskii <eliz-AT-gnu.org> wrote:
>> From: Dave Abrahams <dave@boostpro.com>
>> Date: Wed, 04 Jan 2012 22:36:24 -0500
>> Cc: emacs-devel@gnu.org
>>
>> For what it's worth, Boost has no full-time people, and it releases four
>> times yearly.
>
> How tightly are the various libraries in Boost connected? I.e., if
> one of them is broken, how many others will become broken as result?
Some are extremely loose and some have direct dependencies. But one
thing we have had practically since the beginning is a fairly complete
set of regression tests. Without that, I don't see how our pace of
releases would be possible.
> The "People" page of the Boost site shows 48 developers. How
> intensely does each one of them work on Boost?
I think Ohloh has the best information on this:
http://www.ohloh.net/p/boost
> For that matter, how many hours do you personally spend on Boost
> weekly, if I may ask?
I haven't had much time to do programming for Boost in the past few
years. I'm not sure what the relevance is, though...
> I would be surprised if Emacs had more than 10 to 15 active
> maintainers at any given time. I don't know how many hours others
> spend, but I can only devote about maybe 5 hours or less each week.
Arguably, the more people contributing code, the harder the job of
managing stable releases gets :-)
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 2:58 ` Chong Yidong
2012-01-05 3:36 ` Dave Abrahams
@ 2012-01-05 9:31 ` Bastien
2012-01-05 10:11 ` Leo
` (2 more replies)
1 sibling, 3 replies; 38+ messages in thread
From: Bastien @ 2012-01-05 9:31 UTC (permalink / raw)
To: Chong Yidong; +Cc: Dave Abrahams, emacs-devel
Chong Yidong <cyd@gnu.org> writes:
> Frankly, I'm not convinced there's any problem.
I can see two problems:
1) merging Org into Emacs trunk is a bit painful. I'm still looking for
a good workflow -- given the fact that Org is using git and Emacs is
using bzr. Any concret suggestion here is welcome. I didn't grok
Stefan's last suggestion.
2) I will probably release Org 8.0 before the end of the feature freeze
(say march or april). Not having it in Emacs 24.1 is not such a big
deal, agreed, but it creates a situation where people often install
Org on top of the one that comes with Emacs, which doesn't feel
optimal and leads to many questions, because of conflicting installs.
Both are separate, and I can try to take care of (1) myself.
As for (2), let me refine my suggestion: what about a main feature
freeze for core functionalities and another one for big modules like
Org, Gnus, etc.? The feature freeze for those module could happen for
a *limited* and *known* period of time -- say 2 months before the Emacs
release date.
> Emacs 23.3 was released
> less than one year ago, and we are already well into the pretest for
> 24.1. Doing considerably better would require resources we don't have.
> Note that all those projects that are being held up as models for their
> periodic release systems have people working on them full time!
Yes. It should also be noted that things are getting at a very good
pace since you and Stefan took over maintainership, I guess everyone
acknowledges it.
--
Bastien
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 9:31 ` Bastien
@ 2012-01-05 10:11 ` Leo
2012-01-05 11:31 ` Carsten Mattner
2012-01-05 12:56 ` Jambunathan K
2012-01-05 11:28 ` Carsten Mattner
2012-01-05 11:33 ` Carsten Mattner
2 siblings, 2 replies; 38+ messages in thread
From: Leo @ 2012-01-05 10:11 UTC (permalink / raw)
To: emacs-devel
On 2012-01-05 17:31 +0800, Bastien wrote:
> 2) I will probably release Org 8.0 before the end of the feature freeze
> (say march or april). Not having it in Emacs 24.1 is not such a big
> deal, agreed, but it creates a situation where people often install
> Org on top of the one that comes with Emacs, which doesn't feel
> optimal and leads to many questions, because of conflicting installs.
>
> Both are separate, and I can try to take care of (1) myself.
I think in future it may be desirable to make more use of the packaging
system now that we have one. It is like many of those GNU/Linux
distributions. The core developers/maintainers are concerned with the
core packages/functionality (it is better use of their time since they
usually have better insight of the project) and the rest can be taken
care by community members. For example the value of including org-mode
in the source tree is quite little. If it is distributed with the
packing system people can receive more timely bug fixes free of any
constraint of the release cycle.
Leo
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 10:11 ` Leo
@ 2012-01-05 11:31 ` Carsten Mattner
2012-01-05 12:56 ` Jambunathan K
1 sibling, 0 replies; 38+ messages in thread
From: Carsten Mattner @ 2012-01-05 11:31 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
On Thu, Jan 5, 2012 at 11:11 AM, Leo <sdl.web@gmail.com> wrote:
> On 2012-01-05 17:31 +0800, Bastien wrote:
>> 2) I will probably release Org 8.0 before the end of the feature freeze
>> (say march or april). Not having it in Emacs 24.1 is not such a big
>> deal, agreed, but it creates a situation where people often install
>> Org on top of the one that comes with Emacs, which doesn't feel
>> optimal and leads to many questions, because of conflicting installs.
>>
>> Both are separate, and I can try to take care of (1) myself.
>
> I think in future it may be desirable to make more use of the packaging
> system now that we have one. It is like many of those GNU/Linux
> distributions. The core developers/maintainers are concerned with the
> core packages/functionality (it is better use of their time since they
> usually have better insight of the project) and the rest can be taken
> care by community members. For example the value of including org-mode
> in the source tree is quite little. If it is distributed with the
> packing system people can receive more timely bug fixes free of any
> constraint of the release cycle.
I second that. Cedet, Gnus, Org, themes (hash verification issues?)...
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 10:11 ` Leo
2012-01-05 11:31 ` Carsten Mattner
@ 2012-01-05 12:56 ` Jambunathan K
2012-01-05 14:00 ` Leo
1 sibling, 1 reply; 38+ messages in thread
From: Jambunathan K @ 2012-01-05 12:56 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
> 1 For example the value of including org-mode in the source tree is
> quite little. If it is distributed with the packing system people can
> receive more timely bug fixes free of any constraint of the release
> cycle.
Org's daily builds are part of GNU ELPA for atleast around an year now.
> Leo
--
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 12:56 ` Jambunathan K
@ 2012-01-05 14:00 ` Leo
2012-01-05 14:30 ` Jambunathan K
0 siblings, 1 reply; 38+ messages in thread
From: Leo @ 2012-01-05 14:00 UTC (permalink / raw)
To: emacs-devel
On 2012-01-05 20:56 +0800, Jambunathan K wrote:
>> 1 For example the value of including org-mode in the source tree is
>> quite little. If it is distributed with the packing system people can
>> receive more timely bug fixes free of any constraint of the release
>> cycle.
>
> Org's daily builds are part of GNU ELPA for atleast around an year now.
Point missed.
Leo
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 14:00 ` Leo
@ 2012-01-05 14:30 ` Jambunathan K
0 siblings, 0 replies; 38+ messages in thread
From: Jambunathan K @ 2012-01-05 14:30 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
Leo <sdl.web@gmail.com> writes:
> On 2012-01-05 20:56 +0800, Jambunathan K wrote:
>>> 1 For example the value of including org-mode in the source tree is
>>> quite little. If it is distributed with the packing system people can
>>> receive more timely bug fixes free of any constraint of the release
>>> cycle.
>>
>> Org's daily builds are part of GNU ELPA for atleast around an year now.
>
> Point missed.
Too terse for me to understand - not that I care to understand.
> Leo
>
>
>
--
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 9:31 ` Bastien
2012-01-05 10:11 ` Leo
@ 2012-01-05 11:28 ` Carsten Mattner
2012-01-05 14:18 ` Eric Schulte
2012-01-05 11:33 ` Carsten Mattner
2 siblings, 1 reply; 38+ messages in thread
From: Carsten Mattner @ 2012-01-05 11:28 UTC (permalink / raw)
To: Bastien; +Cc: Dave Abrahams, Chong Yidong, emacs-devel
On Thu, Jan 5, 2012 at 10:31 AM, Bastien <bzg@altern.org> wrote:
> 2) I will probably release Org 8.0 before the end of the feature freeze
> (say march or april). Not having it in Emacs 24.1 is not such a big
> deal, agreed, but it creates a situation where people often install
> Org on top of the one that comes with Emacs, which doesn't feel
> optimal and leads to many questions, because of conflicting installs.
Out of curiosity. If I have 24.1 with Org 7.x and to use Org latest
I put that in ~/.emacs.d/<somewhere>, is there some potential
ambiguity/conflict/version-clash/mixup going on if I add that
local dir to the load path? Do I have to use some unknown-to-me
(prepend-to-load-path path)? I know that Vim has ~/.vim/* first in the
path list. What's it for Emacs?
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 11:28 ` Carsten Mattner
@ 2012-01-05 14:18 ` Eric Schulte
0 siblings, 0 replies; 38+ messages in thread
From: Eric Schulte @ 2012-01-05 14:18 UTC (permalink / raw)
To: Carsten Mattner; +Cc: Dave Abrahams, Bastien, Chong Yidong, emacs-devel
Carsten Mattner <carstenmattner@googlemail.com> writes:
> On Thu, Jan 5, 2012 at 10:31 AM, Bastien <bzg@altern.org> wrote:
>> 2) I will probably release Org 8.0 before the end of the feature freeze
>> (say march or april). Not having it in Emacs 24.1 is not such a big
>> deal, agreed, but it creates a situation where people often install
>> Org on top of the one that comes with Emacs, which doesn't feel
>> optimal and leads to many questions, because of conflicting installs.
>
> Out of curiosity. If I have 24.1 with Org 7.x and to use Org latest
> I put that in ~/.emacs.d/<somewhere>, is there some potential
> ambiguity/conflict/version-clash/mixup going on if I add that
> local dir to the load path? Do I have to use some unknown-to-me
> (prepend-to-load-path path)? I know that Vim has ~/.vim/* first in the
> path list. What's it for Emacs?
The `add-to-list' function will place any new directory at the front of
your load path. In general adding the new version of Org-mode to your
load path, loading or requiring org, and then calling the `org-reload'
function should be sufficient. For more information see [1].
However, when an older version of Org-mode (e.g., one shipped with
Emacs) is loaded first it defines all Org-mode variables. Subsequent
versions of Org-mode will not update the values of these variables as a
defvar of an existing variable does not change its value. This
frequently leads to buggy behavior. This point would argue for
migration of Org-mode to ELPA in future releases.
Best -- Eric
Footnotes:
[1] http://orgmode.org/worg/org-faq.html#Keeping-current
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 9:31 ` Bastien
2012-01-05 10:11 ` Leo
2012-01-05 11:28 ` Carsten Mattner
@ 2012-01-05 11:33 ` Carsten Mattner
2 siblings, 0 replies; 38+ messages in thread
From: Carsten Mattner @ 2012-01-05 11:33 UTC (permalink / raw)
To: Bastien; +Cc: Dave Abrahams, Chong Yidong, emacs-devel
On Thu, Jan 5, 2012 at 10:31 AM, Bastien <bzg@altern.org> wrote:
> Yes. It should also be noted that things are getting at a very good
> pace since you and Stefan took over maintainership, I guess everyone
> acknowledges it.
Definitely, thanks to the new maintainers. You guys do a great job!
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Periodical releases
2012-01-05 2:34 ` Dave Abrahams
2012-01-05 2:58 ` Chong Yidong
@ 2012-01-05 5:43 ` Eli Zaretskii
2012-01-05 12:20 ` Dave Abrahams
2012-01-05 15:34 ` Drew Adams
2 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2012-01-05 5:43 UTC (permalink / raw)
To: Dave Abrahams; +Cc: emacs-devel
> From: Dave Abrahams <dave@boostpro.com>
> Date: Wed, 04 Jan 2012 21:34:25 -0500
>
> Is it not possible to have thorougness and high quality with more
> frequent releases of smaller scope?
It is, with more resources than we currently have.
> Maybe the problem (if there is one) is that trunk is allowed to
> drift too far from a releasable state.
You cannot control that drift without a test suite with decent
coverage. We don't have that yet. We don't even have a concerted
effort to get there, AFAIK. Volunteers are welcome, as always.
^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: Periodical releases
2012-01-05 2:34 ` Dave Abrahams
2012-01-05 2:58 ` Chong Yidong
2012-01-05 5:43 ` Eli Zaretskii
@ 2012-01-05 15:34 ` Drew Adams
2 siblings, 0 replies; 38+ messages in thread
From: Drew Adams @ 2012-01-05 15:34 UTC (permalink / raw)
To: 'Dave Abrahams', emacs-devel
> >> Don't wait until "perfection" and release trunk more often
> >> with bug releases if needed.
> >
> > No, no, no, please. Just the opposite.
> > Bake Emacs _more_ fully before releasing it.
> >
> > Get it right. Document it well. Mention all user-visible
> > changes in NEWS. Fix outstanding bugs.
> >
> > Richard had exactly the right approach to releasing Emacs, IMO. He
> > was attacked by some because they felt the release cycle was too
> > short. I, for one, appreciated his thoroughness and insistence on
> > high quality.
>
> Is it not possible to have thorougness and high quality with more
> frequent releases of smaller scope? Maybe the problem (if
> there is one) is that trunk is allowed to drift too far from a
> releasable state. I'm just saying.
Not when there are large changes made for significant features (new or old).
Consider, for Emacs 24, (1) the myriad user-visible effects of radically
changing the `display-buffer'/window behavior, and (2) the significant
development effort related to bidi (non-trivial, takes time to implement and
test).
^ permalink raw reply [flat|nested] 38+ messages in thread