Applied, and live. Thanks!!
On Fri, Aug 25, 2023 at 3:02 PM Daniel Brownridge <dan...@freshnewpage.com> 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 <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 >> >> On Mon, 21 Aug 2023, 03:47 Gary Martin, <gary.mar...@physics.org> 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 < >>> > daniel.brownri...@gmail.com> 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* >>> >> dan...@freshnewpage.com >>> >> +44 779 138 5626 >>> >> On 20/08/2023 13:59, Nikolay Tsanov wrote: >>> >> >>> >> @Greg Stein <gst...@gmail.com> <gst...@gmail.com> , 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 <gst...@gmail.com> < >>> gst...@gmail.com> wrote: >>> >> >>> >> >>> >> On Fri, Aug 18, 2023 at 6:08 AM Nikolay Tsanov <tza...@gmail.com> < >>> tza...@gmail.com> 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. >>> >> >>> >> >>> >> >>> >> >>> >>
