phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Shen <wills...@marinsoftware.com>
Subject Re: [DISCUSS] Maintaining the Site in Git Instead of SVN
Date Wed, 05 Jun 2019 18:48:19 GMT
Vincent, thanks for clearing up the discussion :)

Do folks have a preference on which of the following we should take? I'm
leaning toward 2).
1) move docs from SVN to a dedicated git repository
2) move docs from SVN to the main phoenix git repository, and publish site
from master branch
3) move docs from SVN to the main phoenix git repository, and publish site
from ______ branch

- Will

On Mon, Jun 3, 2019 at 10:54 AM Vincent Poon <vincentpoon@apache.org> wrote:

> I think the confusion here is stemming from two different things:
> 1)  Moving docs from SVN to git (potentially its own repo)
> 2) Moving docs into the same apache/phoenix repo as the source code.
>
> I think we should do #1, and not #2, which avoids the concerns Thomas and
> James have.
>
> On Mon, Jun 3, 2019 at 10:46 AM James Taylor <jamestaylor@apache.org>
> wrote:
>
> > The problem with committing docs with code is that the release happens
> much
> > later. We’ve always tried to get the doc changes pushed out before the
> > release is cut.
> >
> > On Mon, Jun 3, 2019 at 9:30 AM William Shen <willshen@marinsoftware.com>
> > wrote:
> >
> > > Thomas, that makes sense now. thanks for explaining. didnt catch that
> the
> > > first time. would it make sense to you guys that we publish the website
> > > from master, or should we publish from say the latest of 4.x?
> > >
> > > On Mon, Jun 3, 2019 at 9:11 AM Thomas D'Silva
> > > <tdsilva@salesforce.com.invalid> wrote:
> > >
> > > > William, I was referring to your comment about ensuring doc changes
> are
> > > > checked in with code changes.
> > > > I assume you meant this meant that the doc change would go in to the
> > same
> > > > pull request as the code change?
> > > > But I guess since we currently mostly commit patches to all branches
> > this
> > > > should be fine. We could have the website
> > > > module in one of the branches.
> > > >
> > > > On Sun, Jun 2, 2019 at 10:53 PM William Shen <
> > willshen@marinsoftware.com
> > > >
> > > > wrote:
> > > >
> > > > > I think we do need to come up with a strategy on how to maintain
> > > website
> > > > > documentation given that we have several versions that may
> > potentially
> > > > > conflict in documentation at times. Thomas, is this your main
> > concern?
> > > > >
> > > > >
> > > > > Josh - Would love to help drive it, though I’m not sure if i have
> all
> > > the
> > > > > right access to do so.
> > > > > Seems like we would need to:
> > > > > - commit the svn site directory into git master (I can create a
> patch
> > > but
> > > > > would need help committing this)
> > > > > - file an infra ticket to migrate the website, and enable
> git-pubsub
> > > > > (though I’m totally speak out of my knowledge here...)
> > > > >
> > > > > On Sun, Jun 2, 2019 at 11:42 AM Josh Elser <josh.elser@gmail.com>
> > > wrote:
> > > > >
> > > > > > Yeah, not sure I get your concern, Thomas. We only have one
> > website.
> > > > > >
> > > > > > From the ASF Infra side, svn-pubsub (what deploys our code on
SVN
> > > > > > check-in) works the same as git-pubsub. It should just be a
> request
> > > to
> > > > > > Infra to migrate the website from SVN to Git and then enable
> > > > > > git-pubsub.
> > > > > >
> > > > > > No concerns in doing this from me. Even better if you'd like
to
> > drive
> > > > > > it, William ;)
> > > > > >
> > > > > > On Fri, May 31, 2019 at 2:24 PM William Shen <
> > > > willshen@marinsoftware.com
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Thomas,
> > > > > > >
> > > > > > > Which release line do we currently base our documentation
on?
> Do
> > > you
> > > > > > think
> > > > > > > it makes sense to bring the site source into master, and
always
> > > > update
> > > > > > the
> > > > > > > site from master?
> > > > > > >
> > > > > > > - Will
> > > > > > >
> > > > > > > On Thu, May 30, 2019 at 8:46 PM Thomas D'Silva
> > > > > > > <tdsilva@salesforce.com.invalid> wrote:
> > > > > > >
> > > > > > > > Currently this would not be easy to do since we have
multiple
> > > > > > branches. If
> > > > > > > > we decide to
> > > > > > > > implement Lars' proposal to have a single branch and
a module
> > per
> > > > > > supported
> > > > > > > > HBase version
> > > > > > > > then we could have a module for the website as well.
> > > > > > > >
> > > > > > > > On Thu, May 30, 2019 at 7:03 PM swaroopa kadam <
> > > > > > swaroopa.kadam07@gmail.com
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Huge +1!
> > > > > > > > >
> > > > > > > > > On Thu, May 30, 2019 at 4:38 PM William Shen
<
> > > > > > willshen@marinsoftware.com
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > Currently, the Phoenix site is maintained
in and built
> from
> > > SVN
> > > > > > > > > > <https://svn.apache.org/repos/asf/phoenix/site>.
Not
> sure
> > > what
> > > > > > level
> > > > > > > > of
> > > > > > > > > > work it would require, but does it make
sense to move the
> > > > source
> > > > > > from
> > > > > > > > svn
> > > > > > > > > > to git, so contribution to the website can
follow the
> same
> > > > > JIRA/git
> > > > > > > > > > workflow as the rest of the project? It
could also make
> > sure
> > > > > > changes to
> > > > > > > > > > Phoenix code are checked in with corresponding
> > documentation
> > > > > > changes
> > > > > > > > when
> > > > > > > > > > needed.
> > > > > > > > > >
> > > > > > > > > > - Will
> > > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Swaroopa Kadam
> > > > > > > > > [image: https://]about.me/swaroopa_kadam
> > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.me/swaroopa_kadam?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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