emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ELPA update


From: Ted Zlatanov
Subject: Re: ELPA update
Date: Thu, 29 Sep 2011 10:08:26 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

On Thu, 29 Sep 2011 16:09:07 +0200 Julien Danjou <address@hidden> wrote: 

JD> On Thu, Sep 29 2011, Ted Zlatanov wrote:
>> In Git you can cherry-pick between branches, which makes a new commit ID
>> but the patch contents (including the commit message) are the same.  So
>> that lets you take just one change from one branch to another.  It's not
>> ideal but it's very easy to use and automate.

JD> Let's hope nobody will ever modify more than one file/package in a
JD> commit. Or your strategy will begin to be much more complicated. :)

So far it hasn't been a problem, most non-maintainer commits cover one
thing.

>> If that's too complicated or undesirable in Bazaar and there's no other
>> way to merge just a few commits from one branch to another, I'm open to
>> suggestions.  I still feel, no matter the merge mechanism, that we
>> should use the VCS branch and not the package version as the deciding
>> factor whether to publish a package.

JD> I do not disagree, this is actually kind of how the Linux kernel is
JD> handled if you look at it that way.

Yes, it's a common strategy.  It works well.

JD> But since there's only 2 branches (stable/dev) I'm just not sure it's
JD> the best approach here:
JD> - merging parts of -dev branch into a -stable branch is complicated

No more than managing 20+ package versions, and you have the benefit
that you can publish the branch directly from a cron job.

JD> - tagging a branch when it's ready to be publish with so many packages
JD>   is impossible since developement is happening there on multiple
JD>   packages at the same time

Right, tags are not so good with many moving parts.  Cherry-picking
is better to select only the "ready" pieces for promotion.

JD> At least, the solution to have a set of tags named "{$package}-ready"
JD> which would move on commits will assure that each package is put into
JD> ELPA at the right stage. You can even rollback by moving the tag.
JD> (I'm just not sure bzr can handle that correctly, and that the bzr users
JD> would not make mistakes)

I'm not sure tags would help as much as separate branches, but certainly
it could be beaten into a working state :)

Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]