Re: [bloodhound-site] branch asf-site updated: stage the test

[Greg Stein]

Oh, and I didn't touch download.cgi and download.html, as Daniel switched
to using closer.lua ... the pages are still there, for when we want to
bring back a custom download page


On Fri, Aug 25, 2023 at 8:18 PM Greg Stein  wrote:

> My commit message was wrong. The test/staging site is:
> https://bloodhound-test.staged.apache.org/
>
> There are differences because I upgraded to Bootstrap 5.3.1 when moving to
> Pelican. So a good chunk of styling needs to be fixed.
>
> I did not convert index.html to Markdown at this time (tho it is sitting
> in index.md). It's still a bunch of raw HTML, wrapped by the page template
> at theme/templates/page.html
>
> Please feel free to submit Pull Requests to fix the (Bootstrap) styling,
> the site.css file, and move some stuff from HTML to Markdown. (and note
> that we're using GitHub Flavored Markdown; use those docs for syntax)
>
> When it "looks good", then we can pull the lever to publish to
> bloodhound.a.o instead of the staging site.
>
> Cheers,
> -g
>
> On Fri, Aug 25, 2023 at 8:13 PM  wrote:
>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> gstein pushed a commit to branch asf-site
>> in repository https://gitbox.apache.org/repos/asf/bloodhound-site.git
>>
>>
>> The following commit(s) were added to refs/heads/asf-site by this push:
>>  new 7a4eabb  stage the test
>> 7a4eabb is described below
>>
>> commit 7a4eabbd0a0170b85cfd195e40fe285041bf4b2e
>> Author: Greg Stein 
>> AuthorDate: Fri Aug 25 21:12:26 2023 -0400
>>
>> stage the test
>>
>> This should publish the site to bloodhound-test.a.o for review
>> ---
>>  .asf.yaml | 14 +++---
>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>
>> diff --git a/.asf.yaml b/.asf.yaml
>> index a844ed3..4c4e3df 100644
>> --- a/.asf.yaml
>> +++ b/.asf.yaml
>> @@ -1,11 +1,3 @@
>> -pelican:
>> -  target:   asf-site
>> -  whoami:   main
>> -
>> -github:
>> -  description:  "Apache Bloodhound Website Repository"
>> -  homepage: https://bloodhound.apache.org/
>> -  labels:
>> -- bloodhound
>> -- website
>> -- pelican
>> +staging:
>> +  profile: test
>> +  whoami:  asf-site
>>
>>

Re: [bloodhound-site] branch asf-site updated: stage the test

[Greg Stein]

My commit message was wrong. The test/staging site is:
https://bloodhound-test.staged.apache.org/

There are differences because I upgraded to Bootstrap 5.3.1 when moving to
Pelican. So a good chunk of styling needs to be fixed.

I did not convert index.html to Markdown at this time (tho it is sitting in
index.md). It's still a bunch of raw HTML, wrapped by the page template at
theme/templates/page.html

Please feel free to submit Pull Requests to fix the (Bootstrap) styling,
the site.css file, and move some stuff from HTML to Markdown. (and note
that we're using GitHub Flavored Markdown; use those docs for syntax)

When it "looks good", then we can pull the lever to publish to
bloodhound.a.o instead of the staging site.

Cheers,
-g

On Fri, Aug 25, 2023 at 8:13 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> gstein pushed a commit to branch asf-site
> in repository https://gitbox.apache.org/repos/asf/bloodhound-site.git
>
>
> The following commit(s) were added to refs/heads/asf-site by this push:
>  new 7a4eabb  stage the test
> 7a4eabb is described below
>
> commit 7a4eabbd0a0170b85cfd195e40fe285041bf4b2e
> Author: Greg Stein 
> AuthorDate: Fri Aug 25 21:12:26 2023 -0400
>
> stage the test
>
> This should publish the site to bloodhound-test.a.o for review
> ---
>  .asf.yaml | 14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/.asf.yaml b/.asf.yaml
> index a844ed3..4c4e3df 100644
> --- a/.asf.yaml
> +++ b/.asf.yaml
> @@ -1,11 +1,3 @@
> -pelican:
> -  target:   asf-site
> -  whoami:   main
> -
> -github:
> -  description:  "Apache Bloodhound Website Repository"
> -  homepage: https://bloodhound.apache.org/
> -  labels:
> -- bloodhound
> -- website
> -- pelican
> +staging:
> +  profile: test
> +  whoami:  asf-site
>
>

Re: Apache Bloodhound will be moving to the Attic

[Greg Stein]

Applied, and live. Thanks!!


On Fri, Aug 25, 2023 at 3:02 PM Daniel Brownridge 
wrote:

> Hi Greg,
>
> I've focused on updating the content of the current site to make it a
> little more friendly to new comers who are currently presented with dead
> links.
>
> So here is a patch to the current static website. It only affects
> index.html.
>
> Created by:
>
> $ svn diff index.html > siteupdate.patch
>
> Summary of changes:
>
>- Replace dead links to live.bloodhound.apache.org with most recent
>web.archive.org capture.
>- All original links are still present in the code just commented out
>so can be easily switched back when needed.
>- Brought details of the mailing list onto the main page.
>- Added a brief note about current state of the project in the getting
>involved section.
>- Minor tweaks to wording to make the page make sense given current
>situation.
>- Some re-formatting of dense HTML to make it easy to work with for
>manual editing.
>
> I have noted that there has been consensus reached to switch to Pelican
> (which I don't know). I thought I'd submit this patch anyway since I've
> done it and it should be quick to apply in the meantime while you're
> looking at Pelican. If Pelican is pretty much ready to go then the content
> of this patch may still be useful.
>
> Please could you review and apply if appropriate.
>
> Many thanks,
>
> Daniel
>
> *Daniel Brownridge*
> dan...@freshnewpage.com
> +44 779 138 5626
> On 21/08/2023 18:08, Greg Stein wrote:
>
> https://svn.apache.org/repos/asf/bloodhound/site/
>
> It is read-only, but I can override that to apply any patches you send to
> dev@
>
> Cheers,
> -g
>
>
> On Mon, Aug 21, 2023, 01:17 Daniel Brownridge 
> wrote:
>
>> Hi Gary,
>>
>> Untill we can get live back it might be a good idea tput some more basic
>> info on the landing page and remove the dead links etc.
>>
>> How is the website (bloodhound.apache.org) hosted / updated / where does
>> the code live?
>>
>> Happy to take on maintenance if that helps would just need some help
>> getting started?
>>
>> If this can be done by email great but also can co-ordinate a time when
>> both on-line if that helps?
>>
>> Cheers,
>> Daniel
>>
>> On Mon, 21 Aug 2023, 03:47 Gary Martin,  wrote:
>>
>>> Hi,
>>>
>>> It is certainly good to see some interest in getting things going again.
>>> I should probably have said something sooner but Greg did summarise the
>>> situation pretty well.
>>>
>>> From the point of view of where code is submitted, I totally understand
>>> the desire to use git rather than subversion when that is what people are
>>> likely to be most used to. When this has been discussed before I'm pretty
>>> sure we came to the conclusion that use of git would reduce barriers to
>>> participation. I don't want to be forcing anyone to use subversion.
>>>
>>> The bloodhound-core repo is already git only and if GitHub PRs are what
>>> the development community wants to use, we should support that.
>>>
>>> Meanwhile, I can't say I know if the older bloodhound repo can accept
>>> changes via gitbox or GitHub. If it is not currently set up correctly for
>>> that, we may still want to delay making changes until we decide that we are
>>> going to continue 0.8 development.  I imagine that INFRA has made it easy
>>> to do but it feels better not to ask for work that may not prove necessary.
>>> That said, if enough people disagree with my suggestion here then I will
>>> get to requesting it.
>>>
>>> I think that in principle we can get live.bloodhound working again. I
>>> can of course look into this. Using GitHub for issues for a while is fine
>>> though.
>>>
>>> I noted some potential concern about this list getting busy because of a
>>> lack of an issue tracker. I would still be encouraging us to use this
>>> mailing list for some discussion when issue tracking is restored. It
>>> provides a good point of contact for people who don't want to go through
>>> all the tickets. That is not to say that everything has to be discussed but
>>> some commentary that allows others to be brought into the discussion about
>>> the direction we are taking should be useful.
>>>
>>> There is probably plenty I haven't addressed here but I think that the
>>> direction of the project is an important one to discuss further. My
>>> experimental code has certainly n

Re: switch website to Pelican? (was: Apache Bloodhound will be moving to the Attic)

[Greg Stein]

And that makes (3) +1 binding votes. I've started setting up a
Pelican-based site. Should have it committed today or tomorrow.

I'll have it go to staging until it looks correct, then it will take over
as the source for the primary site.

Cheers,
-g


On Thu, Aug 24, 2023 at 10:20 AM John Chambers  wrote:

> I am happy enough to support moving the site to using Pelican and to having
> it's own repo to make life easier when maintaining it.
>
> Cheers
>
> John .
>
> On Tue, 22 Aug 2023 at 16:55, Greg Stein  wrote:
>
> > The site is outside of {trunks, tags, branches} so the auto-propagate
> > doesn't see it.
> >
> > The Pelican migration will be easy once we get a third binding vote
> > (myself, Gary so far).
> >
> > Daniel: please feel free to post site patches, rather than getting held
> up
> > awaiting migration.
> >
> > Cheers,
> > -g
> >
> >
> > On Tue, Aug 22, 2023 at 9:48 AM Gary Martin  wrote:
> >
> > > For some reason I thought that the site code might also be in the
> GitHub
> > > mirror of the main bloodhound.
> > >
> > > Anyway, personally I would be happy enough to support moving the site
> to
> > > its own repo and using pelican. Very good suggestions.
> > >
> > > Cheers,
> > > Gary
> > >
> > > On 22/08/2023 03:19, Greg Stein wrote:
> > > > Rather than using pure HTML/etc, I would suggest that we switch to
> > using
> > > > Pelican for site generation (sources move to markdown). Infra has
> > > provided
> > > > an automated workflow to move edits to published pages. See:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-PelicanCMS
> > > >
> > > > We can create a git repo named "bloodhound-site", and an edit/push
> of a
> > > .md
> > > > file would publish the page within a few seconds.
> > > >
> > > > There are a few publishing options, but Pelican is straightforward,
> > > > supported by Infra, and the tool is Python-based which is a "nice to
> > > have"
> > > > for this community (to better understand the tooling).
> > > >
> > > > Thoughts?
> > > >
> > > > Cheers,
> > > > -g
> > > >
> > > > On Mon, Aug 21, 2023 at 12:08 PM Greg Stein 
> wrote:
> > > >
> > > >
> > > >> https://svn.apache.org/repos/asf/bloodhound/site/
> > > >>
> > > >> It is read-only, but I can override that to apply any patches you
> send
> > > to
> > > >> dev@
> > > >>
> > > >> Cheers,
> > > >> -g
> > > >>
> > > >> On Mon, Aug 21, 2023, 01:17 Daniel Brownridge <
> > dan...@freshnewpage.com>
> > > >> wrote:
> > > >>
> > > >>
> > > >>> Hi Gary,
> > > >>>
> > > >>> Untill we can get live back it might be a good idea tput some more
> > > basic
> > > >>> info on the landing page and remove the dead links etc.
> > > >>>
> > > >>> How is the website (bloodhound.apache.org) hosted / updated /
> where
> > > does
> > > >>> the code live?
> > > >>>
> > > >>> Happy to take on maintenance if that helps would just need some
> help
> > > >>> getting started?
> > > >>>
> > > >>> If this can be done by email great but also can co-ordinate a time
> > when
> > > >>> both on-line if that helps?
> > > >>>
> > > >>> Cheers,
> > > >>> Daniel
> > > >>>
> > > >>>
> > > >> [snip]
> > > >>
> > > >
> > >
> >
>

Re: switch website to Pelican? (was: Apache Bloodhound will be moving to the Attic)

[Greg Stein]

The site is outside of {trunks, tags, branches} so the auto-propagate
doesn't see it.

The Pelican migration will be easy once we get a third binding vote
(myself, Gary so far).

Daniel: please feel free to post site patches, rather than getting held up
awaiting migration.

Cheers,
-g


On Tue, Aug 22, 2023 at 9:48 AM Gary Martin  wrote:

> For some reason I thought that the site code might also be in the GitHub
> mirror of the main bloodhound.
>
> Anyway, personally I would be happy enough to support moving the site to
> its own repo and using pelican. Very good suggestions.
>
> Cheers,
> Gary
>
> On 22/08/2023 03:19, Greg Stein wrote:
> > Rather than using pure HTML/etc, I would suggest that we switch to using
> > Pelican for site generation (sources move to markdown). Infra has
> provided
> > an automated workflow to move edits to published pages. See:
> >
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-PelicanCMS
> >
> > We can create a git repo named "bloodhound-site", and an edit/push of a
> .md
> > file would publish the page within a few seconds.
> >
> > There are a few publishing options, but Pelican is straightforward,
> > supported by Infra, and the tool is Python-based which is a "nice to
> have"
> > for this community (to better understand the tooling).
> >
> > Thoughts?
> >
> > Cheers,
> > -g
> >
> > On Mon, Aug 21, 2023 at 12:08 PM Greg Stein  wrote:
> >
> >
> >> https://svn.apache.org/repos/asf/bloodhound/site/
> >>
> >> It is read-only, but I can override that to apply any patches you send
> to
> >> dev@
> >>
> >> Cheers,
> >> -g
> >>
> >> On Mon, Aug 21, 2023, 01:17 Daniel Brownridge 
> >> wrote:
> >>
> >>
> >>> Hi Gary,
> >>>
> >>> Untill we can get live back it might be a good idea tput some more
> basic
> >>> info on the landing page and remove the dead links etc.
> >>>
> >>> How is the website (bloodhound.apache.org) hosted / updated / where
> does
> >>> the code live?
> >>>
> >>> Happy to take on maintenance if that helps would just need some help
> >>> getting started?
> >>>
> >>> If this can be done by email great but also can co-ordinate a time when
> >>> both on-line if that helps?
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> >>>
> >> [snip]
> >>
> >
>

Re: switch website to Pelican? (was: Apache Bloodhound will be moving to the Attic)

[Greg Stein]

Oh. ...

Looking: you're right. It requires signing into Confluence, which means
having an Apache account. Sorry about that. Investigating why it isn't
public.

Cheers,
-g


On Tue, Aug 22, 2023 at 5:55 AM Nikolay Tsanov  wrote:

> Fantastic idea!
>
> However, the Confluence page you provided responds with "We can't find that
> page. This could be because: * The page doesn't exist; *The page exists,
> but you don't have view permission for that space.".
>
> Is it because I am not on the contributors roster yet?
>
> Thanks,
>
> Nikolay
> +1-819-635-7198
>
> On Mon, Aug 21, 2023 at 10:20 PM Greg Stein  wrote:
>
> > Rather than using pure HTML/etc, I would suggest that we switch to using
> > Pelican for site generation (sources move to markdown). Infra has
> provided
> > an automated workflow to move edits to published pages. See:
> >
> >
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-PelicanCMS
> >
> > We can create a git repo named "bloodhound-site", and an edit/push of a
> .md
> > file would publish the page within a few seconds.
> >
> > There are a few publishing options, but Pelican is straightforward,
> > supported by Infra, and the tool is Python-based which is a "nice to
> have"
> > for this community (to better understand the tooling).
> >
> > Thoughts?
> >
> > Cheers,
> > -g
> >
> > On Mon, Aug 21, 2023 at 12:08 PM Greg Stein  wrote:
> >
> > > https://svn.apache.org/repos/asf/bloodhound/site/
> > >
> > > It is read-only, but I can override that to apply any patches you send
> to
> > > dev@
> > >
> > > Cheers,
> > > -g
> > >
> > > On Mon, Aug 21, 2023, 01:17 Daniel Brownridge  >
> > > wrote:
> > >
> > >> Hi Gary,
> > >>
> > >> Untill we can get live back it might be a good idea tput some more
> basic
> > >> info on the landing page and remove the dead links etc.
> > >>
> > >> How is the website (bloodhound.apache.org) hosted / updated / where
> > does
> > >> the code live?
> > >>
> > >> Happy to take on maintenance if that helps would just need some help
> > >> getting started?
> > >>
> > >> If this can be done by email great but also can co-ordinate a time
> when
> > >> both on-line if that helps?
> > >>
> > >> Cheers,
> > >> Daniel
> > >>
> > > [snip]
> >
>

signing an ICLA

[Greg Stein]

For those who may want to commit in the future (Daniel, Nikolay), please
follow the instructions on this page:
https://www.apache.org/licenses/contributor-agreements.html#clas

Fill in "bloodhound" on the project. That just sends emails to the right
places. Then submit your ICLA to secret...@apache.org

NOTE: this is simply greasing the wheels, but won't give you commit. That
requires the PMC to discuss, approve, and grant commit privileges. You can
read more about becoming a committer at:
https://community.apache.org/contributors/

Cheers,
-g

switch website to Pelican? (was: Apache Bloodhound will be moving to the Attic)

[Greg Stein]

Rather than using pure HTML/etc, I would suggest that we switch to using
Pelican for site generation (sources move to markdown). Infra has provided
an automated workflow to move edits to published pages. See:
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-PelicanCMS

We can create a git repo named "bloodhound-site", and an edit/push of a .md
file would publish the page within a few seconds.

There are a few publishing options, but Pelican is straightforward,
supported by Infra, and the tool is Python-based which is a "nice to have"
for this community (to better understand the tooling).

Thoughts?

Cheers,
-g

On Mon, Aug 21, 2023 at 12:08 PM Greg Stein  wrote:

> https://svn.apache.org/repos/asf/bloodhound/site/
>
> It is read-only, but I can override that to apply any patches you send to
> dev@
>
> Cheers,
> -g
>
> On Mon, Aug 21, 2023, 01:17 Daniel Brownridge 
> wrote:
>
>> Hi Gary,
>>
>> Untill we can get live back it might be a good idea tput some more basic
>> info on the landing page and remove the dead links etc.
>>
>> How is the website (bloodhound.apache.org) hosted / updated / where does
>> the code live?
>>
>> Happy to take on maintenance if that helps would just need some help
>> getting started?
>>
>> If this can be done by email great but also can co-ordinate a time when
>> both on-line if that helps?
>>
>> Cheers,
>> Daniel
>>
> [snip]

Re: Apache Bloodhound will be moving to the Attic

[Greg Stein]

ailed information so far. It feels like we're not quite dead (I
>> mean in
>> >> the Attic) yet, but will be soon if we don't do something.
>> >>
>> >> In the interests of maintaining momentum here ,which seems to be
>> >> gathering, I'll keep sharing my thoughts. I'm happy to help in
>> whatever way
>> >> I can.
>> >>
>> >> Personally I don't think I'm in a position to commit just yet even if I
>> >> wanted to, I've not yet signed an ICLA but have no problem doing so, I
>> just
>> >> never got round to it before. So, I'll make that my personal mission
>> for
>> >> this week, to sort that an any associated Apache official admin with
>> the
>> >> intention that that will put me in a position to be more useful to the
>> >> project going forward. As I get into that I may need to ask for more
>> >> specific help but I don't quite know what I'm asking for yet!
>> >>
>> >> As for some project goals it feels like there are two main areas we can
>> >> focus on.
>> >>
>> >> The first is practical getting the project up and running stuff. The
>> >> second is future development and direction stuff. To me that feels
>> like the
>> >> right order because if we focus on the former it gives a bit more time
>> to
>> >> gather our collective thoughts and discuss the later.
>> >>
>> >> So for the project part. I definitely support the use of Git as the
>> >> primary source code management system and think we should move towards
>> >> that. If that's GitHub then that completely works for me too. Correct
>> me if
>> >> I'm wrong, but I think that it was at one point that Bloodhound was
>> >> 'self-hosting' for Issues on live.bloodhound.apache.org and for
>> whatever
>> >> reason that's not the case now. Getting back to that feels like a nice
>> >> thing to aim for medium term. There may be multiple things involved in
>> >> doing that though and whilst this may seem contradictory I actually
>> also
>> >> agree with Nikolay in the short-term, which is we should just use
>> GitHub
>> >> issues (or whatever) until we've achieved the admin around getting a
>> live
>> >> Bloodhound up and running again.
>> >>
>> >> To elaborate a little on the above suggestion since it might seem odd,
>> >> through my work recently I've had a fair bit of experience with these
>> >> chicken-and-egg style problems and have dealt with a handful of
>> situations
>> >> where to achieve X you need Y but to have Y you first need X and
>> things go
>> >> round in circles for ages. But if you look at it differently and
>> realise
>> >> that although Z might not be what you want for some other reason in the
>> >> short term Z provides an alternative route to X and once you have X
>> you can
>> >> go back and get Y later then things unlock and you get moving again.
>> So if
>> >> 'GitHub Issues' can be our 'Z' here then I'm all for that.
>> >>
>> >> In the very-short term lacking any form of issue tracker it feels like
>> >> this mailing list probably has to serve as our main point of contact
>> until
>> >> we can fix that. That will mean that the mailing list in the short term
>> >> might get (relatively) busy (but as previously stated there are only a
>> few
>> >> of us so we can probably cope).
>> >>
>> >> As for the direction, I support transitioning Bloodhound to being
>> Django
>> >> based. I have to be honest I haven't yet looked in detail at the
>> >> experimental work that has been done by Gary in that area yet, but
>> that too
>> >> is going on my todo list. In general though I really like the idea of
>> >> having a Python based OpenSource issue tracker that is somewhat
>> comparable
>> >> in terms of practical utility to the likes of the more commercial
>> tools. By
>> >> that I mean multi-project, support workflows, and basic Agile features
>> such
>> >> as a backlog and Kanban board style view.
>> >>
>> >> So here is a starter for 10 suggested priority list (fully expecting
>> >> comments / disagreements but that's the point)
>> >>
>> >> 1. Get a live list of issues we can all get around, somehow, somewhere.
>> >> Current best suggestion (which I agree with) 

Re: git repo for new bloodhound core work

[Greg Stein]

Following the rest of this thread (archive at
https://lists.apache.org/thread/kohw9nr4x94wdh7w46y82x6ghy75znjh), there
were three PMC members supporting the move to git (Gary, Greg, John) with
implied consent from a fourth (Dammina).

Thus, I've gone ahead and made svn readonly [1].

Cheers,
-g

[1] private, readable by ASF committers:
https://github.com/apache/infrastructure-p6/commit/4174bc7d51b161f0862d9126d6a4f0fedb73090c


On Tue, Sep 22, 2020 at 7:57 AM Gary Martin  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
>

Re: Apache Bloodhound will be moving to the Attic

[Greg Stein]

On Sun, Aug 20, 2023 at 7:59 AM Nikolay Tsanov  wrote:
>...

> The choice of a version control system goes far beyond the tech stack, it
> defines the governance at the technology layer of the Bloodhound
> architecture
>

No. Governance is defined by Apache rules of peer conduct. The version
control system is orthogonal to how a community reaches consensus and
develops code.

If English language is the issue and you meant "DESIGN at the technology
layer of the Bloodhound architecture", then you're wrong. A version control
system has zero impact on architecture. The VCS merely helps to organize
workflow/process. git sucks at this, GitHub is awesome at this, and svn
falls in between.

>...

> In personal capacity, I must regretfully let you know that I will not
> invest any time until this essential technology architecture concern (Git
> vs SVN) is formally addressed
>

Never attempt extortion of the community to get what you want.

You can leave. Your contributions are not worth more than anybody else's,
and are certainly not required. The version control choice will not be made
by you.

-g

Re: Apache Bloodhound will be moving to the Attic

[Greg Stein]

On Fri, Aug 18, 2023 at 6:08 AM Nikolay Tsanov  wrote:

> Hi Greg,
>
> Two questions:
> 1. Is the verdict to send Bloodhound to the attic already rendered and you
> are simply letting us know about it, or there is still room for discussions?
> 2. If the debate is still open, how many commits are required per what
> period of time in order to keep Bloodhound off the attic?
>

I'm just relating my experience with "how things work", given my extensive
time with the ASF. I've been to over 200 Board meetings, and unfortunately
missed the meeting a few days ago where Bloodhound was discussed (I'm
traveling right now; which speaks to Shane's point about "give people time;
24h is not enough")

Moving is not a given, as Shane noted later in this thread. The Board
simply needs to see a community, and if that is present, then it will defer
to those people (it is squishy; there are no "commit metrics"; it's about
people). For all intents and purposes, there isn't an Apache Bloodhound
community right now.

... but given the responses, is there enough? Of course. It only takes a
few.

So far, Daniel, yourself (Nikolay), and Sz have spoken up to throw in some
time to see if we have enough energy to (re)launch Apache Bloodhound.

Let me collect a few queries into this single email...

* the (archival) repository is in svn, and mirrored to github.
  - if we want to evolve this, then I'd suggest making svn read-only and
carrying forward with a git-based codebase
* the "experimental" repository is at:
https://github.com/apache/bloodhound-core and
https://gitbox.apache.org/repos/asf/bloodhound-core.git
  - the above is Gary's initial work towards a v2 vision/prototype
  - there is no community consensus on future direction, so far; individual
exploration and input is needed
* "jettison burden" means it won't be Apache Bloodhound
  - personally, I welcome the legal umbrella/shield of the ASF, so I'm
happy that I signed an ICLA (which is not a burden, IMO)

I think the biggest issue is in the middle there: where is Bloodhound
headed? Evolve the existing branch? Strike out on something new, like Gary
was exploring (a Django-based solution), or something else? Personally, I'd
like to see a Quart-based app server using a sqlite database. Keep it super
simple and easy to set up.

Regarding the repository: file some PRs. Or maybe we can use the GitHub
wiki to figure out a roadmap. "commit" is several steps down the road, and
sure: we can easily make that happen. But even if everybody had commit
tomorrow, we don't have a consensus vision yet.

Cheers,
-g

ps. note that I also hold a role in Infra; I can directly/immediately make
changes to support the community.

Re: Apache Bloodhound will be moving to the Attic

[Greg Stein]

There has been near-zero commit activity for many years. The mailing list
is empty. There are a few people "around", but inactive.

Note that a move to the Attic will not cause any problems with the 0.8
release. That will always be available for download. The Attic is simply a
marker that future development will not occur.

Cheers,
-g
Member of the Bloodhound PMC


On Thu, Aug 17, 2023 at 4:57 PM Nikolay Tsanov  wrote:

> Hi Shane,
>
> Could you please elaborate on the material metrics for "real engagement and
> energy" that would rescue Bloodhound from the attic? I have been using
> version 0.8 for my personal needs since 2015 and the lack of active
> contributions on my end is, among other reasons, due to the fact that it
> still 'works for me".
>
> Thanks,
> Nikolay
> +1-819-635-7198
>
> Le jeu. 17 août 2023, 08 h 09, Shane Curcuru  a
> écrit :
>
> > While we very much appreciate the several attempts to bring new life
> > back to Bloodhound, it feels like it's time to celebrate the project and
> > send it off to the Apache Attic.  This is only fair to potential users,
> > to let them know we don't have a fully active community here.
> >
> > UNLESS the Board sees real engagement and energy from at least three
> > developers here on Bloodhound in the next couple of weeks, the Board
> > will be voting at our September meeting to place Bloodhound into the
> > Apache Attic.  All resources will be preserved as-is, but read only.
> >
> >https://attic.apache.org/
> >
> > I know Gary and others have really tried, but for an active Apache
> > project we need three regular PMC members to provide oversight.
> >
> > Thanks for all the work over the years,
> >
> > --
> > - Shane
> >Director
> >The Apache Software Foundation
> >
> >
>

Re: ASF Board Report for Bloodhound - Repeated Reminder for August 2021

[Greg Stein]

We're still here. The community hasn't disappeared. It is simply low-energy.


On Thu, Aug 19, 2021 at 8:54 PM Gary Martin  wrote:

> Hi Sander and everyone else,
>
> Sorry for the unfortunate silence from me for a bit. I'll avoid providing
> too much in the way of excuses as I hope that people will just be more
> interested in seeing genuine activity as soon as possible instead.
>
> Also, sorry this is only a short message for now.
>
> Cheers,
> Gary
>
> On Tue, 10 Aug 2021, at 10:17 PM, Sander Striker wrote:
> > Dear Bloodhound community,
> >
> > In the Apache governance model, the ASF board delegates responsibility
> for
> > managing projects to PMCs. This allows projects to govern themselves, in
> terms
> > of their own development goals, guidelines, and volunteer spirit, within
> the
> > scope of our purpose as an open source foundation. The state allows us to
> > supply an umbrella of corporate protection to our projects and
> volunteers, but
> > only to the extent that we retain active and effective oversight of each
> > project's operation on behalf of the public's interest.
> >
> > To enable the board to provide oversight across the foundation, each PMC
> is
> > tasked with providing the board a quarterly report on the health of their
> > project. This allows us to hear your heartbeat, to see the project
> through
> > your eyes, and to inform the public through our meeting minutes.
> >
> > The board has noticed that the reports for Bloodhound have been missed
> > for a number of months. This makes us sad because we have lost that
> ability
> > to communicate with you, to see what may be preventing your good health,
> > and to ensure that we are providing the services that you need to
> continue
> > as an Apache project.
> >
> > The reports to the board are normally written by the PMC chair but all
> PMC
> > members have an individual responsibility to ensure that a report is
> > submitted. If the PMC chair is not available then any PMC member can
> submit
> > the report. If you need help with this process, please reach out to
> > bo...@apache.org
> >
> > Please ensure that a report for Bloodhound is submitted to the board
> > for the next meeting.
> >
> > If the PMC chair is not going to be available for an extended period of
> time,
> > it may make sense to rotate the PMC chair. Rotating the PMC chair does
> not
> > mean the current chair has failed. People's situations and interests
> change;
> > rotation is good as it allows more people to become familiar with that
> role.
> > Again, if assistance is required with this process, please feel free to
> > reach out to bo...@apache.org
> >
> > As projects mature, they will naturally reach a point where activity
> reduces
> > to a level that the project is no longer sustainable. At Apache, projects
> > reach this stage when there are no longer 3 active PMC members providing
> > oversight. Projects that reach this stage are placed in our Attic, where
> > they continue to be accessible to the public but are not portrayed as
> having
> > an active community for maintenance.
> >
> > http://attic.apache.org/
> >
> > If Bloodhound has reached this point, please reach out to the Attic
> project
> > to arrange transfer. On the other hand, if your project is mostly
> dormant but
> > still has at least three active PMC members, it can remain in that state
> for
> > as long as needed. If your project is in such a state, please mention
> that in
> > your report and verify the PMC's state at regular intervals.
> >
> > Finally, if you have any questions, please feel free to reach out to
> > bo...@apache.org.
> >
> > Thanks,
> > The ASF Board
> >
>

Re: git repo for new bloodhound core work

[Greg Stein]

On Thu, May 6, 2021 at 5:26 PM Gary Martin  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  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

Re: git repo for new bloodhound core work

[Greg Stein]

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  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
>

Re: Is it time for Bloodhound to move to the Apache Attic?

[Greg Stein]

I don't have any coding time, but I do have review/oversight time. That
makes (4) for oversight.


On Sun, Sep 13, 2020 at 8:54 AM John Chambers  wrote:

> Hi everyone, I am also still committed to supporting this project going
> forward.
> I will do my best to take part in any discussions about its future
> development.
>
> Cheers
>
> John.
>
> On Sun, 13 Sep 2020, 14:23 Gary,  wrote:
>
> > Hi everyone and thanks to Shane for bringing this up.
> >
> > For my part I still have an interest in continuing and I really want to
> > get things organised again.
> >
> > However, this discussion certainly needs to happen. Is there really
> enough
> > interest amongst us to keep this going and can we translate the interest
> > into actual action?
> >
> > Coincidentally, I was planning to take a week off work from the 21st
> > September which I was hoping to be able to use to help make some progress
> > on Bloodhound. Life being what it is, I am not going to be sure how much
> of
> > that time I will be able dedicate to Bloodhound but I have nothing else
> > organised for that time (apart from the Sunday before that). Obviously I
> > can't expect others to just drop everything and join me in taking a week
> > off on this basis, so I am more hoping that there would be interest from
> > people in setting some time aside to chat with me and hopefully others on
> > #bloodhound in the-asf Slack and see what progress we can make.
> >
> > Cheers,
> > Gary
> >
> > On Sat, 12 Sep 2020, at 3:45 PM, Shane Curcuru wrote:
> > > While we very much appreciate Gary's repeated efforts to bring back new
> > > life to Apache Bloodhound, reviewing the past year of dev/user/private
> > > traffic and #bloodhound on the-asf's Slack, I don't see other energy.
> > >
> > > The board meeting is this coming Wednesday, and we'd really like to
> hear
> > > some feedback from the community one way or the other, since there
> > > hasn't been a board report since May.
> > >
> > > - If Gary and anyone who's been involved recently know it's time for
> the
> > > Attic, please let us know - we could post and pass the resolution at
> > > either this month's Board meeting or next month's.
> > >
> > > - If you do feel like you have more energy to drive Apache Bloodhound,
> > > then we need the PMC to perform a roll call, to show that at least
> three
> > > people are still active and able to oversee the project:
> > >
> > >   https://apache.org/dev/pmc.html#roll-call
> > >
> > > Reminder: moving to the Apache Attic isn't a bad thing - it's just a
> > > recognition that there's no longer an *active* PMC able to manage the
> > > project here at the ASF.  All project code, website, mailing lists
> would
> > > get turned read-only, but will *still be available* at the same URLs.
> > >
> > > Thanks for all the work in the past, and the cute logo!
> > >
> > > --
> > >
> > > - Shane
> > >   Director & Member
> > >   The Apache Software Foundation
> > >
> >
>

Re: Is it time for Bloodhound to move to the Apache Attic?

[Greg Stein]

Nobody is stopping you. There are a bunch of forks already:
https://github.com/apache/bloodhound/network/members

On Sat, Sep 12, 2020 at 4:30 PM jason  wrote:

>
> Post it on Github and let us fork it.Sent from my Samsung Galaxy
> smartphone.
>  Original message From: Shane Curcuru <
> a...@shanecurcuru.org> Date: 12/09/2020  15:45  (GMT+00:00) To:
> dev@bloodhound.apache.org Subject: Is it time for Bloodhound to move to
> the Apache Attic? While we very much appreciate Gary's repeated efforts to
> bring back newlife to Apache Bloodhound, reviewing the past year of
> dev/user/privatetraffic and #bloodhound on the-asf's Slack, I don't see
> other energy.The board meeting is this coming Wednesday, and we'd really
> like to hearsome feedback from the community one way or the other, since
> therehasn't been a board report since May.- If Gary and anyone who's been
> involved recently know it's time for theAttic, please let us know - we
> could post and pass the resolution ateither this month's Board meeting or
> next month's.- If you do feel like you have more energy to drive Apache
> Bloodhound,then we need the PMC to perform a roll call, to show that at
> least threepeople are still active and able to oversee the project:
> https://apache.org/dev/pmc.html#roll-callReminder: moving to the Apache
> Attic isn't a bad thing - it's just arecognition that there's no longer an
> *active* PMC able to manage theproject here at the ASF.  All project code,
> website, mailing lists wouldget turned read-only, but will *still be
> available* at the same URLs.Thanks for all the work in the past, and the
> cute logo!-- - Shane  Director & Member  The Apache Software Foundation

Re: looking to get back on track or possible retirement to attic

[Greg Stein]

Hi Gary, Daniel, et al,

On Wed, Apr 15, 2020 at 9:17 PM Gary Martin  wrote:

> Hi Daniel,
>
> On Sun, 2 Feb 2020, at 9:12 AM, Daniel Brownridge wrote:
>
>...

> > > I see that I hid a number of issues by mentioning that there is some
> infrastructure work that is required. Updates to the project page and
> getting the issue tracker back up would be amongst these. Getting a new set
> of tickets to help hand out the work would also clearly be useful.
>

Please note that I'm part of the Infra team, so can ensure the wheels are
greased. My available time for coding/projects is near zero, but am happy
to do chat/discuss and infra.

>...

> > about we request a project to be created in JIRA for Bloodhound which we
> > can use in the meantime. I'm still new in ASF world and getting
> > established but I'd be more than happy to take this aspect on. I note
> > from https://issues.apache.org/jira/secure/Dashboard.jspa that:
> >
> > > If your ASF project wants to use JIRA, either read this wiki page
> > > aboutmigrating from Bugzilla
> > > or
> > > please contact jira at apache.org to setup a new project.
>

Note the instructions have been updated since you viewed/pasted that. Jira
project setup is selfserve nowadays.

> How about we do this? I can already think of one of the first tickets
> > I'd like to register there! Get http://live.bloodhound.apache.org/
> >  up and running again.
>
> Sorry to go against that idea a little. For now I am intending to get the
> current bloodhound instance going again as a stop-gap before we can replace
> it with a new version. This is partly so we will have existing links
> restored and partly as we will probably desire some kind of migration of
> issues to the new project. I hope that makes some kind of sense.
>

How about a time-box on that? We can set up Jira on (say) June 1, if a
Bloodhound instance isn't up and running yet.

> In a similar vein it would make sense to have some CI going on so it
> > would be nice to have Bloodhound up on https://builds.apache.org/ to
> see
> > tests passing etc.
>
> Yes, we certainly used to have CI via buildbot. These days I do a fair
> amount of work with jenkins pipelines so I can see that working reasonably
> well.
>

The buildbot config is located at:
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/bloodhound.conf

(that might not be available to the general public, but committers-only)

> I'm still finding my feet in ASF land - from reading general stuff on
> > Apache.org I think I need to sign ICLA or something before anyone lets
> > me near code?
>
> Well, it is certainly possible to contribute code to Apache projects
> without being a committer to the project. You can look at
> http://apache.org/foundation/how-it-works.html#roles for distinctions
> between contributors and committers. I may well be talking to you about
> this again shortly though.
>

The short answer is: send a few patches; if it all looks good, then the
Bloodhound PMC votes you in as a committer; you sign an ICLA and get an @
apache.org account. Off to the races!


> > > I would also like to organise some hack days so that interested people
> can be online at the same time to try to share advice and see if we can
> make more progress that way.
> > More than happy to get involved in a hack day. Just let me know when
> > works for you. I'm also trying to hang out in irc more! Totally off
> > topic but I'm on a laptop +allegary, JasonO- & macmaN all seem to be
> > there permanently, is this as simple as you're using a desktop you don't
> > turn off or are you doing something clever?
>

Please note that since about 1.5 years ago, the Foundation has an official,
supported Slack workspace at the-asf.slack.com. We have a Standard [NGO]
Plan, so all history is retained/searchable. That is nicer than IRC, if
people leave/return-to the channel. I've taken the liberty to create
#bloodhound there (since I'm on the-asf.s.c 24x7 for Infra work), and
invited Gary onto the channel.

>...

> > On 14/01/2020 10:29, Gary Martin wrote:
>
>...

> > > The current code is available from a number of places. I updated the
> README.md last night to see if I could improve the instructions around
> getting the code, although clearly that would only be seen when you have
> already seen the code. The svn repo is available at
> https://svn.apache.org/repos/asf/bloodhound/ but you can get a more
> targetted checkout with:
> > >
> > >svn checkout
> https://svn.apache.org/repos/asf/bloodhound/branches/bh_core_experimental/
> > >
> > > alternatively, as you spotted, it is mirrored at github and so you can
> clone and checkout direct to the appropriate branch with:
> > >
> > >git clone --branch bh_core_experimental
> https://github.com/apache/bloodhound.git


Please note the above is a readonly mirror. Any PRs created against it will
imply the need to 

Re: [Proposal] Core Bloodhound - basic concepts

[Greg Stein]

On Mon, Mar 19, 2018 at 8:43 AM, Gary Martin 
wrote:

> Hi everyone,
>
> I am going to start building out a basic core implementation to play
> around with some of the ideas we have discussed. I'll try not to take
> things too far before getting this into source control.


I would recommend using an svn branch, and committing "hourly". Why not?
You won't be affecting trunk, and you'll get early feedback.

>...

> On that last item, I believe I have the ability to create a git repo for
> the project at the asf. I would expect the project to also be available via
> github.
>

Infra would like to see some community consensus, if you plan to switch
from svn to git. (ie. discuss it first)

>...

Cheers,
-g

Re: [Proposal] Core Bloodhound - basic concepts

[Greg Stein]

On Sun, Mar 11, 2018 at 4:21 PM, Gary  wrote:
>...

> How tickets are stored as a whole is also worth tackling, which is what #2
> is trying to broadly decide. Here I am suggesting that the state of a
> ticket can be built up from a query that collects all the change events and
> applies the deltas in order. This could prove to be a slow process so at
> some point we may want to look at keeping a record of the current state or
> a checkpoint but, given that ticket views are expected to show the history,
> these are details that are required anyway. I suggest that we can look at
> optimising for speed later. Knowing that we can update a ticket from deltas
> may be useful.
>

The Apache Subversion team has a LOT of experience in this kind of storage
:-)

When we started, we stored the "latest" in full text, and then had a series
of "reverse deltas" to go backwards in time. We switched that around, and
store the original in full text, and then apply "forward" deltas to reach
"latest".

We have two mechanisms to speed this up: a sophisticated cache system.
Invariably, "latest" will be cached and fast to retrieve. The more
important part of our "series of delta" system, allowing us to rapidly
construct any point in history is to use "skip deltas". This is analogous
to the "skip list"[1] concept, where we assemble N deltas into a single
delta allowing us to skip over many deltas with a single application.
Generally speaking, if there are M deltas in a file's entire history, then
we can reassemble any point in history by applying log(M) deltas.

(note we used the skip delta mechanism for both directions; it is effective
in both directions)

Finally, I am suggesting in #3 that as much as possible we generalise
> ticket categorisation. Categorisation is a central concept to capture and,
> in trac we inherited categorisations such as statuses (open, in progress,
> etc), types (bug, enhancement, task, etc), milestones, versions, etc, and
> these had separate implementations.


When my team designed the issue tracker for Google Code's project hosting,
we did the same thing. Most issue trackers are highly-structured with a
field or this and that. It complicates issue creation, issue management,
querying, etc. I recall sitting down with 20 fields from a typical Bugzilla
install, and reducing it to about 8, where we used labels for "everything".
We did not bother with "issue types".

A second thing that we did is allow labels such as "milestone-14", and then
enable our "list display" to be configured for a "milestone" column that
would extract any labels that started with "milestone-", showing just the
"14".

It made for a very robust, easy to understand, and flexible metadata system
for each issue.

You can still see some of these design choices a decade later in Monorail,
a descendent of our tracker, now being used by the Chromium project.

>...

Cheers,
-g

[1] https://en.wikipedia.org/wiki/Skip_list

Re: Public Bloodhound is down again

[Greg Stein]

Hi Dammina, John,

What is the status of the new VM? (per
https://issues.apache.org/jira/browse/INFRA-13255)

Dammina: I see that you're not "watching" that ticket. Please do so. These
Bloodhound VMs have been off/on/ignored for far too long, and I was hoping
that you and John would get bloodhound-vm3 up and running. I had asked for
*two* volunteers.

Can Infrastructure delete bloodhound-vm and bloodhound-vm2? I presume there
is no data to copy from those?

Thanks,
Greg Stein
Infrastructure Administrator, ASF
(and Bloodhound PMC Member)


On Sun, Nov 5, 2017 at 7:07 PM, Greg Stein <gst...@gmail.com> wrote:

> On Sun, Nov 5, 2017 at 4:05 AM, John Chambers <cham...@apache.org> wrote:
>
>> Hi Greg/Dammina,
>>
>> I have been looking at how to get a working version of the Bloodhound
>> instance locally from a backup file I made on August 1st 2017. I have
>> asked
>>
>
> That should be the latest, as the site wasn't running after that date, so
> no further changes could have been made.
>
> Infra should have backups (and I believe the VM is still around, but
> turned off).
>
>
>> Gary for some help with instructions on the correct way to do this.
>> However
>> if anyone else has the details then please let me know. I am unsure at the
>> moment if the backup I have has everything in it needed to restore the
>> issues and wiki to the state it was previously. Also I am not aware of any
>> other backups of the system.
>>
>> My plan is to create a working 0.4 version of Bloodhound from this backup
>> and then upgrade it to 0.8. Then take another backup which can then be
>> used
>> to create our new instance of the official site on a new VM. Once I can
>> get
>> to this point I will publish the instructions here along with the backup
>> file for others to try. Then once the process has been verified I will put
>> my name forward as the second person to manage the new official VM and
>> work
>> with Dammina to get it operational and maintained going forward.
>>
>
> Great! With you and Dammina, we can reopen INFRA-13255 and y'all can help
> set up and manage a new VM. That can either be the issues.apache.org live
> VM, or a demo, as you wish.
>
> Cheers,
> -g
>
>

Re: Public Bloodhound is down again

[Greg Stein]

Infra can provide a bare Ubuntu 16.04 VM via puppet, and then you can
finish the install from there. No skin off Infra's back. We encourage
project VMs to use puppet to easily restore their VM should something go
sideways. But if you can easily rebuild another way... hey, fine.

Cheers,
-g


On Wed, Dec 13, 2017 at 4:36 PM, John Chambers  wrote:

> As prompted (Thanks Gary  ) a quick update on my progress with getting
> the public instance back online.
>
> I have just committed my code changes to the Vagrant and salt files to
> enable us to provision an instance of 0.8 and I have created a backup of
> the live tickets and wiki for 0.8.
> I am not sure if I should post that backup anyway. Any ideas let me know. I
> can also provide the steps to restore from the backup if anyone is
> interested in trying these changes out locally for themselves. Just let me
> know.
>
> The next step I think is to contact INFRA to see what is actually required
> to provision the new VM. We have salt code currently but I am thinking that
> INFRA may require puppet.
>
> The other outstanding question is what to do about the users and
> permissions. I have the original htdigest file and the permissions set in
> the database, but I am wondering if we should just reset the users and
> permissions and start again. Maybe we can discuss this once the live
> instance has been sorted.
>
> Cheers,
>   John.
>
> On 14 November 2017 at 19:05, Gary  wrote:
>
> > That is an interesting question.
> >
> > One thing we should really be considering is whether we can be using a
> > common set of users to the apache instance of jira through ldap or
> > however it works. It may introduce a small barrier to access to ask
> > people to register through jira but it might be nice to be able to avail
> > ourselves of responsibility of working out who the real users are.
> >
> > I expect we should be able to work with our own permissions against an
> > external ldap, for instance. I have not yet tried such a setup of
> > course. This may be something that is delayed for further down the line
> > if it would delay recovery too much. It may be that we can use multiple
> > sources for users too. Possibly worth checking.
> >
> > Anyway, the immediate need should be considered to be getting anyone who
> > needs access signed up so the questions around this need to be
> > considered by others here are:
> >
> >  * would those who already have accounts mind if they needed to sign up
> >  again?
> >  * can we have access to register accounts opened for now or do we want
> >  spam control in place from the start?
> >  * would a longer term plan to have accounts 'shared' with another
> >  apache issue tracker instance bother you?
> >
> > Cheers,
> >   Gary
> >
> > On Mon, 13 Nov 2017, at 12:56 PM, John Chambers wrote:
> > > Thanks Gary. I will take a look at the backup you provided later today.
> > > Hopefully as you say it will make the restore process much easier.
> > >
> > > I think once I have the restore process to a copy of the latest
> > > Bloodhound
> > > release sorted, we can start a discussion with INFRA on the best way
> > > forward.
> > >
> > > One question I did have though is this. Should I be looking to restore
> > > the
> > > current user base?
> > >
> > > We may also need to discuss solving the issues of spam users and posts
> > > etc
> > > which caused some issues previously.
> > >
> > > Will keep you all updated with progress.
> > >
> > > Cheers.
> > >
> > > John.
> > >
> > > On 13 Nov 2017 11:21, "Gary"  wrote:
> > >
> > > > Hi John,
> > > >
> > > > Just a quick note about the upgrade. I suspect that the backup you
> are
> > > > testing on has not got the proper environment. It seems a little
> > > > surprising that the attachments are in the wrong place for a 0.4
> > > > installation. I've found the backup that I made for the upgrade work
> > and
> > > > passed it on to you. Assuming that is the right stuff, that might
> make
> > > > life easier!
> > > >
> > > > Perhaps we can look at puppet again shortly. It may be that the
> > problems
> > > > that I had were smaller than they looked. I would expect it to be
> fine
> > > > to install without but have a commitment to get the setup properly
> > > > puppetised later. Though obviously that is something to clear with
> > INFRA
> > > > again.
> > > >
> > > > Cheers,
> > > >   Gary
> > > >
> > > >
> > > > On Sun, 12 Nov 2017, at 10:20 AM, John Chambers wrote:
> > > > > Hi all,
> > > > >
> > > > > I just wanted to give a quick status update on my progress with
> > getting
> > > > > the
> > > > > live issue tracker and wiki back online.
> > > > >
> > > > > I have managed to use the existing vagrant/salt files to provision
> a
> > vm
> > > > > with the 0.4 version installed.
> > > > > I have also got a fix for the issue where apache was unable to
> serve
> > > > > bloodhound. I have managed to use the existing backup of the live

Re: Public Bloodhound is down again

[Greg Stein]

On Sun, Nov 5, 2017 at 4:05 AM, John Chambers  wrote:

> Hi Greg/Dammina,
>
> I have been looking at how to get a working version of the Bloodhound
> instance locally from a backup file I made on August 1st 2017. I have asked
>

That should be the latest, as the site wasn't running after that date, so
no further changes could have been made.

Infra should have backups (and I believe the VM is still around, but turned
off).


> Gary for some help with instructions on the correct way to do this. However
> if anyone else has the details then please let me know. I am unsure at the
> moment if the backup I have has everything in it needed to restore the
> issues and wiki to the state it was previously. Also I am not aware of any
> other backups of the system.
>
> My plan is to create a working 0.4 version of Bloodhound from this backup
> and then upgrade it to 0.8. Then take another backup which can then be used
> to create our new instance of the official site on a new VM. Once I can get
> to this point I will publish the instructions here along with the backup
> file for others to try. Then once the process has been verified I will put
> my name forward as the second person to manage the new official VM and work
> with Dammina to get it operational and maintained going forward.
>

Great! With you and Dammina, we can reopen INFRA-13255 and y'all can help
set up and manage a new VM. That can either be the issues.apache.org live
VM, or a demo, as you wish.

Cheers,
-g

Re: [Proposal] How to get out of this situation?

[Greg Stein]

On Mon, Oct 23, 2017 at 3:44 PM, Olemis Lang  wrote:

> On 10/23/17, Allan Swanepoel  wrote:
>
>...

> > And, again, nothing against ASF here, but I'm sure migrating the
> > source to GH could attract more involvement from more developers.
> >
> [...]
>
> As far as I know all ASF projects , even those in the Apache Incubator
> , are mirrored in github . This is Apache Bloodhound instance @ Github
> [1]_
>
> .. [1] https://github.com/apache/bloodhound


Correct, re: mirroring. All git projects are auto-mirrored. We've enabled
mirrored for pretty much all svn-based projects.

Infra also has a beta program for communities who want to move their
read/write repository *onto* GitHub (and the ASF will mirror it back to
us). That allows a community to use GitHub's features, such as PRs, issues,
wiki, etc.

Not sure if that's something to do while trying to reboot, but always an
option.

Cheers,
-g

Re: Public Bloodhound is down again

[Greg Stein]

Hey Dammina,

Short answer: Infra turned off the service because it wasn't being
maintained. More below:

On Mon, Oct 23, 2017 at 1:59 AM, Dammina Sahabandu <dmsahaba...@gmail.com>
wrote:
>...

> Hi All,
>
> The public hosted instance of bloodhound is down again for some time now.
> We need to come up with a sustainable methodology to keep this up and
> running. At least we should activate a different health check monitoring
> service.
>

Infra has ample monitoring. No worries there. But a couple things got
broken on it, and never fixed. There were also a couple VMs running for
Bloodhound demos, but those weren't worked on either. ... So Infra just
shut it all down.


> As I remember last time we have reported this to infra team and get
> resolved. Is this the method that we have following all along? Or else do
> we have any control to the VM that this instance is running.
>
> I would like to take the responsibility of keeping the instance up and
> running in the future, but first I need some guidance from our senior
> members.
>

Speaking for Infra now: we would like an additional person to make a
similar commitment, before we spin up a VM for Apache Bloodhound. We've
been going back/forth on these VMs for a while now, and have yet to succeed.

I'm reachable here (as a PMC Member) or on users@infra or via a Jira
ticket. Happy to help, but Infra needs some assurances of assistance for
your VM(s).

Cheers,
Greg Stein
Infrastructure Administrator, ASF
(and a Bloodhound PMC member)

Robot users

[Greg Stein]

Is there a captcha that can be installed on new user creation?

Over the past couple weeks, it has become horrendous. The commits@ list is
getting buried in user creation notices.

Cheers,
-g