From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: ELPA update
Date: Thu, 29 Sep 2011 10:08:26 -0500 [thread overview]
Message-ID: <87d3ejidxx.fsf@lifelogs.com> (raw)
In-Reply-To: 87pqijwid8.fsf@keller.adm.naquadah.org
On Thu, 29 Sep 2011 16:09:07 +0200 Julien Danjou <julien@danjou.info> 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
next prev parent reply other threads:[~2011-09-29 15:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-27 14:25 ELPA update Julien Danjou
2011-09-27 15:53 ` Chong Yidong
2011-09-28 7:48 ` Julien Danjou
2011-09-28 8:41 ` Tassilo Horn
2011-09-28 14:05 ` Stefan Monnier
2011-09-28 17:30 ` Ted Zlatanov
2011-10-12 4:58 ` Stefan Monnier
2011-09-28 13:52 ` Ted Zlatanov
2011-09-28 14:00 ` Julien Danjou
2011-09-28 17:25 ` Ted Zlatanov
2011-09-28 17:28 ` Julien Danjou
2011-09-28 18:43 ` Ted Zlatanov
2011-09-28 20:58 ` Stefan Monnier
2011-09-28 23:01 ` PJ Weisberg
2011-09-29 1:16 ` Stephen J. Turnbull
2011-09-29 8:45 ` Ted Zlatanov
2011-09-29 10:14 ` Julien Danjou
2011-09-29 12:36 ` Ted Zlatanov
2011-09-29 14:09 ` Julien Danjou
2011-09-29 15:08 ` Ted Zlatanov [this message]
2011-09-29 12:26 ` Stephen J. Turnbull
2011-09-28 14:53 ` Eli Zaretskii
2011-09-29 7:43 ` Jambunathan K
2011-09-29 15:03 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d3ejidxx.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.