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]> , 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]> wrote:
On Fri, Aug 18, 2023 at 6:08 AM Nikolay Tsanov<[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 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.
