bats
bats copied to clipboard
sstephenson
Call for Maintainers
Hi everyone,
My plate’s been full with other work for the past year or so, and I haven’t given Bats the attention it deserves. I’m sorry about that.
I’m looking for one or two people who’d like to step up and take over maintenance of the project.
Your first task would be to work through the major outstanding issues and ship a solid, stable Bats 1.0. I’m happy to work closely with you on prioritizing the work and answering any questions you have about the code base.
Beyond that, I’d leave the future direction of the project up to you.
Please use this thread to nominate yourself and tell me why you’d like the job. Let’s get a conversation going.
Thanks!
/cc @ztombol @jasonkarns for :eyes: since I know they are big users of Bats.
So what's the plan, move to a dedicated github space and make it more of a community effort? Having bats and the assert library merged together or as a parallel bats/bats bats/batslib and optional community modules?
To reiterate, the short-term plan is to ship Bats 1.0, and the long-term plan is to hand over future decisions about the direction of the project to the new maintainer(s).
I'm able and willing to help maintain bats. However, I am not able to be the lead maintainer.
I use eco but not bats so I am not useful here, but would using something like https://jazzband.co/ help?
I would love to help out. My other responsibilities (job huntung etc.) will definitely not let me take part as much as @jasonkarns (judging from his excelent activity over at bats-core, bats-assert and bats-docs), but I will still help as much as I can.
I'm not very well known to you, but have used bats in a semi-large project at work, which I hope we'll be able to open source some time in the not too far future (read as "hopefully later this year, or maybe sometime during 2017").
As such, I'd like to see bats prosper, and would love to be a part of making that happen.
Edit: Oh, and as reference on previous bash work, the only thing I have to show for is my experiments with ticktick which I made a rather big rewrite of to resolve some hard to fix outstanding issues.
Hi, we're making extensive use of BATS at Red Hat, both for internal testing and for use on customer projects involving Red Hat Satellite and CI. I would be very happy to take over maintenance of the project. I'm also pushing for it to be officially shipped in RHEL which would get more QE resources etc behind it.
That's a great news, will you ship only core bats or also the matcher libs in separate packages?
Nice! Looks like we're gathering the manpower Bats needs!
I've been going through the issue tracker and been writing up a list of issues, features and annoyances that come up over and over again and we could look into addressing as we move towards 1.0. I'll post it here as soon as it's ready. Probably on the weekend, or early next week.
@schrepfler Do you mean the bats-* libraries? I wouldn't bet on it. I still think they're better off as a separate install. But we can certainly discuss it again.
Of course they can be separate, I meant more of a question for @nstrug, are they going to ship bats-* libs as installable packages/rpm's?
Just posting to ask if there are any updates, since I don't think we have a mailing list for BATS. Like others, I'll chip in where I can (about to have a look at #161 ). But it will be great if the project is maintained by a larger group using BATS like Red Hat / Docker / Chef?
I'd really be glab to help here, be it as a reviewer, maintainer or whatever.
I'd be glad to help out as well.
In reference to pulling all the bats-* under one location, I checked and https://github.com/bats is already taken although not heavily used it seems. I'm not sure if they'd be willing to vacate. I have not asked.
What's the status of additional maintainers? Are there any?
Given the call for maintainers was made 10 months ago and we have add at least one volunteer: @jubianchi, @sstephenson could you grant him maintainer status? Assuming that happens, @jubianchi would you be willing to set up a Google group or something similar for a mailing list? Maybe we can have a discussion there to create an initial list of PRs to merge. I suggest we would bump the current master to an 0.5.0 release (since there has been some commits since 0.4.0) and then identify about 4 or 5 PRs to merge for an intended 0.6.0 to get the ball rolling. All that can get discussed on a mailing list, if we can get at least one person granted the needed privs to get the ball rolling.
I'd like to throw my hat in the ring here as well. I use bats on a regular basis and find it to be an incredibly useful and valuable tool. It's vastly increased the quality of my bash projects, but perhaps more importantly I've found it to be incredibly useful as a more-or-less general purpose integration testing tool.
I'm happy to commit time to this, both personal and professional.
I second @mstade . If we can get anyone write access we can probably get this ship moving again. @sstephenson is it possible?
I'm mostly just a passerby (just started using bats a couple days ago), but it sounds to me like @mstade and @jubianchi should just move forward. If you don't have permissions on this repo, fork and make another. You'd want to do that eventually anyway, right, to move it out of this personal space? Maybe the only tricky part is whether or not you need to change the name while this one is still lingering around, so any external references are clear which one they are referring to. But you can definitely create a mailing list, create a new repo, merge in changes, etc.
@sstephenson has made it clear they would like others to take over so I can't see how any of this would be stepping on any toes.
my interest is as someone interested in introducing bats to our internal tests, but need to know its in a somewhat stable position (given that I personally suck at bash and couldn't possibly fix any bats bugs) before we use it widely. most likely I will switch to using junit to call bash from java, and write my asserts in java.
@squito a few points to touch on there, and I'll try to get at them individually.
First off: yes – you should use bats. It's an excellent tool and will make your bash testing life much easier. I've been using it for well over a year at this point, it does what it says on the tin and it does it well. There are quirks that may give you pause, for sure, but I've yet to come across a show-stopper bug or an issue that wasn't just a misunderstanding on my part. Milage may vary and all that, but I'd definitely recommend using it.
With regards to forking. Sure, it's one way forward. The problem with forking is that we can't make it abundantly clear to people coming to this repo, or @jasonkarns' fork, that for a maintained version of bats they should look elsewhere. We could make an issue with a title in all-caps saying DEPRECATED: LOOK HERE FOR MAINTAINED ALTERNATIVE but it wouldn't really help people installing bats via homebrew, npm, or other package alternatives.
Aside from the npm package, I don't know what kind of traffic this repo gets. Maybe it's not that big of a deal to fork, but I'm hoping we can come to a resolution here without the need to fork.
@mstade thanks for such a quick response!
yeah, I totally understand about the issues w/ confusion over which version to install. That is why I suggested a name change. I personally found bats via answers on stack overflow (pretty sure I found it via this answer: http://stackoverflow.com/a/13199129/1442961). its pretty easy to add comments on existing answers or new answers (or edit answers if members have those privileges). Anyway, i agree that this option has some serious drawbacks as well, so I wouldn't be suggesting it right after the initial call for maintainers, but this has been stagnant for a while.
I'll take your word that bats is reasonably stable; but honestly I'm still hesistant without a mailing-list, because there just isn't a good place for me to learn how to use it. I'm seriously quite incompetent at bash -- I can muddle through, but often feel like I'm probably "doing it wrong". I need a place to ask basic questions. It looks like right now that is opening a github issue, and waiting for an experienced user to chime in? I now see there is a lot of good info there. But I hadn't considered reading through issues to get answers to things more like FAQs . I could contribute by adding to the wiki, but again given my lack of knowledge, I'd be worried that I'd post incorrect stuff.
As a trivial example, one thing I'm stuck on is how to load a file that ends in ".sh" (its a bash file, but its suffixed ".sh" anyway, just because of historical reasons). I see that load appends ".bash" -- can I just call source instead? I'm not so much looking for an answer to this question, as to find the right forum to search for answers, ask the question if I can't find it, and post the answer for other newbies like me.
To put another way -- obviously, there is an active and helpful community here, but its hard to know how to tap into; for users that went help getting started; for anyway wanting to contribute bug fixes; for contributing documentation; for experienced users that want to give advice for newbies.
again, I don't mean to be argumentative, I appreciate your effort here. So that I can contribute constructively, one thing I could do is collate answers from some issues like https://github.com/sstephenson/bats/issues/175, https://github.com/sstephenson/bats/issues/192, https://github.com/sstephenson/bats/issues/191, https://github.com/sstephenson/bats/issues/190 on the wiki given your blessing.
I only recently found out about BATS, but I already think it is BATS*** awesome! I've already implemented it in one of my repos and will be migrating several others over in time.
But this conversation - from my perspective from the peanut gallery - seems to be going nowhere. @sstephenson hasn't commented in 10 months, and judging by the Network of forks, people are fracturing this project over time, so it needs management. It appears that multiple people have offered to take over management of the project, so what exactly is the holdup?
I'd caution against counting number of forks as an indicator of fracturing; considering that any fork opened for the purpose of a PR wouldn't be distinct from actually forking the project. Unless people are actually using any of those forks, the tallied number doesn't really indicate anything, IMO.
On Tue, Dec 6, 2016 at 12:31 PM, Rick Kasten [email protected] wrote:
I only recently found out about BATS, but I already think it is BATS*** awesome! I've already implemented it in one of my repos and will be migrating several others over in time.
But this conversation - from my perspective from the peanut gallery - seems to be going nowhere. @sstephenson https://github.com/sstephenson hasn't commented in 10 months, and judging by the Network of forks, people are fracturing this project over time, so it needs management. It appears that multiple people have offered to take over management of the project, so what exactly is the holdup?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sstephenson/bats/issues/150#issuecomment-265215348, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHUpBjx2hb-8xr6xt2IXWDy2pvHYeQKks5rFZvsgaJpZM4HeO5n .
Have any maintainers been nominated? I'd be willing to help maintain this. Shell scripting is what I enjoy doing on nights off.
@squito
I'm seriously quite incompetent at bash -- I can muddle through, but often feel like I'm probably "doing it wrong". I need a place to ask basic questions.
You're looking for a shell scripting guide, and sites like StackOverflow. Unless you know basic shell scripting (you don't need to be a wizard) you don't know the real power and limitations of Bats.
my interest is as someone interested in introducing bats to our internal tests, but need to know its in a somewhat stable position (given that I personally suck at bash and couldn't possibly fix any bats bugs) before we use it widely.
Bats is stable and pretty widely used I think (although I don't have traffic data). It has its quirks but many of them can be worked around.
Without knowing how to effectively use it, it would be hard to recommend to your team.
Disclaimer: I'm not affilated with the Bats project, I'm just another user like most of us here. This is my personal opinion.
What's the hold-up?
Simply put, there are no serious maintainer candidates. There are people who said they would be interested in taking over maintenance, but haven't demonstrated their ability to do so.
- Some haven't worked on Bats or commented on issues since nominating themselves, or at all.
- Some didn't even say why they want to be the new maintainer. Something that was explicitly asked of them.
- For some, the nominating comment was their only comment in the lifetime of Bats.
This is not an insult. Life happens, people can't always do what they want. I get it. The point is that there is no serious candidate to even consider at this point.
Same goes for most of the people who volunteered to be contributors. How many of them are actually active on the issue tracker? How many bugs have they helped to investigate? You get my point.
You don't hand over a project to someone unprepared and unproven, especially not one that is as critical to many software projects as Bats.
Again, not an insult. Just an observation. I just made good on my promise of writing up a list of issues and features to consider. After a 7 month delay... Life happens.
Obviously, this doesn't apply to @pgporada, who just nominated himself in the past 24 hours and didn't have time to demonstrate his ability yet.
No commit access necessary
You don't need write access to get the ball rolling. And it shouldn't be given until later. The transition process was clearly described, twice.
@sstephenson said on 2016-02-19 (emphasis mine)
Your first task would be to work through the major outstanding issues and ship a solid, stable Bats 1.0. I'm happy to work closely with you on prioritizing the work and answering any questions you have about the code base.
Beyond that, I'd leave the future direction of the project up to you.
@sstephenson said on 2016-02-21 (emphasis mine)
To reiterate, the short-term plan is to ship Bats 1.0, and the long-term plan is to hand over future decisions about the direction of the project to the new maintainer(s).
It seems clear to me that before reaching 1.0, @sstephenson would call the shots and do merges. The prospective maintainer would:
- identify and track major issues
- vet and refine new feature
- present ready-to-merge, high quality patches
- refine said patches based on feedback from maintainer
In short, work with the community and reduce the load on @sstephenson to major decisions, while getting cozy with the code base, including its coding style, design decisions and focus. So that once the project is handed over, it'll have a competent and knowledgeable new maintainer.
I think this seems a plausible scenario.
Bottom line
No maintainer candidates yet. Talk is cheap. Get to work! No offense. :)
Any news on this? I don't think looking for someone dedicated to reach a 1.0 would be a good idea. At least 2 or 3 users have proposed to help, and there are a lot of pull requests ready to be merged before that. That would make the project alive again, a step necessary before targeting something perfect (a full roadmap for 1.0 with a lot of collaborators). Thanks
I'd be interested in becoming a (or "the") Bats maintainer.
I've been studying Bash and Bats pretty extensively since last summer, putting together a passion project that's steadily become more capable: https://github.com/mbland/go-script-bash. Much of its initial design regarding modularity and documentation was inspired by studying rbenv. Many of the commit messages, issues, PRs, and comments document my encounters with various Bashisms, cross-platform issues, and cross-version issues and bugs. I've spent more time grepping through the Bash changelog than I ever thought I would in my career.
As a result of this experience, yesterday I submitted #210, a refactoring of Bats internals to eliminate subshells and external commands from bats-exec-test and bats-preprocess to achieve more than 2x performance gains on UNIX platforms, and at least 3x on Windows (update: I'd originally said 10x-20x because I was thinking of the overall improvement to the go-script-bash test suite after refactoring both the suite itself (to eliminate bats_debug_trap calls) as well as Bats). I also fixed a test failure on the default Bash 3.2.57 that comes with macOS thanks to errant ERR trap behavior across Bash versions.
Several of the issues from #196 ring familiar, and I have ideas about a few of them. For example, in #49, the issue happens because [[ doesn't trigger the ERR trap until Bash 4.1. However, I think in the while loop of bats-preprocess we might be able to detect lines that begin with [[ and safely append || false automatically to ensure compatibility. (I'd have to write a test to confirm this theory, of course.)
I've also noticed I've done a lot of work in my framework that basically overlaps with the libraries developed in #110. My lib/bats/assertions library relies on knowledge of how Bats traps work in order to provide fast implementations that pinpoint failing test case lines without stack information from the assertion implementations themselves. I'd be interested in consolidating the work somehow, perhaps migrating bits from my framework into the official libraries and then re-integrating them into the framework.
The reasons I haven't commented on several of the issues up to this point are twofold. One, I've been so heads-down on my project, I didn't even realize I was solving several Bats issues in the process. Two, when I did poke my head up recently to look at the issues and PRs, I honestly didn't want to spend time adding more comments to what appears to be a sizable array of lengthy, dormant threads. Some threads were closed since last summer, true, but the last was in December; the last PR merged was also in December, and the next-to-last a year before that.
Were I considered a serious maintainer candidate, I'd methodically work to resolve them. Before I invest the time, however, I'd need some indication that it will result in reasonably swift action (PR reviews and merges in particular).
Regardless, I'm all-in on Bats as the testing framework of choice for my project, and all the subsequent projects developed from it. I've never tried to manage a project as popular as Bats before, but I think I've the requisite commitment and technical insight at this point to give it a good shot.
cc: @stroupaloop
Hi all, I found myself here after a team I'm on agreed to stick with bats since it really is quite amazing. So, cheers for that. :)
Looking at the kind of talk going on here, I thought I would chime in with an idea. Many of the projects I have contributed to have found success in giving push access to anyone who manages to create a working PR. Giving people the power is often the first step to getting them motivated enough to do the work, even though "common sense" would dictate moving in the other direction. Git is distributed, and truly terrible accidents or betrayals can be recovered from. But they usually don't happen anyway.
Good luck to everyone! We'll see if we don't have any contributions of our own to make in the coming weeks and months.
I'm willing to help maintain this project. I use Bats on a bunch of projects and would love to see it thrive. I don't have experience in terms of contributing to this particular project...
It sounds like there is an opportunity to do some more careful vetting of pull requests and triaging of issues in order to support identified functionality for 1.0? I'd be willing to do that, and submit feedback on pull requests.
I too would love to see this project actively maintained again, and it seems like enough people are interested. However, like @ztombol mentioned, we need to make good on @sstephenson's request:
To reiterate, the short-term plan is to ship Bats 1.0, and the long-term plan is to hand over future decisions about the direction of the project to the new maintainer(s).
Since (AFAIK) no one else has write access to this repo, I propose the following high-level plan:
1. Roadmap 1.0: There are already existing high-quality PRs, and often-requested features and issues, especially here at #196 . Leverage these and consolidate into a single roadmap.
2. Create or choose a fork or mirror of this repo to use as the new mainline: Repoint existing PRs (whichever ones are possible) to the new mainline, get that repo to a stable 1.0. IMO we should create an organization and grant 2-3 people admin and write access.
3. Create PR of 1.0 to original repo (this one). (there's some git nuances here but nothing major)
--
Doing it this way accomplishes two things:
- Removes dependency on original maintainer (just in case!)
- Enables collaboration and contribution flow again
It seems like the missing element here isn't drive or interest, it's more about organization and a way to collaborate and chat with the existing contributors.
I'd be happy to make the effort to find somewhere to more easily chat (IRC, Slack, Discord, Gitter, etc.) so we can organize and make decisions. Also I'm quite into organizing projects, so if enough people are active and willing, I'd be happy to facilitate that too.
If @ztombol or @mbland or @jasonkarns or enough people gives this plan a 👍 I can get the ball rolling with a mailing list, org, and a more detailed plan + iron out git items, maybe nudge some people, etc.
EDIT: This effort has now begun at https://github.com/bats-core/bats-core!
Meanwhile, I've added a wiki page where folks can document their clones if they care too (I've linked my own). And also to makes a note of the current 0.1.0 situation and track its progress. There's a CI config for testing at travis, and docker images.
@bvberkum Great!
An update to my own post, I did end up creating the org and mirroring the repository here: https://github.com/bats-core/bats. I'm still figuring things out, but right now my immediate tasks are:
- Importing information on the Road to 1.0 (#196)
- ~~Copying Wiki and knowledge base~~ Done!
- Pointing existing contributors and to new org
@mbland @ztombol @jasonkarns and everyone: Please take a look at https://github.com/bats-core/bats-core/issues/4 and let me know if you're interested! :) Thank you.
@bvberkum @btamayo @mbland @ztombol @jasonkarns Few questions: What's are the differences between the two forks of bvberkum and bats-core? Is there a reason why development has not continued on a single unified fork? Are there plans to consolidate these two primary forks so effort is not being duplicated?
https://github.com/bats-core/bats-core https://github.com/bvberkum/bats
I assume these were a separate attempt to fork and decouple portions of bats: https://github.com/ztombol/bats-docs https://github.com/ztombol/bats-assert https://github.com/ztombol/bats-support https://github.com/ztombol/bats-file
Are these used as dependencies in bats-core, and if so should they be included in the bats-core organization repositories?
Just looking to gather some insight into the current state of bats.
@RichVRed The bats-core fork is definitely active, though it seems we all got swamped with work/life around the holidays and new year. I'm hoping we can get some momentum again in the next week or so.
We're looking to make bats-core the new standard distribution, and will host discussions there regarding how to manage extensions/dependencies.
@RichVRed this topic itself explains why focus diverged, there was noone to accept PR's.
I have been hard pressed to find some time to spend on a shell unittest framework as well. But I'll try.
@mbland if bats-core is indeed active and the successor for bats, then someone should really update https://github.com/ztombol/bats-support/blob/master/README.md since it has this..
Important: bats-core has been renamed to bats-support. GitHub automatically redirects all references, e.g. submodules and clones will continue to work, but you are encouraged to update them. Version numbering continues where bats-core left off.
And it's better to add deprecated message to README.md in this repo as well to stop other contributors keeping sending pr/issues here.
FYI: Repos can be set to read-only since a while.
Von meinem iPhone gesendet
Am 07.04.2018 um 06:40 schrieb david942j [email protected]:
And it's better to add deprecated message to README.md in this repo as well to stop other contributors keeping send pr here.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Wanted to emphasize @drennalls point. That quote from the bats-support readme is especially confusing, because it makes it sound like bats-core is a support library for bats instead of the current fork of bats. I would further advocate the adoption of some of ztombol's bats libraries into the bats-core org, especially bats-assert
FYI: I invite folks to check out the new Bats v1.0.0 release:
https://github.com/bats-core/bats-core/releases/tag/v1.0.0
We've resolved a number of open issues from this original repo, fixed a few more, and greatly improved performance—while maintaining compatibility with the v0.4.0 interface. It should be a drop-in replacement for v0.4.0, more or less; but issues illustrating the contrary are welcome.
@sstephenson please archive this repository and link to https://github.com/bats-core/bats-core
Is there any reason this repository is not archived and linked to the newer one? It's still confusing how it is now.
Just another heads up, bats current development status is a bit confusing for someone finding it via Github, so it would really be helpful to archive this repo, or at the very least add a few lines acknowledging the existence of bats-core in this README. Also thanks all involved, it's being really useful! 👍
I agree with @DazEdword, therefore I'm linking this PR here: https://github.com/sstephenson/bats/pull/248
Yep, please archive it to save people time! It is a small gesture. We did not ask to delete it, only to archive it.
