Re: git repo for new bloodhound core work
Following the rest of this thread (archive at https://lists.apache.org/thread/kohw9nr4x94wdh7w46y82x6ghy75znjh), there were three PMC members supporting the move to git (Gary, Greg, John) with implied consent from a fourth (Dammina). Thus, I've gone ahead and made svn readonly [1]. Cheers, -g [1] private, readable by ASF committers: https://github.com/apache/infrastructure-p6/commit/4174bc7d51b161f0862d9126d6a4f0fedb73090c On Tue, Sep 22, 2020 at 7:57 AM Gary Martin wrote: > Hi, > > Judging by previous conversations long past (e.g. [1], [2]) I believe I > effectively have a mandate to switch to using git for at least some of our > work and so I think we may as well try this out with the experimental > 'core' bloodhound stuff and see how we got from there. > > I am not expecting to migrate any old bloodhound work to any new git repo > - any legacy work can stay in the subversion repo for any ongoing > maintenance. Also, I am not intending to drop any of our other current > usages of subversion, be they public or private so, for instance, the > "site" pages can remain there for now as I don't see as big advantages in > moving these things for the moment. > > From my point of view, I have been working with git more than subversion > long enough that I am finding it a lot more difficult to work with. Trying > to use git-svn doesn't feel a good enough solution for this, particularly > at clone time. Maybe there are other solutions but I am not sure it is > worth putting in more effort to work them out. > > So, unless there are any big objections, I will be looking to get this > done today. As there is already a bloodhound mirror of sorts on github with > the bloodhound name, I will be calling the new repo > > "bloodhound-bhcore" > > This name obviously gives an impression that there will be multiple repos > associated with the new bloodhound. If anyone cares to change my mind on > this naming, I think the `bloodhound-` prefix is sensible and certainly > consistent with all other apache projects I have spotted so it will just be > a question of whether there is a better "subname." > > Cheers, > Gary > > [1] > https://lists.apache.org/thread.html/e2ce321621205b7131047e21c776ffcacd8516ecbac70ea2f665d761%40%3Cdev.bloodhound.apache.org%3E > [2] > https://lists.apache.org/thread.html/c3956214bd35ff57526d7e63fac86e2613499f6fc473275345ee6b61%40%3Cdev.bloodhound.apache.org%3E >
Re: Apache Bloodhound will be moving to the Attic
On Sun, Aug 20, 2023 at 7:59 AM Nikolay Tsanov wrote: >... > 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 > No. Governance is defined by Apache rules of peer conduct. The version control system is orthogonal to how a community reaches consensus and develops code. If English language is the issue and you meant "DESIGN at the technology layer of the Bloodhound architecture", then you're wrong. A version control system has zero impact on architecture. The VCS merely helps to organize workflow/process. git sucks at this, GitHub is awesome at this, and svn falls in between. >... > 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 > Never attempt extortion of the community to get what you want. You can leave. Your contributions are not worth more than anybody else's, and are certainly not required. The version control choice will not be made by you. -g
Re: Apache Bloodhound will be moving to the Attic
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
Re: Apache Bloodhound will be moving to the Attic
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 , 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
Re: Apache Bloodhound will be moving to the Attic
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 , 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
Re: Apache Bloodhound will be moving to the Attic
@Greg Stein , 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 wrote: > On Fri, Aug 18, 2023 at 6:08 AM Nikolay Tsanov 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. > >
