You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@physics.org> on 2021/05/06 22:26:11 UTC

Re: git repo for new bloodhound core work

Hi Dammina,

Sorry I meant to address this ages ago.. It does seem important to look at to some extent.

I'm not sold on the need for a develop branch at this point. For the moment I'm expecting us to be able to keep the main branch in a generally working order by ensuring that code goes through automated testing and code review ahead of merging. Potentially we could be using github pull requests for that.

With github in the mix we will naturally open ourselves up to the possibility of accepting changes from non-committers as pull requests. Beyond concerns around ownership of the code and how large a change would require an ICLA, I think this is something that is desirable.

This leaves the question of whether there is any advantage to Bloodhound committers also using forks on github from which to prepare their code and organise their own pull requests. To be honest I don't think I am going to mind feature branches being created a bit more directly but perhaps others have stronger views.

Cheers,
    Gary

On Wed, 9 Dec 2020, at 4:34 AM, Dammina Sahabandu wrote:
> Thanks Gary. Great work. I just cloned the new repo in Git.
> 
> For now I see that we only have the master branch that you have ported. Is
> it a good idea to create a new develop branch for the dev work?
> 
> Thanks,
> Dammina
> 
> On Thu, 24 Sep 2020 at 06:53, John Chambers <ch...@apache.org> wrote:
> 
> > Nice work.
> > Will try and make time tomorrow to clone the new repo.
> >
> > Cheers
> >
> > John
> >
> > On Wed, 23 Sep 2020, 18:54 Gary Martin, <ga...@physics.org> wrote:
> >
> > > OK, more than enough delay I think.
> > >
> > > I'll create the new repo as 'bloodhound-core', leaving the notifications
> > > as their defaults which will mean github related update emails going to
> > > this list. As with most choices I expect they will not be difficult to
> > > change.
> > >
> > > Then I'll look at pushing just our current code over to the new main
> > > branch.
> > >
> > > On Wed, 23 Sep 2020, at 12:47 PM, Gary Martin wrote:
> > > > On Wed, 23 Sep 2020, at 12:11 PM, John Chambers wrote:
> > > > > I think using git for the new work is a great idea and I agree with
> > > Greg
> > > > > that 'bloodhound-core' seems a more sensible name.
> > > >
> > > > Cool :)
> > > >
> > > > > Though I am wondering if we need to make it obvious that this
> > > repository is
> > > > > for a different version than what is currently held in the svn repo?
> > > >
> > > > Yeah, the current situation may well be confusing.
> > > >
> > > > I don't think that there is much we can do with repo naming to help
> > > > this if we don't want names to get too complicated. README.md files
> > > > being updated to refer to the changes once the dust settles on some of
> > > > these decisions may well be appropriate though.
> > > >
> > > > I think I am willing to let a bit of confusion live on for the short
> > > > term as long as we are fairly clear about what is going on in this
> > > > list. If we can resolve this within a week or two, that would probably
> > > > be a good result.
> > > >
> > > > We may need to wait a short while if we want to update our old
> > > > bloodhound instance with this information as there is a bit of work
> > > > going on with it at the moment.
> > > >
> > > > >
> > > > > Cheers
> > > > >
> > > > > John
> > > > >
> > > > > On Wed, 23 Sep 2020 at 08:32, Daniel Brownridge <
> > > daniel.brownridge@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Go go git! This this is a really good move as (re)learning SVN was
> > a
> > > > > > little bit of a barrier to entry for me.
> > > > > >
> > > > > > On 23/09/2020 03:53, Greg Stein wrote:
> > > > > > > How about just "bloodhound-core" ... the"bh" in "bhcore" seems
> > > redundant.
> > > > > > >
> > > > > > > Note that we could also ask Infra to perform some "magic" like
> > > renaming
> > > > > > > "bloodhound" to "bloodhound-archive" or such, and then make use
> > of
> > > > > > > "bloodhound" going forward.
> > > > > > >
> > > > > > > Note that requesting a new git repository is available via
> > > > > > > selfserve.apache.org, and I'd just note to be careful to check
> > the
> > > > > > answer,
> > > > > > > and avoiding creating bloodhound-bloodhound-blah. That used to
> > be a
> > > > > > common
> > > > > > > mistake (not sure if the code warns you nowadays).
> > > > > > >
> > > > > > > In any case, +1 for going ahead and switching to git, even though
> > > I'm an
> > > > > > > svn partisan. The advantages are much higher than any negatives.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > -g
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Sep 22, 2020 at 7:57 AM Gary Martin <
> > > gary.martin@physics.org>
> > > > > > wrote:
> > > > > > >
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> Judging by previous conversations long past (e.g. [1], [2]) I
> > > believe I
> > > > > > >> effectively have a mandate to switch to using git for at least
> > > some of
> > > > > > our
> > > > > > >> work and so I think we may as well try this out with the
> > > experimental
> > > > > > >> 'core' bloodhound stuff and see how we got from there.
> > > > > > >>
> > > > > > >> I am not expecting to migrate any old bloodhound work to any new
> > > git
> > > > > > repo
> > > > > > >> - any legacy work can stay in the subversion repo for any
> > ongoing
> > > > > > >> maintenance. Also, I am not intending to drop any of our other
> > > current
> > > > > > >> usages of subversion, be they public or private so, for
> > instance,
> > > the
> > > > > > >> "site" pages can remain there for now as I don't see as big
> > > advantages
> > > > > > in
> > > > > > >> moving these things for the moment.
> > > > > > >>
> > > > > > >>  From my point of view, I have been working with git more than
> > > > > > subversion
> > > > > > >> long enough that I am finding it a lot more difficult to work
> > > with.
> > > > > > Trying
> > > > > > >> to use git-svn doesn't feel a good enough solution for this,
> > > > > > particularly
> > > > > > >> at clone time. Maybe there are other solutions but I am not sure
> > > it is
> > > > > > >> worth putting in more effort to work them out.
> > > > > > >>
> > > > > > >> So, unless there are any big objections, I will be looking to
> > get
> > > this
> > > > > > >> done today. As there is already a bloodhound mirror of sorts on
> > > github
> > > > > > with
> > > > > > >> the bloodhound name, I will be calling the new repo
> > > > > > >>
> > > > > > >>      "bloodhound-bhcore"
> > > > > > >>
> > > > > > >> This name obviously gives an impression that there will be
> > > multiple
> > > > > > repos
> > > > > > >> associated with the new bloodhound. If anyone cares to change my
> > > mind on
> > > > > > >> this naming, I think the `bloodhound-` prefix is sensible and
> > > certainly
> > > > > > >> consistent with all other apache projects I have spotted so it
> > > will
> > > > > > just be
> > > > > > >> a question of whether there is a better "subname."
> > > > > > >>
> > > > > > >> Cheers,
> > > > > > >>      Gary
> > > > > > >>
> > > > > > >> [1]
> > > > > > >>
> > > > > >
> > >
> > https://lists.apache.org/thread.html/e2ce321621205b7131047e21c776ffcacd8516ecbac70ea2f665d761%40%3Cdev.bloodhound.apache.org%3E
> > > > > > >> [2]
> > > > > > >>
> > > > > >
> > >
> > https://lists.apache.org/thread.html/c3956214bd35ff57526d7e63fac86e2613499f6fc473275345ee6b61%40%3Cdev.bloodhound.apache.org%3E
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Cheers,
> > > >     Gary
> > >
> > > --
> > > Cheers,
> > >     Gary
> > >
> >
>

Re: git repo for new bloodhound core work

Posted by Greg Stein <gs...@gmail.com>.
On Thu, May 6, 2021 at 5:26 PM Gary Martin <ga...@physics.org> wrote:
>...

> With github in the mix we will naturally open ourselves up to the
> possibility of accepting changes from non-committers as pull requests.
> Beyond concerns around ownership of the code and how large a change would
> require an ICLA, I think this is something that is desirable.
>

The person who pushes/merges the PR becomes responsible for the change
under their ICLA. There is definitely a lot of <hand-wave> on what "large"
means. Honestly: I think that isn't something for the BH community to worry
about right now. If we get a PR, then we should do a Happy Dance,
rather than pondering on requesting an ICLA.

This leaves the question of whether there is any advantage to Bloodhound
> committers also using forks on github from which to prepare their code and
> organise their own pull requests. To be honest I don't think I am going to
> mind feature branches being created a bit more directly but perhaps others
> have stronger views.
>

I think we should just go with Commit-Then-Review for all committers. Just
make the change. All committers are all trusted to move the project forward
in a productive fashion. We can always make further edits to fix things.

Branches and PRs interposed between committers and the repository suggest a
lack of trust. Let's trust, then fix things as problems arise. Note that we
aren't going to be making releases any time soon, so any problems will not
extend beyond this community.

And frankly: we need to lower the barrier as much as possible. This
community needs some forward motion, and should avoid anything that might
slow that down.

Cheers,
-g