Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> [git] Documentation and Plan of Action


+
Josh Elser 2013-06-05, 03:04
+
Josh Elser 2013-06-06, 01:58
+
Josh Elser 2013-06-11, 02:44
+
Sean Busbey 2013-06-11, 11:16
+
Josh Elser 2013-06-11, 12:55
+
Mike Drob 2013-06-11, 15:44
+
Josh Elser 2013-06-11, 16:05
+
Christopher 2013-06-11, 16:26
+
Josh Elser 2013-06-12, 00:46
+
Christopher 2013-06-12, 19:49
+
David Medinets 2013-06-13, 02:45
Copy link to this message
-
Re: [git] Documentation and Plan of Action
On Wed, Jun 12, 2013 at 10:45 PM, David Medinets
<[EMAIL PROTECTED]> wrote:
> It troubles me that we are referring to the master branch as unstable.
> While we are not following the dictums of Agile methodology it is clear to
> me that the master branch should always be potentially releasable. It is
> not a dumping ground for untested features or half-complete code.

I think the master should be generally stable, in the "nightly build"
sense. I thought that's why we discussed feature branches. I think
perhaps we're confusing "latest" and "subject to change prior to
release" with "unstable". This may be a question of semantics. What do
we mean if we say "unstable"? If we're defining it as "latest", "not
release-quality tested", or "subject to change before a release", I
think it's fine to call it "unstable". If we mean "partially completed
features that are not remotely ready to be tested for a release", I
think we definitely don't want that kind of "unstable" in master.

[snip]
> The SHA1 value of a change tracks it across all branches. No need to
> perform no-op merges. Simply check the branch history to see it contains
> the SHA1 hash you're interested in.
[snip]

I think it's still useful to merge forward (even if it's an effective
"no-op"), for two reasons:
1) It keeps the history between older supported versions and newer
versions linear, which makes it easier to merge non-"no-op" fixes
across supported versions.
2) It's still useful to record that a bug has been at least considered
and resolved in a newer branch, even if nothing needs to be done.
Simply requiring that the merge process be performed as a part of the
workflow helps prevent bug regression.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
+
Josh Elser 2013-06-13, 02:59
+
Mike Drob 2013-06-11, 23:10
+
Josh Elser 2013-06-11, 23:18
+
Mike Drob 2013-06-11, 23:25
+
Josh Elser 2013-06-11, 23:39
+
Christopher 2013-06-12, 20:21
+
Josh Elser 2013-06-12, 22:15
+
Christopher 2013-06-12, 23:09
+
Drew Farris 2013-06-13, 01:05
+
Josh Elser 2013-06-13, 01:16
+
David Medinets 2013-06-13, 02:48
+
Josh Elser 2013-06-13, 02:52
+
Drew Farris 2013-06-13, 01:38
+
Josh Elser 2013-06-13, 02:00
+
Josh Elser 2013-06-13, 03:23
+
Christopher 2013-06-13, 05:16
+
John Vines 2013-06-13, 17:36
+
Christopher 2013-06-13, 17:49
+
John Vines 2013-06-13, 17:55
+
Corey Nolet 2013-06-13, 20:26
+
Josh Elser 2013-06-13, 23:54
+
Josh Elser 2013-06-13, 23:52
+
Eric Newton 2013-06-12, 22:52
+
Christopher 2013-06-12, 21:35
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB