Re: ELPA commit freeze

[Dmitry Gutov]

On 20.08.2013 17:45, Stefan Monnier wrote:
> > So we could check out the version before externals were introduces, erase
> > all their respective directories, then apply all commits made to the
> > "administrative" part of the tree, and then add the subtrees properly. Some
> > cleanup commits would have to be re-applied, but there's not a lot of them.
>
> We could try to do that.  I'm far form convinced it's worth the trouble.

Yep, I've tried that, and some of the subtree merges were done quite a 
while ago, e.g. coffee-mode. Maybe it's indeed not worth the trouble.

> > If it's too late, I suppose we can live with that, but this way we a) give
> > up an easy way to sync back, b) accept that we'll see each non-upstream
> > commit in externally maintained packages's histories twice: once for when
> > it's made, second after it's cherry-picked, committed to upstream and then
> > merged back into elpa.
>
> Not that "git subtree push" also duplicates the commits.  It just
> automates the process.  So, it's only a) that's lost.

Yes, I should've checked. So, if git-subtree does not include any 
additional conflict-resolving functionality, I guess sending commits 
from elpa to relevant upstreams by email should be close enough.

I guess the main drawback left is if anyone else looks at the 
description of how elpa is organized, thinks "git subtree!", and spends 
time trying to make it work properly.


That aside, could you look at the following emails? I sent them via 
Yandex's SMTP server accidentally and, as usual, they were bounced back 
from perlin.IRO.UMontreal.CA by timeout.

http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00521.html
http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00522.html