Bleeding edge in elpa

Bleeding edge in elpa

[Nikolai Weibull]

Hi!

Would it be of interest to anyone else if the bleeding edge version
was available via elpa?

Re: Bleeding edge in elpa

[Xavier Maillard]

Hi,

Nikolai Weibull <now@disu.se> writes:

> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?

Isn't it already available via M-x package interface ? I'd rather use
git (I really do not like the package stuff).

Regards
-- Xavier.

Re: Bleeding edge in elpa

[Nikolai Weibull]

On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard <xavier@maillard.im> wrote:

> Nikolai Weibull <now@disu.se> writes:

>> Would it be of interest to anyone else if the bleeding edge version
>> was available via elpa?

> Isn't it already available via M-x package interface ?

No, only the version based on the maint branch is available via elpa.

> I'd rather use
> git (I really do not like the package stuff).

As Grant pointed out, it’s a lot more convenient working inside Emacs
for switching between versions and such.

Re: Bleeding edge in elpa

[Xavier Maillard]

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


Nikolai Weibull <now@disu.se> writes:

> On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard <xavier@maillard.im> wrote:
>
>> Nikolai Weibull <now@disu.se> writes:
>
>>> Would it be of interest to anyone else if the bleeding edge version
>>> was available via elpa?
>
>> Isn't it already available via M-x package interface ?
>
> No, only the version based on the maint branch is available via elpa.

Ah yes, I see.

>> I'd rather use
>> git (I really do not like the package stuff).
>
> As Grant pointed out, it’s a lot more convenient working inside Emacs
> for switching between versions and such.

I understand but that's not my use case too so...
-- Xavier.

[-- Attachment #2: Type: application/pgp-signature, Size: 1494 bytes --]

Re: Bleeding edge in elpa

[Sebastien Vauban]

Nikolai Weibull wrote:
> On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard <xavier-U5RQyKqGfor/u5h4R/Qkbg@public.gmane.org> wrote:
>> Nikolai Weibull <now-yvQGvizXgks@public.gmane.org> writes:
>
>>> Would it be of interest to anyone else if the bleeding edge version
>>> was available via elpa?
>
>> Isn't it already available via M-x package interface ?
>
> No, only the version based on the maint branch is available via elpa.
>
>> I'd rather use git (I really do not like the package stuff).
>
> As Grant pointed out, it’s a lot more convenient working inside Emacs
> for switching between versions and such.

How do you switch between versions in ELPA?  IIUC, you only get the
latest version, and if that one is not right, you're kind of stuck: you
can't reinstall the previous version via the interface. Or maybe I have
to learn something new?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Bleeding edge in elpa

[T.F. Torrey]

Hello,

Sebastien Vauban <sva-news@mygooglest.com> writes:

>> As Grant pointed out, it’s a lot more convenient working inside Emacs
>> for switching between versions and such.
>
> How do you switch between versions in ELPA?  IIUC, you only get the
> latest version, and if that one is not right, you're kind of stuck: you
> can't reinstall the previous version via the interface. Or maybe I have
> to learn something new?

Only one version per package name is allowed, so with everything in one
archive it won't currently work.

However, with smaller archives each holding one version, it becomes
possible.

For instance, to get the latest package of the main version of Org,
enable the Orgmode.org/elpa archive.  To go back to the slightly older,
perhaps more stable version in the GNU archive, remove the
Orgmode.org/elpa archive from your archive configuration, uninstall Org,
then reinstall it, and you will get the version from the GNU archive,
which will now be the latest one the packages system can find.

It's kind of a hack, sure, but until the package system is upgraded to
handle dependence on multiple versions of the same package, it works.
It would probably be inconvenient to do this for every package, but I
don't mind doing it for major packages like Org.

HTH,
Terry
--
T.F. Torrey

Re: Bleeding edge in elpa

[Grant Rettke]

Yes because it would allow us to very easily switch between a stable
and unstable installation using the built-in package infrastructure.

On Sat, Mar 7, 2015 at 8:36 AM, Nikolai Weibull <now@disu.se> wrote:
> Hi!
>
> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?
>



-- 
Grant Rettke
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: Bleeding edge in elpa

[T.F. Torrey]

Nikolai Weibull <now@disu.se> writes:

> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?

I would also very much appreciate it.

Terry
--
T.F. Torrey

Re: Bleeding edge in elpa

[Nicolas Girard]

2015-03-07 15:36 GMT+01:00 Nikolai Weibull <now@disu.se>:
>
> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?
>

I'd greatly appreciate it too !

Cheers,

Nicolas

Re: Bleeding edge in elpa

[Aaron Ecay]

Hi Nikolai,

IMO this is a bad idea.  The bleeding edge version is expected to be
somewhat unstable, and exposing it via ELPA will lead to foot-shooting
incidents.

On the other hand, it would be nice to have more regular releases from
master to maint.  AFAIK the last one was a year and a half ago (Org
8.2).  However, this has traditionally required a lot of effort from
Bastien and others, so it’s not a simple case of “wishing will make it
so”.

--
Aaron Ecay

Re: Bleeding edge in elpa

[Nikolai Weibull]

On Sun, Mar 8, 2015 at 3:17 PM, Aaron Ecay <aaronecay@gmail.com> wrote:

> IMO this is a bad idea.  The bleeding edge version is expected to be
> somewhat unstable, and exposing it via ELPA will lead to foot-shooting
> incidents.

Is trying to manage it via git+make oneself less likely to cause incidents?

From the FAQ:

The master branch of the git repository always contains the bleeding
edge development code. This is important for Org's fast development,
because code on master gets checked out by many people daily and we
quickly receive bug reports if something is wrong. On rare occasions,
this code may not function perfectly for a limited time while we are
trying to fix things. It is therefore recommended to keep a known-good
version of org-mode installed outside the source tree and always run
the full test suite before using a new version from master.

> On the other hand, it would be nice to have more regular releases from
> master to maint.  AFAIK the last one was a year and a half ago (Org
> 8.2).  However, this has traditionally required a lot of effort from
> Bastien and others, so it’s not a simple case of “wishing will make it
> so”.

The more time that passes between releases, the harder it is to
release a new version.

And as this is the case here, having easy access to the latest
“version” would lessen the effect of this.  It would also allow more
people to find bugs.

Re: Bleeding edge in elpa

[Achim Gratz]

Nikolai Weibull writes:
> Is trying to manage it via git+make oneself less likely to cause
> incidents?

There's a bunch of people who seem to manage it just fine.

> From the FAQ:
>
> The master branch of the git repository always contains the bleeding
> edge development code. This is important for Org's fast development,
> because code on master gets checked out by many people daily and we
> quickly receive bug reports if something is wrong. On rare occasions,
> this code may not function perfectly for a limited time while we are
> trying to fix things. It is therefore recommended to keep a known-good
> version of org-mode installed outside the source tree and always run
> the full test suite before using a new version from master.

Yes, if the absolutely latest master doesn't work, people can just check
out whatever version was working for them last and continue without
waiting for the next snapshot from ELPA /which may or may not work).

> The more time that passes between releases, the harder it is to
> release a new version.
>
> And as this is the case here, having easy access to the latest
> “version” would lessen the effect of this.  It would also allow more
> people to find bugs.

It doesn't get any easier than it already is.  Having both a stable and
an unstable version of Org avilable via ELPA is a non-starter for the
simple reason that the package manager can't deal with the versioning
problems this would introduce.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Bleeding edge in elpa

[Nikolai Weibull]

On Sun, Mar 8, 2015 at 6:59 PM, Achim Gratz <Stromeko@nexgo.de> wrote:
> Nikolai Weibull writes:
>> Is trying to manage it via git+make oneself less likely to cause
>> incidents?

> There's a bunch of people who seem to manage it just fine.

Did I say otherwise?

Does this preclude making an alternative available, one that at least
some would consider simpler to access?

>> From the FAQ:
>>
>> The master branch of the git repository always contains the bleeding
>> edge development code. This is important for Org's fast development,
>> because code on master gets checked out by many people daily and we
>> quickly receive bug reports if something is wrong. On rare occasions,
>> this code may not function perfectly for a limited time while we are
>> trying to fix things. It is therefore recommended to keep a known-good
>> version of org-mode installed outside the source tree and always run
>> the full test suite before using a new version from master.

> Yes, if the absolutely latest master doesn't work, people can just check
> out whatever version was working for them last and continue without
> waiting for the next snapshot from ELPA /which may or may not work).

See below.

>> The more time that passes between releases, the harder it is to
>> release a new version.
>>
>> And as this is the case here, having easy access to the latest
>> “version” would lessen the effect of this.  It would also allow more
>> people to find bugs.

> It doesn't get any easier than it already is.

(How can this statement possibly be true?)

> Having both a stable and
> an unstable version of Org avilable via ELPA is a non-starter for the
> simple reason that the package manager can't deal with the versioning
> problems this would introduce.

This could, I assume, and was sort of implied in my original e-mail,
be solved by providing an “org” package as it is today (based off of
maint) and an “org-edge” package that’d be based off of master.

Re: Bleeding edge in elpa

[Rasmus]

Nikolai Weibull <now@disu.se> writes:

>> Having both a stable and
>> an unstable version of Org avilable via ELPA is a non-starter for the
>> simple reason that the package manager can't deal with the versioning
>> problems this would introduce.
>
> This could, I assume, and was sort of implied in my original e-mail,
> be solved by providing an “org” package as it is today (based off of
> maint) and an “org-edge” package that’d be based off of master.

As I think somebody said, the correct "fix" to this problem is more
frequent released.  I'm sure Bastien would appreciate help with this.
Do you want to volunteer?

—Rasmus

-- 
One thing that is clear: it's all down hill from here 

Re: Bleeding edge in elpa

[T.F. Torrey]

Hello,

Rasmus <rasmus@gmx.us> writes:

> As I think somebody said, the correct "fix" to this problem is more
> frequent released.  I'm sure Bastien would appreciate help with this.
> Do you want to volunteer?

If the goal is to have the latest and greatest version of Org available via
ELPA (for all the reasons some people use ELPA instead of git), there
are two obvious options:

1. Org could have a stable release every month or so.

2. The Org server could be configured to automatically package the
master version of Org every day, as the maint version is now.

Option 1 is widely regarded as the best choice.  However, it requires a
lot of actual, repeated human effort.  As Debian repeatedly
demonstrates, this is very hard to do, even once.  If option 1 could be
done, it would already be done.

Option 2 would be a one-time (mostly) human effort, and the daily work
would be automated.

So, if the goal is to have the latest and greates version of Org
available via ELPA (and it should be), option 2 is the only one that is
possible in the real world, so that's the one we should set up.

All the best,
Terry
--
T.F. Torrey

Re: Bleeding edge in elpa

[Aaron Ecay]

Hi Terry,

2015ko martxoak 9an, "T.F. Torrey"-ek idatzi zuen:
>
> Hello,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> As I think somebody said, the correct "fix" to this problem is more
>> frequent released.  I'm sure Bastien would appreciate help with this.
>> Do you want to volunteer?
>
> If the goal is to have the latest and greatest version of Org available via
> ELPA (for all the reasons some people use ELPA instead of git), there
> are two obvious options:
>
> 1. Org could have a stable release every month or so.
>
> 2. The Org server could be configured to automatically package the
> master version of Org every day, as the maint version is now.
>
> Option 1 is widely regarded as the best choice.  However, it requires a
> lot of actual, repeated human effort.  As Debian repeatedly
> demonstrates, this is very hard to do, even once.  If option 1 could be
> done, it would already be done.
>
> Option 2 would be a one-time (mostly) human effort, and the daily work
> would be automated.

But what would not be automated is the actual human effort that goes into
making a release: writing NEWS and documentation for new features, testing
for regressions, generating the emacs Changelog files, merging changes
from emacs trunk back into to org code base, merging org code into emacs
trunk, ...  Someone still has to do all those things eventually.  Or not,
and the quality of org as a software product suffers.

--
Aaron Ecay

Re: Bleeding edge in elpa

[T.F. Torrey]

Hello Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

>> If the goal is to have the latest and greatest version of Org available via
>> ELPA (for all the reasons some people use ELPA instead of git), there
>> are two obvious options:
>>
>> 1. Org could have a stable release every month or so.
>>
>> 2. The Org server could be configured to automatically package the
>> master version of Org every day, as the maint version is now.
>>
>> Option 1 is widely regarded as the best choice.  However, it requires a
>> lot of actual, repeated human effort.  As Debian repeatedly
>> demonstrates, this is very hard to do, even once.  If option 1 could be
>> done, it would already be done.
>>
>> Option 2 would be a one-time (mostly) human effort, and the daily work
>> would be automated.
>
> But what would not be automated is the actual human effort that goes into
> making a release: writing NEWS and documentation for new features, testing
> for regressions, generating the emacs Changelog files, merging changes
> from emacs trunk back into to org code base, merging org code into emacs
> trunk, ...  Someone still has to do all those things eventually.  Or not,
> and the quality of org as a software product suffers.

Refusing to make the git master version available through ELPA doesn't
help any of those things get done.  It simply denies the latest Org to
those unable or afraid of using git.

Of the things in your list, I think only the NEWS and Changelog are
absent from the master branch in git.  Lots of us happily use Org master
from git without them every day.  Do they really need to be done at
all?

If Emacs 25 is taking Org out of core, does the code still have to be
merged into the trunk?

If the manpower does not exist to support both a maint and a master
branch, maybe they should be merged.  Could that be done?

Still just trying to make it easier to spread the gospel of Org,
Terry
-- 
T.F. Torrey

Re: Bleeding edge in elpa

[Aaron Ecay]

Hi Terry,

2015ko martxoak 10an, "T.F. Torrey"-ek idatzi zuen:

> Of the things in your list, I think only the NEWS and Changelog are
> absent from the master branch in git.  Lots of us happily use Org master
> from git without them every day.  Do they really need to be done at
> all?

Many people are very happy not using org at all.  Perhaps we should just
all quit and find other hobbies.  OTOH, release milestones are important
to the health of a software project and so yes, really need to be done.

>
> If Emacs 25 is taking Org out of core, does the code still have to be
> merged into the trunk?

This is not on the table.  Rather, the (tentative) proposal from the
emacs side is for some packages to be developed in the GNU ELPA
repository, and be extracted from there and bundled with emacs release
tarballs (in addition to being released in ELPA).

Org is sometimes cited as an example of a package that would benefit from
this strategy, but there has been no discussion of this from the org
side, and AFAIK no decision has been made whether we’d take advantage of
this facility if/when it’s available.

>
> If the manpower does not exist to support both a maint and a master
> branch, maybe they should be merged.  Could that be done?
>
> Still just trying to make it easier to spread the gospel of Org,

Exposing new users to the vagaries of the master branch may rather lead
to atheism.

--
Aaron Ecay

Re: Bleeding edge in elpa

[T.F. Torrey]

Hello Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> Hi Terry,
>
> 2015ko martxoak 10an, "T.F. Torrey"-ek idatzi zuen:
>
>> Of the things in your list, I think only the NEWS and Changelog are
>> absent from the master branch in git.  Lots of us happily use Org master
>> from git without them every day.  Do they really need to be done at
>> all?
>
> Many people are very happy not using org at all.  Perhaps we should just
> all quit and find other hobbies.  OTOH, release milestones are important
> to the health of a software project and so yes, really need to be done.

You seem to be arguing with a point I wasn't making.  Release milestones
are fine, but the current plan for doing them is too much work for the
people involved.  Couldn't a simpler way work?

>> If Emacs 25 is taking Org out of core, does the code still have to be
>> merged into the trunk?
>
> This is not on the table.  Rather, the (tentative) proposal from the
> emacs side is for some packages to be developed in the GNU ELPA
> repository, and be extracted from there and bundled with emacs release
> tarballs (in addition to being released in ELPA).
>
> Org is sometimes cited as an example of a package that would benefit from
> this strategy, but there has been no discussion of this from the org
> side, and AFAIK no decision has been made whether we’d take advantage of
> this facility if/when it’s available.

Interesting.

> Exposing new users to the vagaries of the master branch may rather lead
> to atheism.

This sounds like the foot-shooting argument again.  Could one not just
as easily harm one's foot with the master version from git?  Or is the
assumption that only git users are smart enough to wield the power?
Maybe Org is so powerful that it should not be released via by ELPA at
all, for the sake of everyone's appendages.

All the best,
Terry
-- 
T.F. Torrey

Re: Bleeding edge in elpa

[Nick Dokos]

tftorrey@tftorrey.com (T.F. Torrey) writes:

> Aaron Ecay <aaronecay@gmail.com> writes:

>  ...
>> Exposing new users to the vagaries of the master branch may rather lead
>> to atheism.
>
> This sounds like the foot-shooting argument again.  Could one not just
> as easily harm one's foot with the master version from git?  Or is the
> assumption that only git users are smart enough to wield the power?
> Maybe Org is so powerful that it should not be released via by ELPA at
> all, for the sake of everyone's appendages.
>

I took Aaaron's comment to mean that most users would be happier *not*
using the master branch (however obtained), relying instead on the maint
branch.

Nick

Re: Bleeding edge in elpa

[T.F. Torrey]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> It doesn't get any easier than it already is.  Having both a stable and
> an unstable version of Org avilable via ELPA is a non-starter for the
> simple reason that the package manager can't deal with the versioning
> problems this would introduce.

I think this is not only not a "non-starter", I think it is very easy
with the existing package manager.

The package manager can only handle one version of a package *per
archive*, so instead use one archive per version.

The current daily builds are here:

http://orgmode.org/elpa/

To allow choosing between stable (maint) and unstable (master), put the
package archives here instead:

Stable: http://orgmode.org/elpa-stable/

Unstable: http://orgmode.org/elpa-unstable/

Then, just add-to-list 'package-archives whichever flavor you want.

(And actually, to do away with the current conflict between the org and
org-plus-contrib packages, each of those should be in a separate
archive as well.)

If the next version of Emacs breaks Org out of core into the GNU ELPA
package archive, things can be even easier:  Keep the stable version in
the GNU package archive, and keep the unstable version in the archive on
the orgmode.org server.

(And personally, I think the "contrib" parts should either be merged
into the core or split into separate packages, but that's another can of
worms.)

All the best,
Terry
--
T.F. Torrey

Re: Bleeding edge in elpa

[Achim Gratz]

T.F. Torrey writes:
> The package manager can only handle one version of a package *per
> archive*, so instead use one archive per version.

The version of package manager that people most likely use today always
choses the latest version from _any_ archive available when you update.
You can't tell it to consider some archive more authoritative than
another or that it should stick with whatever source archive the package
was originally installed from.

> The current daily builds are here:
[…]

That sort of contorsionist gymnastics defeats the whole point of having
a package manager in the first place.  If every package would have to do
that we'd all end up juggling dozens of archives in our config files.

> If the next version of Emacs breaks Org out of core into the GNU ELPA
> package archive, things can be even easier:  Keep the stable version in
> the GNU package archive, and keep the unstable version in the archive on
> the orgmode.org server.

I wouldn't hold my breath.  At the moment that mechanism by which to do
that is certainly not in place and there's no agreement on what it
should look like.

> (And personally, I think the "contrib" parts should either be merged
> into the core or split into separate packages, but that's another can of
> worms.)

if you want to move things into core, clean those files up, create tests
and get the copyrights assignmed to the FSF by their authors and propose
their inclusion.

If you want separate packages, I'm quite certain that this needs further
modifications at least to some of the files.  The current mode of
operation is that they should be compiled together with the rest of Org
and no checks are made if they work if installed sepaerately.  Some of
them likely do, others probably not.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Bleeding edge in elpa

[T.F. Torrey]

Achim Gratz <Stromeko@nexgo.de> writes:

> The version of package manager that people most likely use today always
> choses the latest version from _any_ archive available when you update.
> You can't tell it to consider some archive more authoritative than
> another or that it should stick with whatever source archive the package
> was originally installed from.

Of course.  My explanation was worded poorly, because instead of
sleeping I was wasting my time supporting someone else's request to be
able to get the latest version of Org via ELPA.

>> The current daily builds are here:
> […]
>
> That sort of contorsionist gymnastics defeats the whole point of having
> a package manager in the first place.  If every package would have to do
> that we'd all end up juggling dozens of archives in our config files.

The guidance for using Org via ELPA is already to "add the
Orgmode.org/elpa archive" (paraphrased).  Changing that to "add
Orgmode.org/elpa-stable for the stable version or
Orgmode.org/elpa-unstable for the bleeding edge version" is suddenly
contortionist gymnastics?  Really?  Compared to using git?

>> If the next version of Emacs breaks Org out of core into the GNU ELPA
>> package archive, things can be even easier:  Keep the stable version in
>> the GNU package archive, and keep the unstable version in the archive on
>> the orgmode.org server.
>
> I wouldn't hold my breath.  At the moment that mechanism by which to do
> that is certainly not in place and there's no agreement on what it
> should look like.

Agreement or not, something will be done.  Already the mechanisms are in
place that put the maint version in both locations.  The biggest
obstacle I to this that I see is that developers tend to hate the
package manager and love git.

>> (And personally, I think the "contrib" parts should either be merged
>> into the core or split into separate packages, but that's another can of
>> worms.)
>
> if you want to move things into core, clean those files up, create tests
> and get the copyrights assignmed to the FSF by their authors and propose
> their inclusion.
>
> If you want separate packages, I'm quite certain that this needs further
> modifications at least to some of the files.  The current mode of
> operation is that they should be compiled together with the rest of Org
> and no checks are made if they work if installed sepaerately.  Some of
> them likely do, others probably not.

Yes, either choice would be an effort.

However, there is currently the problem that some packages depend on
org, and others on org-plus-contrib, which cause both to be installed
(without some controtionist gymnastics).  IMHO, the Org package at
Orgmode.org/elpa should either always include contrib, as the git
repository does, or split the contrib part into an org-contrib package
that depends on org.

All the best,
Terry
-- 
T.F. Torrey

Re: Bleeding edge in elpa

[Alexis]

On 2015-03-10T06:21:10+1100, T.F. Torrey <tftorrey@tftorrey.com> 
said:

 TFT> The biggest obstacle I to this that I see is that developers 
 tend TFT> to hate the package manager and love git.

This developer appreciates both, and thus particularly appreciates 
MELPA as well. :-)


Alexis.

Re: Bleeding edge in elpa

[Grant Rettke]

`package-pinned-packages' seems to allow for user choice here. It is
still easy to muck up one's installation, but that is between the user
and package.el, not any particular package, I believe.

On Tue, Mar 10, 2015 at 6:01 AM, Alexis <flexibeast@gmail.com> wrote:
>
> On 2015-03-10T06:21:10+1100, T.F. Torrey <tftorrey@tftorrey.com> said:
>
> TFT> The biggest obstacle I to this that I see is that developers tend TFT>
> to hate the package manager and love git.
>
> This developer appreciates both, and thus particularly appreciates MELPA as
> well. :-)
>
>
> Alexis.
>



-- 
Grant Rettke
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: Bleeding edge in elpa

[T.F. Torrey]

A major benefit of an ELPA version of the "bleeding edge" version of
Org is that it enables those of us who run Emacs and Org on machines
where we can not install git (or just do not want to) to have the latest
version of Org nonetheless.

In a real-world situation, I want to collaborate on Org files with my
wife and parents, and I want to use the current best version of Org
(which has significant improvements to #+INCLUDE that I use), but I do
not want to try to install git on their Windows machines, and I do not
want to scare them off by introducing the world of Git in addition to
Emacs.  And it's not limited to #+INCLUDE.  I've been using Org for many
years, and no matter how good a release of Org has been, the version in
maint has followed right behind with new killer features.  Having that
version in Elpa makes it easier for me to share the awesome.

Aaron Ecay <aaronecay@gmail.com> writes:

> IMO this is a bad idea.  The bleeding edge version is expected to be
> somewhat unstable, and exposing it via ELPA will lead to foot-shooting
> incidents.

I understand this concern in principle, but it is difficult for me to
imagine how it would be validated in actual usage.

Serious Org users are already forced to install and run git to use the
master version, and whatever the dangers, the practice is almost
completely without problems.  A "bleeding edge" ELPA would merely make
that simpler.

I regularly use both the git master version of Org and the ELPA version
of Org, and I do extensive elisp coding that interacts with both, and I
do not remember a problem that could be described as "foot-shooting".

Any significant problems in a bleeding edge version would be resolved
the same way they are in the master version of git, only with the
solution packaged, delivered, and installed by the next day, except
automatically.

It is easy to imagine someone else unofficially packaging the bleeding
edge version and making it available via ELPA, and hard to imagine that
resulting in significant problems.  Melpa is loaded with bleeding edge
versions, but the problems I hear or see from it are very rare.

Also, as noted before, if someone is unhappy with the "bleeding edge"
version, switching back would be easy.

> On the other hand, it would be nice to have more regular releases from
> master to maint.  AFAIK the last one was a year and a half ago (Org
> 8.2).  However, this has traditionally required a lot of effort from
> Bastien and others, so it’s not a simple case of “wishing will make it
> so”.

Very true, and no doubt there are benefits to having a "stable" version
 available.

However, not providing the "bleeding edge" version on ELPA is not
without cost.  The mailing list is littered with responses from Nicolas
saying "that problem has been fixed in the master version ...."

One last thought: I think it would be better to name the versions
"stable" and "unstable", to match the meanings established by Debian.

All the best,
Terry
--
T.F. Torrey

Re: Bleeding edge in elpa

[Rasmus]

Hi,

tftorrey@tftorrey.com (T.F. Torrey) writes:

> I want to collaborate on Org files with my wife and parents,
    ^^^^^^^
    
Do you?  It sounds cool!

> In a real-world situation, I want to collaborate on Org files with my
> wife and parents, and I want to use the current best version of Org
> (which has significant improvements to #+INCLUDE that I use), but I do
> not want to try to install git on their Windows machines,

I agree.  I have the same problem when I build documents (via CI) on a
remote Debian server where I don't want to mess around with anything more
than what comes with Emacs by default.

> Serious Org users are already forced to install and run git to use the
> master version, and whatever the dangers, the practice is almost
> completely without problems.  A "bleeding edge" ELPA would merely make
> that simpler.

I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
of other packages will move to GNU ELPA and thus separate release channels
(these packages will still be bundled with Emacs).  This means we can push
out new versions easily, making more frequent releases more attractive.
Again, if you want to help out with preparing releases just let the list
and Bastien now.

—Rasmus

-- 
I feel emotional landscapes they puzzle me

Re: Bleeding edge in elpa

[Achim Gratz]

Rasmus writes:
> I agree.  I have the same problem when I build documents (via CI) on a
> remote Debian server where I don't want to mess around with anything more
> than what comes with Emacs by default.

You can use a tarball and the support for manual builds, described in:
http://orgmode.org/worg/dev/org-build-system.html#sec-7

> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
> of other packages will move to GNU ELPA and thus separate release channels
> (these packages will still be bundled with Emacs).  This means we can push
> out new versions easily, making more frequent releases more
> attractive.

None of this is going to lift one core limitation of package manager:
"there can be only one".  It doesn't support packages that subsume other
packages, so "org-whatever" is totally different from "org" and would be
installed together when referenced by dependencies even though it makes
no sense.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Bleeding edge in elpa

[Rasmus]

Achim Gratz <Stromeko@nexgo.de> writes:

> Rasmus writes:
>> I agree.  I have the same problem when I build documents (via CI) on a
>> remote Debian server where I don't want to mess around with anything more
>> than what comes with Emacs by default.
>
> You can use a tarball and the support for manual builds, described in:
> http://orgmode.org/worg/dev/org-build-system.html#sec-7

I have no desire to use anything more than what comes with emacs-24-nox on
this system.

>> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
>> of other packages will move to GNU ELPA and thus separate release channels
>> (these packages will still be bundled with Emacs).  This means we can push
>> out new versions easily, making more frequent releases more
>> attractive.
>
> None of this is going to lift one core limitation of package manager:
> "there can be only one".  It doesn't support packages that subsume other
> packages, so "org-whatever" is totally different from "org" and would be
> installed together when referenced by dependencies even though it makes
> no sense.

I'm arguing against "org-whatever" and for less time between Org version N
and (1+ N).

—Rasmus

-- 
. . . The proofs are technical in nature and provides no real understanding

Re: Bleeding edge in elpa

[Achim Gratz]

Rasmus writes:
>> You can use a tarball and the support for manual builds, described in:
>> http://orgmode.org/worg/dev/org-build-system.html#sec-7
>
> I have no desire to use anything more than what comes with emacs-24-nox on
> this system.

You can download any git commit directly from orgmode.org as a tarball
(or use the daily snapshot), via Emacs.  The rest of the installation
doesn't need any outside tools either.

To get the tip of master, try for instance:
http://orgmode.org/cgit.cgi/org-mode.git/snapshot/org-mode-master.tar.gz


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Bleeding edge in elpa

[T.F. Torrey]

Hello again,

Achim Gratz <Stromeko@nexgo.de> writes:

> Rasmus writes:
>> I agree.  I have the same problem when I build documents (via CI) on a
>> remote Debian server where I don't want to mess around with anything more
>> than what comes with Emacs by default.
>
> You can use a tarball and the support for manual builds, described in:
> http://orgmode.org/worg/dev/org-build-system.html#sec-7

I think there is even an existing way to automate the whole process,
isn't there?  Org is awesome.

But still, we were looking for an ELPA solution, not just a different
workaround.

>> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
>> of other packages will move to GNU ELPA and thus separate release channels
>> (these packages will still be bundled with Emacs).  This means we can push
>> out new versions easily, making more frequent releases more
>> attractive.
>
> None of this is going to lift one core limitation of package manager:
> "there can be only one".  It doesn't support packages that subsume other
> packages, so "org-whatever" is totally different from "org" and would be
> installed together when referenced by dependencies even though it makes
> no sense.

I wrote in my other e-mail that the limit is one per archive, but I
don't think that's technically true.  I think you can actually have as
many as you want, even from the same archive, but only the one with the
newest date (actually, greatest file name) will be installed.

So, to make all the packages that depend on Org use the unstable version
rather than the stable version, add-to-list 'package-archives the
unstable archive rather than the stable archive.

And if you want to keep have both the GNU archive and the Orgmode.org
archive in your package-archives, and you want to have the unstable
version from Orgmode.org installed instead of the stable version from
the GNU archive, no problem:  The one in the GNU archive has an older
date because the unstable one on the Orgmode.org server gets updates
every day, and thus the package manager will select that one to install.

IIUC,
Terry
--
T.F. Torrey

Re: Bleeding edge in elpa

[T.F. Torrey]

Hello again,

Rasmus <rasmus@gmx.us> writes:

>> I want to collaborate on Org files with my wife and parents,
>     ^^^^^^^
>     
> Do you?  It sounds cool!

It's complicated.

I've convinced my parents to begin writing memoir-type books, and my
wife works in non-profit, where good books are always good solutions.  I
push them toward using plain text files for the benefits we all know,
and because I can turn the files into epub books, Kindle books, and PDF
print books using my custom Org export code.

I would love to introduce them to the awesomeness of Org.  I think they
could work in Emacs, and I'm sure they could handle updating things via
ELPA, but I'm also pretty sure that the sight of git would send them
screaming all the way back to Microsoft Word.

At the same time, I don't want to use or write my custom code for an old
version of Org, and the files produced by the maint and master versions
of Org are slightly incompatible.

So.  The current process is for them to use Markdown formatting in their
plain-text files.  At least these can be converted with a quick script
(and Calibre's ebook-convert) to epub, Kindle, and pdf versions.  These
are okay, but not great.  For "final" versions, I will need to convert
the Markdown down Org using Pandoc, then do the pretty exports using my
Manuscript package.  This is not a solution.  This is a labor-intensive,
error-prone hack.

I would so much prefer to get them into Emacs and Org.  And I could, if
the master version was availble through ELPA.

>> In a real-world situation, I want to collaborate on Org files with my
>> wife and parents, and I want to use the current best version of Org
>> (which has significant improvements to #+INCLUDE that I use), but I do
>> not want to try to install git on their Windows machines,
>
> I agree.  I have the same problem when I build documents (via CI) on a
> remote Debian server where I don't want to mess around with anything more
> than what comes with Emacs by default.

This is another great use-case for an ELPA version of the git master.

>> Serious Org users are already forced to install and run git to use the
>> master version, and whatever the dangers, the practice is almost
>> completely without problems.  A "bleeding edge" ELPA would merely make
>> that simpler.
>
> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
> of other packages will move to GNU ELPA and thus separate release channels
> (these packages will still be bundled with Emacs).  This means we can push
> out new versions easily, making more frequent releases more attractive.
> Again, if you want to help out with preparing releases just let the list
> and Bastien now.

I'm looking forward to this new arrangement (though it will be
interesting when, AFAIK, Gnus still doesn't have a workflow through
ELPA).  However, I don't see how this will make it easier to push out
new stable releases.  That still has the inherent problem that making
something called a "stable" version takes a lot of human effort.

I wonder how much effort it would take to copy onto my own machine the
scripts on the server that package the git maint version into an ELPA
version, and modify them to package master instead.  Probably not much.
I could host that on my own server, or maybe upload it to Melpa.  I
think I will look into that.

All the best,
Terry
--
T.F. Torrey

Re: Bleeding edge in elpa

[Richard Y. Kim]

tftorrey@tftorrey.com (T.F. Torrey) writes:

> I wonder how much effort it would take to copy onto my own machine the
> scripts on the server that package the git maint version into an ELPA
> version, and modify them to package master instead.  Probably not much.

The shell script below is what I use to create my own org-plus-contrib
ELPA package.

Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc.,
I've been creating my own packages over the past year or so.  This way I
know exactly which packages are installed in not only my emacs, but my
colleagues who use my packages.  So far this has worked out great for
me.


#!/bin/sh

# This script builds org-plus-contrib-YYYYMMDD.tar ELPA package from the git
# clone of org-mode.

if [ ! -f mk/server.mk ]; then
  echo "Current directory must be org-mode root directory"
  exit 1
fi

# Where to install the tarballs 
SERVROOT=$HOME/public_html/elpa/orgmode

# server.mk has the elpaplus makefile target
echo " include mk/server.mk" >> Makefile

make SERVROOT=$SERVROOT elpaplus elpaplus-up

# Undo the change made above
git checkout Makefile
rm -f archive-contents

# $SERVROOT/org-plus-contrib-YYYYMMDD.tar
# should now be created with today as value of YYYYMMDD.

Re: Bleeding edge in elpa

[Achim Gratz]

Richard Y. Kim writes:
> # server.mk has the elpaplus makefile target
> echo " include mk/server.mk" >> Makefile
[…]
> # Undo the change made above
> git checkout Makefile

You know, local.mk was introduced specifically so you wouldn't have to
do anything like that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Bleeding edge in elpa

[T.F. Torrey]

Achim Gratz <Stromeko@nexgo.de> writes:

> Richard Y. Kim writes:
>> # server.mk has the elpaplus makefile target
>> echo " include mk/server.mk" >> Makefile
> […]
>> # Undo the change made above
>> git checkout Makefile
>
> You know, local.mk was introduced specifically so you wouldn't have to
> do anything like that.

I did know that.  I remember the massive overhaul of the makefile
system (which, IIRC, you masterminded).

Unfortunately, I am not a makefile guru, so merely knowing that is not
enough.

I wish I had fewer dirty hacks in my life, but I'd rather get something
done with a dirty hack than not get it done at all.

All the best,
Terry
-- 
T.F. Torrey

Re: Bleeding edge in elpa

[T.F. Torrey]

emacs18@gmail.com (Richard Y. Kim) writes:

> tftorrey@tftorrey.com (T.F. Torrey) writes:
>
>> I wonder how much effort it would take to copy onto my own machine the
>> scripts on the server that package the git maint version into an ELPA
>> version, and modify them to package master instead.  Probably not much.
>
> The shell script below is what I use to create my own org-plus-contrib
> ELPA package.
>
> Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc.,
> I've been creating my own packages over the past year or so.  This way I
> know exactly which packages are installed in not only my emacs, but my
> colleagues who use my packages.  So far this has worked out great for
> me.

Looks excellent.  Thank you!

All the best,
Terry
-- 
T.F. Torrey

Re: Bleeding edge in elpa

[Bastien Guerry]

I believe GNU ELPA should contain the stable release.

Of course, this means we need to have a stable release cycle,
and we should put efforts into that, obviously.

-- 
 Bastien

Re: Bleeding edge in elpa

[Steinar Bang]

>>>>> Nikolai Weibull <now@disu.se>:

> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?

Isn't this what's MELPA is for?
 http://www.emacswiki.org/emacs/MELPA

Ie. GNU ELPA for the official releases and MELPA for git master HEAD.

Re: Bleeding edge in elpa

[Achim Gratz]

Steinar Bang writes:
> Isn't this what's MELPA is for?
>  http://www.emacswiki.org/emacs/MELPA

MELPA is unable to provide a correctly installable package for Org since
they just pull down the tree and don't do the necessary build steps.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves