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 Threaded View
Accumulo >> mail # dev >> [git] Documentation and Plan of Action


Copy link to this message
-
Re: [git] Documentation and Plan of Action
+1 for Josh just contacting infra to make this happen

On Wed, Jun 12, 2013 at 6:15 PM, Josh Elser <[EMAIL PROTECTED]> wrote:

> On Jun 12, 2013 4:21 PM, "Christopher" <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]>
> wrote:
> > > Alright, I think I covered all of the content that's needed.
> > >
> > > 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.
> >
> > I did read the whole thing. I would like to see a place for the
> > scenarios I contributed, but other than that, I think it's a
> > sufficient plan for transition.
>
> Are you planning to update it yourself or would you like me to? If you'd
> like me to, please refresh my mind on the specifics :)
> >
> > > _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
> >
> > One thing mentioned is the release instructions (how to create/stage a
> > release). I'm not sure things will work exactly the same as for svn,
> > but I hope they'll be very close (it might require an extra 'git push'
> > or something, after the normal steps expressed in assemble/build.sh).
> > I'd have to do some more experimenting with git and the
> > maven-release-plugin, after which I could write something up. I can do
> > this after the transition, though, and after I'm sure myself how to do
> > it smoothly. I don't think this should be a blocker, though.
> >
> > > 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.
> >
> > IMO, this is probably the most important thing remaining to find out,
> > since the described workflow that seems to have consensus assumes
> > this.
>
> Yay for your response from #infra. Thanks for taking the time to ask. I'll
> remove those caveats from the doc.
> >
> > > 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.
> >
> > +1, +1
>
> I'll update this section of the doc tonight.
> >
> > > Once we get these questions answered and the process reviewed, I
> believe
> > > we're ready to move forward with the INFRA ticket.
> >
> > +1
>
> Does anyone feel we need to call a vote on this plan? I feel lazy consensus
> is good enough given our previous poll on wanting to move to git in the
> first place.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
>
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