hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: ANNOUNCEMENT: Git Migration In Progress (WAS => Re: Git Migration)
Date Thu, 22 May 2014 18:17:02 GMT
On Wed, May 21, 2014 at 11:23 AM, Andrew Purtell <apurtell@apache.org>wrote:

> ... I also believe we should rewrite history only in rare cases.
> ​​


On Wed, May 21, 2014 at 4:19 PM, Enis Söztutar <enis.soz@gmail.com> wrote:

> > crew).  On feature branches, lets see.  Squash if messy history (most
> > cases?)?
> >
> >
> ...
> For "official" feature branches which will be pushed to the main repo, I
> think we should
> require a similar thing. If people need a working branch with less-clean
> history, there is
> no need to push that to the asf repo.


On Wed, May 21, 2014 at 4:19 PM, Enis Söztutar <enis.soz@gmail.com> wrote:

> > The Accumulo doc makes for a good start [1] (ignoring where their
> branching
> > style is different to ours). It is informed by the Kafka contributors
> > workflow doc, also a good read [2]. When in doubt, do as we've done in
> the
> > past: e.g. adding patch to JIRA for hadoopqa run. Dump dev pains and
> > suggested solutions into this thread. Lets keep this thread alive with
> > issues we run into as a dev team and our (suggested) solutions. As our
> > practice diverges from that outline in docs above, lets note and add doc
> > locally?
> >
> +1 for a local doc.

I've made a small start.  Will try and collect all agreed herein (please
all keep dumping into this thread) and add it into the developer chapter.

> I think for existing release branches, the merge is out of question (if I
> understand this correctly). We always did trunk-first than cherry-pick into
> branches approach, while Accumulo suggests that we do earlier branch first,
> then merge into master. Since I don't have experience on this,
> not sure whether that will work for us or not.
I'd be fine w/ our starting out w/ our old practice (trunk first, then
other branches if needed making new issues if needed).  I'd not stop anyone
who'd want to try coming up from the other direction merging patch at the
earliest incidence; this seems more aligned w/ git-ness.

> >
> > I need to heads-up our FB brothers and sisters too....
> >

Our man Elliott is game after the dust settles.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message