Home | About | Sematext search-lucene.com search-hadoop.com
 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