It's not an empty commit. It's just circumstantial that the changes for
your commit are empty. The fact that you noted "changes X version
version1 should not be applied to version2" is important and that merge
tracks such information.
The same is applicable when version1 and version2 depend on two
different versions of a dependency. Say your new code in version1 calls
a method whose signature changed in said dependency from the version
version1 depends on as opposed to the version of the dependency version2
depends on. Point being, after making the changes in version1, it is
your responsibility to make sure whatever necessary variants exist in
their appropriate versions.
On 06/11/2013 07:10 PM, Mike Drob wrote:
It was originally a general question, because I wasn't sure on what the
proper answer.
Actually, I'm still not quite clear - should the person who did the fix for
Version1 immediately do a merge into Version2 with an empty commit so that
history looks pretty? Or is it better to wait until the next merge and then
fix it as it happens? The first option sounds less liable to bite somebody
in the rear.
Probably worth expounding on the example work-flow in the documentation
though.
On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser <josh.el...@gmail.com> wrote:
The person who implements the workaround in Version1 should ensure that
when Version1 is merged into Version2, the correct code is present in
Version2.
Do you think this merits a section on the document or was this a general
question?
On 6/11/13 11:44 AM, Mike Drob wrote:
How do we handle the following situation:
There are two active development branches - versions 1 and 2. Branch 1
uses
external library version 7, while Branch 2 uses external library version
9. It is discovered that version 7 of the external library has a bug, with
a known workaround. In this case, the workaround should be applied to
branch 1, but does not need to be applied to branch 2. What is the
git-friendly way to make these changes, not merge them into the later
branch, but still have a proper history and allow future fixes against
branch 1 to merge cleanly?
Mike
On Tue, Jun 11, 2013 at 8:55 AM, Josh Elser <josh.el...@gmail.com> wrote:
Sean,
I was referring to Christopher's notes on the maven commands; using the
release plugin, making RCs, publishing to the ASF staging area, promoting
to the RC if the vote passes, etc.
http://mail-archives.apache.****org/mod_mbox/accumulo-dev/****
201305.mbox/%**
3CCAL5zq9bH8y0FyjXmmfXhWPj8axo****sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**
40mail.gmail.com%3E<http://**mail-archives.apache.org/mod_**
mbox/accumulo-dev/201305.mbox/**%**3CCAL5zq9bH8y0FyjXmmfXhWPj8axo**
sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**40mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/accumulo-dev/201305.mbox/%3CCAL5zq9bH8y0FyjXmmfXhWPj8axosn9dZ7%2Bu-R1DK4Y-WM1YoWg%40mail.gmail.com%3E>
I don't believe that information is markdown-ified/CMS'ed at all.
I did add the high-level release guide to that comment with a place
holder
for when we get the specifics also written down on the CMS.
On 6/11/13 7:16 AM, Sean Busbey wrote:
Release Guide:
http://accumulo.apache.org/****governance/releasing.html<http://accumulo.apache.org/**governance/releasing.html>
<http**://accumulo.apache.org/**governance/releasing.html<http://accumulo.apache.org/governance/releasing.html>
On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <josh.el...@gmail.com>
wrote:
Alright, I think I covered all of the content that's needed.
http://people.apache.org/~******elserj/git/git.html<http://people.apache.org/~****elserj/git/git.html>
<http://**people.apache.org/~**elserj/**git/git.html<http://people.apache.org/~**elserj/git/git.html>
<http://**people.apache.org/~**elserj/git/**git.html<http://people.apache.org/~elserj/git/**git.html>
<http://**people.apache.org/~elserj/git/**git.html<http://people.apache.org/~elserj/git/git.html>
Disclaimer, I actually got Christopher to say "it's kind of long...".
Yes,
this was intended. I'd rather be (painfully) explicit front and lift
out
a
TL;DR version from the master document.
_Please_ give feedback now as to what is still unclear about after
reading
the document. I'd hate to have wasted all of this time writing this to
just
change our minds again in the near future
Also, please look for text in _emphasis_ as these are things which I do
not believe were decided upon as a group. Copied here for your ease:
1. Need to ensure that deleting remote branches is not an issue.
History
is still intact so this should not grind against ASF policy.
2. Do we have a nice write-up of the release policies?
And, the last thing:
Is everyone ok with the default branch when cloning the repository
being
latest unstable branch (synonymous with what "trunk" is now)? If so, is
everyone ok with naming it `master`? This is what my vote is towards.
Once we get these questions answered and the process reviewed, I
believe
we're ready to move forward with the INFRA ticket.
- Josh
On 06/05/2013 09:58 PM, Josh Elser wrote:
For those who are interested:
Fork of CMS site:
https://svn.apache.org/repos/******<https://svn.apache.org/repos/****>
<https://svn.apache.org/**repos/** <https://svn.apache.org/repos/**>>
asf/accumulo/site/branches/******git/<https://svn.apache.org/****<https://svn.apache.org/**>
repos/asf/accumulo/site/****branches/git/<https://svn.**
apache.org/repos/asf/accumulo/**site/branches/git/<https://svn.apache.org/repos/asf/accumulo/site/branches/git/>
Active copy:
http://people.apache.org/~******elserj/git/git.html<http://people.apache.org/~****elserj/git/git.html>
<http://**people.apache.org/~**elserj/**git/git.html<http://people.apache.org/~**elserj/git/git.html>
<http://**people.apache.org/~**elserj/git/**git.html<http://people.apache.org/~elserj/git/**git.html>
<http://**people.apache.org/~elserj/git/**git.html<http://people.apache.org/~elserj/git/git.html>
Jira issue: https://issues.apache.org/******
jira/browse/ACCUMULO-1498<https://issues.apache.org/****jira/browse/ACCUMULO-1498>
<http**s://issues.apache.org/**jira/**browse/ACCUMULO-1498<https://issues.apache.org/**jira/browse/ACCUMULO-1498>
<http**s://issues.apache.org/**jira/**browse/ACCUMULO-1498<http://issues.apache.org/jira/**browse/ACCUMULO-1498>
<ht**tps://issues.apache.org/jira/**browse/ACCUMULO-1498<https://issues.apache.org/jira/browse/ACCUMULO-1498>
I finished a first draft of all but what should be done with Git
during/after a release (outlining RC tags, a final tag and cleanup for
the
branch which started said work, with corresponding merges upstream).
Again, any and all help, preferably the form of patchs :D, is welcome,
but comments on ACCUMULO-1498 are the next-best thing. I tried to
leave
placeholders on the site for information which needs to finalized by
the
devs.
On 06/04/2013 11:04 PM, Josh Elser wrote:
In an effort to track the abundance of information that we need to
define, manage, etc before making the development switch to git, I've
started a WIP document.
http://people.apache.org/~******elserj/git/git.html<http://people.apache.org/~****elserj/git/git.html>
<http://**people.apache.org/~**elserj/**git/git.html<http://people.apache.org/~**elserj/git/git.html>
<http://**people.apache.org/~**elserj/git/**git.html<http://people.apache.org/~elserj/git/**git.html>
<http://**people.apache.org/~elserj/git/**git.html<http://people.apache.org/~elserj/git/git.html>
Not all of the information included (perhaps "planned to be included"
at
this point) in the document is likely candidate for final inclusion
in
the
site (e.g. steps to contact INFRA, getting github mirrors, etc);
however, I
like writing in markdown and this gave me a template without having
to
do
other lifting of my own.
If people want to contribute, I'm more than happy to put something up
in
/accumulo/contrib so that multiple people can directly add/modify
information.
