Adopt under the cucumber org? #1059
Comments
|
I don't feel qualified to have an opinion, but if it means getting more
support for the maintainers, it's great news.
Blaise
…On Thu, Sep 29, 2022 at 10:54 AM Matt Wynne ***@***.***> wrote:
We've had some feedback from within our community that they're worried
about contributing to Behave because they're not sure whether the project
is maintained anymore, and whether their changes would be merged.
I know Behave is pretty stable, but I can also see there are some PRs open
that have languished for a few years. I also know how much work it is to
maintain an open source project!
I wanted to extend an offer to invite Behave to move under the
github.com/cucumber/ organisation, similar to what happened with Godog
<cucumber/godog#207> a few years ago (although
hopefully this time without the maintainer stepping down! 😄 )
The aim would be that this move would attract some new attention to the
project, and enable us to find additional people willing to carry some of
the burden of maintenance.
What do people think?
—
Reply to this email directly, view it on GitHub
<#1059>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB6D6BAT23VTWAUKPRP3E3WAWUTXANCNFSM6AAAAAAQY3P4PY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora
<https://www.quora.com/profile/Blaise-Pabon> | Github
<https://github.com/blaisep>
“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
|
|
This project is dead already. No release since 2018. Any attempt to resurrect it would be better than the current state. |
This Project Is Maintained
This project is certainly not dead. It's in popular use, and the main branch has all the latest advancements. If @jenisys as the maintainer decides to not release a package that he is not 100% confident with then that is an unpleasant (for most) but safe choice (for everyone). If a release were out there that breaks everyone's workflow that would be even worse. – Ask yourself: Would you forgive Jens if he released a package that makes you unable to complete your daily work? Unlikely. You Can Install The Latest VersionLet me reiterate: You can install any version of behave from this repository using Pip easily, e.g. # latest version (from main branch)
python -m pip install git+https://github.com/behave/behave#egg=behave# a tagged version, see https://github.com/behave/behave/tags
python -m pip install git+https://github.com/behave/behave@v1.2.7.dev2#egg=behave# generic form
python -m pip install git+https://github.com/behave/behave@<git-sha-or-branch-or-tag>#egg=behaveRest assured, I'm with you in wishing for more frequent releases, but no releases on PyPI is maybe better than broken ones. Newer versions of the code can always be installed directly off GitHub. That's one of the great advantages of Free & Open Source software. Ack, It's Hard To ContributeYet still, I acknowledge, it's particularly hard to contribute on this project. I'm not 100% sure why Jens has such a hard time accepting others' contributions. For what I feel it seems hard for him to trust solutions that don't come from himself – and it's certainly correlated with a lack of time (e.g. to dedicate yourself to understanding a contribution). Personally, I do have permissions to merge PRs, but I very rarely make use of that power, and if I do it's usually for trivial contributions. I don't wont to betray Jens' trust. I feel it's better that I'm part of this project (as a last resort) than kicking myself out by unaccepted behavior. |
|
Perhaps better, then, would be a new, green-field project under the Cucumber project group to create a python solution that uses the "native Cucumber components" as much as possible. If it starts out as a collective endeavour from the beginning, hopefully it will avoid the difficulties of having a single maintainer having the onerous task of managing all the incoming requests and change approvals themself. It seems like there are a number of people willing to create a python solution, so I don't think there would be a lack of interested parties to support development. |
|
I've been consulting customers that have an absolute policy on that: stable releases only. That is 1.2.6 , no exceptions. And I can myself tell many stories of release engineering, even left a company myself on the argument of not honoring community contributions. |
|
I would be interested in helping a native cucumber project
…On Fri, Oct 7, 2022, 12:55 PM jsa34 ***@***.***> wrote:
Perhaps better, then, would be a new, green-field project under the
Cucumber project group to create a python solution that uses the "native
Cucumber components" as much as possible.
If it's starts out as a collective endeavour from the beginning, hopefully
it will avoid the difficulties of having a single maintainer having the
onerous task of managing all the incoming requests and change approvals
themselves.
—
Reply to this email directly, view it on GitHub
<#1059 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB6D6FSMMFMCYRGCF4K4LLWCBIXBANCNFSM6AAAAAAQY3P4PY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Behave is great, fits well with a bunch of python things, is well known and has a bunch of support out there. Breaking it or starting anew would be a real shame. I would want any "native cucumber project" to start from a fork of behave. |
|
I totally get the desire to not break people. It is very respectable and I think we all appreciate that. It doesn't sound like 1.2.7 will have backwards compatibility any time soon, though. I guess the question becomes, is 1.2.7 stable enough to be used in it's own right? If it is, then maybe a compromise is to use a roll out strategy that doesn't have a drastic impact on people. Instead of releasing behave-1.2.7, would it be possible to release behave2-2.0.0? Anyone with a non-pinned version of behave will not break. They may break when they change their dependency to behave2, but that is something that have to choose to pull in. The adoption of behave2 would give the maintainers the time to respond to any unforeseen issues. |
|
I second @intirix's opinion above. If 1.2.7 introduces breaking changes, then it should absolutely not be released as 1.2.7 as that would violate semver and cause a huge headache, I get that. So why not just call it 2.0.0 and ship it? For the record, the issue that @bittner linked above, #763, is one I opened, and the reason for the issue is that the "latest" docs are describing features that exist only on 1.2.7, but 1.2.7 is not actually released. So however you spin it, calling 1.2.7 the "latest" is incorrect and the docs are misleading at best, wrong at worst. If 1.2.6 is the latest official/supported/stable version that's been deployed to PyPI, then for all intents and purposes 1.2.6 is "THE" version people will use. Having the ability to install any arbitrary version from GitHub is a small comfort, as @xrg rightfully pointed out, since many orgs and teams won't mess with beta/preleases in their CI systems (assuming they even know about the 1.2.7 beta, most people will probably just use the "latest" PyPI release and look no further.) At the end of the day I don't have too much of a preference about what the releases are actually called or when they get out, but I do think it's important that all facets of the project (including the docs and the PyPI deployments) at least agree on what the "latest" version actually is. |
|
@bittner You said "the main branch has all the latest advancements" - that is largely true, but:
I have helped clients get a great deal of value from using Behave; I value it and have the greatest appreciation for @jenisys, for his hard work in creating it and offering it to the community as open source. That said, I think that, unless we have significant help from Jens to pull Behave apart and rewrite it to use the official Cucumber code, we will probably be better off starting over. I didn't say 'from scratch' because @mrkaiser has suggested that we could start from PyTest and reuse a lot of code. If we can find someone to lead and architect that project, then like @blaisep I would be interested in helping. |
|
@glenn-barker hows about we just do that, making it clear that this is beta code. This is a specific thing that FOSS licensing is designed to encourage. Depending on how @jenisys feels about this we can do it under a different name so that nobody can get confused or we can do it under the same name but with very clear 2.0.0-alpha1 type versioning (sermver compliant or not depending on what we are trying to signal) so that @The-BDD-Coach Behave's Gherkin parsing has, until now, been a superset of Gherkin that had certain advantages. Can the official parsers accept options to cover all of Behave's previous and possible future behavior? |
|
FWIW, @mattwynne and I considered updating the features (in general) to be
exemplary of all the latest gherkin capabilities.
Jens has done an exceptional job of creating feature files which we can
consult to determine any gaps in supporting behave from the reference
implementation.
…On Mon, Nov 14, 2022, 4:07 AM mikedlr ***@***.***> wrote:
@glenn-barker <https://github.com/glenn-barker> hows about *we* just do
that, making it clear that this is beta code. This is a specific thing that
FOSS licensing is designed to encourage. Depending on how @jenisys
<https://github.com/jenisys> feels about this we can do it under a
different name so that nobody can get confused or we can do it under the
same name but with very clear 2.0.0-alpha1 type versioning (sermver
compliant or not depending on what we are trying to signal) so that
@The-BDD-Coach <https://github.com/The-BDD-Coach> Behave's Gherkin
parsing has, until now, been a superset of Gherkin that had certain
advantages. Can the official parsers accept options to cover all of
Behave's previous and possible future behavior?
—
Reply to this email directly, view it on GitHub
<#1059 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB6D6CQDKJIWJCVQ2BLZKTWIH6MVANCNFSM6AAAAAAQY3P4PY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
💯 My motivation is to:
For me, the ideal thing would be to keep the Behave "brand" even if there was some kind of "Behave v2" (or perhaps v3) rewrite, but that's not my decision. Perhaps in the meantime we could forge ahead with recruiting that "someone to lead and architect" and starting to sketch out what it would look like, whatever it ends up being called. Writing a Cucumber is kindof a write of passage for many of us, and a lot of fun now that we have so many building blocks already done. I'm no pythonista but I'd certainly be happy to facilitate and support where I can. Any volunteers? |
|
So, I'm in a position to help for the next few weeks. I'm interviewing for
jobs, so I midget swallowed up by work in the next month, but I believe
that if we charge forward with an opinionated implementation, we will have
something working rather quickly.
…On Mon, Nov 14, 2022 at 3:24 PM Matt Wynne ***@***.***> wrote:
I have helped clients get a great deal of value from using Behave; I value
it and have the greatest appreciation for @jenisys
<https://github.com/jenisys>, for his hard work in creating it and
offering it to the community as open source.
That said, I think that, unless we have significant help from Jens to pull
Behave apart and rewrite it to use the official Cucumber code, we will
probably be better off starting over. I didn't say 'from scratch' because
@mrkaiser <https://github.com/mrkaiser> has suggested that we could start
from PyTest and reuse a lot of code.
If we can find someone to lead and architect that project, then like
@blaisep <https://github.com/blaisep> I would be interested in helping.
💯
My motivation is to:
1. ensure the Python community has an actively-maintained,
best-of-breed Cucumber implementation.
2. respect all of the work that Jens has invested into Behave.
For me, the ideal thing would be to keep the Behave "brand" even if there
was some kind of "Behave v2" (or perhaps v3) rewrite, but that's not my
decision. Perhaps in the meantime we could forge ahead with recruiting that
"someone to lead and architect" and starting to sketch out what it would
look like, whatever it ends up being called.
Writing a Cucumber is kindof a write of passage for many of us, and a lot
of fun now that we have so many building blocks already done.
Any volunteers?
—
Reply to this email directly, view it on GitHub
<#1059 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB6D6HQCXUBFRSSBLT3333WIKNZLANCNFSM6AAAAAAQY3P4PY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora
<https://www.quora.com/profile/Blaise-Pabon> | Github
<https://github.com/blaisep>
“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
|
|
I feel, what you all are saying is, "we want the behave project to be more active". More lively collaboration, no gatekeeping, a continuous flow of progress. Not a fork. Not if it could be easier, if it could be avoided. Right? It would be time for @jenisys to join the discussion and talk us into his point of view. Explain his picture of the future. |
|
Hi Peter,
Speaking for myself only, as a python fanboy, I would put it just a little
bit differently.
I would like Python to have first-class presence in cucumber.
All the latest developments from upstream should be available in Python,
either with Behave or with the upstream open-cucumber.
I would love for Behave to be a superset, where we might have features that
are more advanced than upstream... so that users of more primitive
languages (Javascript, rust, golang) can take advantage of the goodness by
upgrading to Python.
(and yes, I have a backlog of ideas for "next-gen" cucumber)
Again, for myself, I would love to see Behave move to Gerrit and zuul-ci,
so that we always have a working and deployable main branch and consume
much less of Jens' time.
But you can say I'm a dreamer...
…On Mon, Nov 14, 2022 at 4:09 PM Peter Bittner ***@***.***> wrote:
I feel, what you all are saying is, "we want the behave project to be more
active". More lively collaboration, no gatekeeping, a continuous flow of
progress. Not a fork. Not if it could be easier, if it could be avoided.
Right?
It would be time for @jenisys <https://github.com/jenisys> to join the
discussion and talk us into his point of view. Explain his picture of the
future.
—
Reply to this email directly, view it on GitHub
<#1059 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB6D6AUQIVO5FBFHHR6DH3WIKS7LANCNFSM6AAAAAAQY3P4PY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora
<https://www.quora.com/profile/Blaise-Pabon> | Github
<https://github.com/blaisep>
“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
|
|
Well I'll note that there are 22 unmerged to 260 merged pull requests on behave which looks pretty good to me, so I'd also say there's a definite "please don't break what isn't broken" part here. I've also found Jens responsive in situations of behave bugs / strangeness in the past so there are two things
A new, less complete cucumber implementation would be lots less useful than a better working version of behave and might divide the community. On the other hand, ensuring that python behave was a feature complete cucumber implementation seems really useful. |
Stable behave is years old by now, latest tagged commit in its main is a bit better at 1.5 year old as of today. Let's switch to it to see if there are any problems. Links: * behave/behave#1030 * behave/behave#1059 * behave/behave#855 (comment)
Stable behave is years old by now, latest tagged commit in its main is a bit better at 1.5 year old as of today. Let's switch to it to see if there are any problems. Links: * behave/behave#1030 * behave/behave#1059 * behave/behave#855 (comment) MR: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1346
Stable behave is years old by now, latest tagged commit in its main is a bit better at 1.5 year old as of today. Let's switch to it to see if there are any problems. Links: * behave/behave#1030 * behave/behave#1059 * behave/behave#855 (comment) MR: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1346
Stable behave is years old by now, latest tagged commit in its main is a bit better at 1.5 year old as of today. Let's switch to it to see if there are any problems. Links: * behave/behave#1030 * behave/behave#1059 * behave/behave#855 (comment) MR: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1346
Stable behave is years old by now, latest tagged commit in its main is a bit better at 1.5 year old as of today. Let's switch to it to see if there are any problems. Links: * behave/behave#1030 * behave/behave#1059 * behave/behave#855 (comment) MR: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1346
Stable behave is years old by now, latest tagged commit in its main is a bit better at 1.5 year old as of today. Let's switch to it to see if there are any problems. Links: * behave/behave#1030 * behave/behave#1059 * behave/behave#855 (comment) MR: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1346
Stable behave is years old by now, latest tagged commit in its main is a bit better at 1.5 year old as of today. Let's switch to it to see if there are any problems. Links: * behave/behave#1030 * behave/behave#1059 * behave/behave#855 (comment) MR: https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1346
@mattwynne Matt would the Cucumber compatibility tool kit help to direct work? |
|
@Johnlon I think this thread has become obsolete; Kostya Goloveshko has forked Pytest-BDD to create Pytest-BDD-NG, using the official Cucumber Gherkin parser. It also supports Cucumber Expressions, the Messages protocol, and other good things. I have started a tutorial series. However, there are ongoing discussions about merging Pytest-BDD-NG back into Pytest-BDD, and possibly moving Pytest-BDD into the Cucumber repo. Your help with that would certainly be appreciated. |
|
And parallelism and support for attachments? |
|
And yep I might be able to help. Looking at godog it also needs some work. |
|
You would have to ask Kostya about parallelism; I haven't explored that. I don't know what you mean by attachments; please give me an example. |
|
In cuke you can add embeddings , same in behave (master).
A step can attach some content with a name and media type.
…On Thu, 2 May 2024, 9:53 pm The-BDD-Coach, ***@***.***> wrote:
You would have to ask Kostya about parallelism; I haven't explored that. I
don't know what you mean by attachments; please give me an example.
—
Reply to this email directly, view it on GitHub
<#1059 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGMFGGHIQHTLPZCAAA22BDZAKRUZAVCNFSM6AAAAAAQY3P4P2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJRGUZTONJUGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
We've had some feedback from within our community that they're worried about contributing to Behave because they're not sure whether the project is maintained anymore, and whether their changes would be merged.
I know Behave is pretty stable, but I can also see there are some PRs open that have languished for a few years. I also know how much work it is to maintain an open source project!
I wanted to extend an offer to invite Behave to move under the github.com/cucumber/ organisation, similar to what happened with Godog a few years ago (although hopefully this time without the maintainer stepping down! 😄 )
The aim would be that this move would attract some new attention to the project, and enable us to find additional people willing to carry some of the burden of maintenance.
What do people think?
The text was updated successfully, but these errors were encountered: