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