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