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 <[email protected]> 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, <[email protected]> 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 not got particularly far in its objectives >> at this point. There are obviously pros and cons to such an approach. >> >> In particular I would note that a clean(ish) break from Trac brings with >> it opportunities to control all of what it is to be the issue tracker while >> building on sane webserver frameworks. It does, however, lead to the >> question of what such a break would ultimately look like. Is feature parity >> something that would be desired? Would we at least be happy to avoid >> support for trac plugins? >> >> Obviously continuing the development of Apache Bloodhound 0.8 certainly >> is not out of the question but this could also be a difficult path. There >> could be some interesting decisions to make too. The code obviously needs >> to move to Python 3 and almost certainly a shift to be built on a newer >> version of Trac. >> >> Anyway, I'll leave it there for the moment. In the meantime I'll try to >> eke out some more time to do stuff this week, hopefully including putting >> more of my thoughts together somewhere useful. >> >> Cheers, >> Gary >> >> On Sun, 20 Aug 2023, at 7:33 PM, Nikolay Tsanov wrote: >> > I fully agree with Daniel and the top ten priorities he suggested. I >> > haven't looked at Gary's code either (assuming this is the repo at >> > https://github.com/apache/bloodhound-core), this is the first thing I >> will >> > do, and I will share my feedback as soon as I can. >> > >> > Nikolay Tsanov >> > +1-819-635-7198 >> > >> > On Sun, Aug 20, 2023 at 1:38 PM Daniel Brownridge < >> > [email protected]> wrote: >> > >> >> I just wanted to say thank you to Greg and Shane for providing all the >> >> detailed 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) use GitHub issues. >> >> >> >> 2. Switch from Subversion to Git as primary source control. >> >> >> >> 3. Resurrect live.bloodhound.apache.bloodhound.org if possible with >> the >> >> current version of Bloodhound. >> >> >> >> 4. Make a plan to get back off GitHub issues again. >> >> >> >> 5. Get consensus on the future development roadmap. (Possible features >> >> suggestion - 'Make it easy to import issues from Github Issues!') >> >> >> >> What do you think? >> >> >> >> *Daniel Brownridge* >> >> [email protected] >> >> +44 779 138 5626 >> >> On 20/08/2023 13:59, Nikolay Tsanov wrote: >> >> >> >> @Greg Stein <[email protected]> <[email protected]> , thank you for the >> timely and commendably >> >> thorough response. As far as the development part of the community is >> >> concerned, to top priority concern that should be dealt with is, as you >> >> defined it: >> >> "- if we want to evolve this, then I'd suggest making svn read-only and >> >> carrying forward with a git-based codebase" >> >> >> >> 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 and, simply put, a non-Git version control system is a >> >> roadblock (I am in the same boat as Daniel Brownridge who wrote on Aug >> 18, >> >> 2023, 7:56 AM (2 days ago) “I’ve struggled a bit to get started. I >> found >> >> the Apache initiation rituals a bit challenging."). >> >> >> >> 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, e.g. we start using GitHub for code >> review >> >> and issues tracking. I know that it might sound demoralizing that an >> issues >> >> tracking system as Bloodhound is not eating its own dogfood and it is >> using >> >> a third party as GitHub for tracking its own issues, however this is >> what >> >> we need in order to get traction. >> >> >> >> Thanks, >> >> Nikolay Tsanov >> >> +1-819-635-7198 >> >> >> >> On Sat, Aug 19, 2023 at 10:58 PM Greg Stein <[email protected]> < >> [email protected]> wrote: >> >> >> >> >> >> On Fri, Aug 18, 2023 at 6:08 AM Nikolay Tsanov <[email protected]> < >> [email protected]> 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 andhttps:// >> 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. >> >> >> >> >> >> >> >> >> >
