Pulse of this repository #630
Comments
|
That makes me think that it might also be worth considering the Academy Software Foundation (ASWF): https://www.aswf.io/ |
|
Hey all,
First, apologies for recent inactivity. Life, sickness etc. Will be getting
up to speed on recent email threads pretty soon, and merges should start
happening again.
RE a development plan, yes this is something I've been thinking about. I
think it does make sense, and it'd be good to do a full writeup outlining
the goals, and the features/fixes necessary to get there. I think I'll
concentrate on this next. In order to get rez to where (I think) it should
be, we'll need a combined effort. Some of the necessary work will be
challenging.
RE ASWF, it is something I am considering. I think it'd be good to get the
project into a more orderly state before going that route however. But in
theory I have no issue with passing it into the ASWF and with changes to
governance that would come with that. Ultimately it would help the project
become a standard for our industry, and that's been my goal all along
(because let's face it, who wants to keep writing their own tech to deal
with this crap?!)
Thx all,
A
…On Tue, May 21, 2019 at 8:18 PM Thomas Mansencal ***@***.***> wrote:
That makes me think that it might also be worth considering the Academy
Software Foundation (ASWF): https://www.aswf.io/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSUSTLD73CALD6LZWWDPWPD6ZANCNFSM4HOJOBMQ>
.
|
|
Thanks for getting back, and again, the problem isn't inactivity, but that inactivity leads to inaction. Inaction due to inactivity can be solved by having someone able to move the project forwards - especially on things you're happy with but just haven't got the time for (which again, is totally fine!). For example, PRs like #355 could probably have been taken over and implemented by contributors. As another example, submitting this project for review to ASWF could also be done by a contributor; all you have to do is ask. :) This isn't a power struggle; it's a way to avoid year-long PRs and internal forks from having to take place and be maintained at all. We're all solving the same problems, and if we band together we'll be that much stronger. Like a rez-bundle of sticks. |
|
Out of curiosity, does anyone besides @nerdvegas have permissions on this repo? Even things as simple as going through the issues and closing, merging, tagging, and cleaning them up -- there are probably a good number of contributors that would gladly do that work, so at least there's a better idea of exactly what changes need to be made. |
|
I'm the only one that has merge permissions.
Let me look at things in GitHub soon and see what the options are. I would
feel better about opening up access if GH can be configured to only allow
merges after a certain number of approvals, things like that.
Thx
A
…On Thu, May 23, 2019 at 5:24 AM Brendan Abel ***@***.***> wrote:
Out of curiosity, does anyone besides @nerdvegas
<https://github.com/nerdvegas> have permissions on this repo?
Even things as simple as going through the issues and closing, merging,
tagging, and cleaning them up -- there are probably a good number of
contributors that would gladly do that work, so at least there's a better
idea of exactly what changes need to be made.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSSV4VGZCGJA2J4GNLTPWWMV3ANCNFSM4HOJOBMQ>
.
|
|
Hello Allan In terms of allowing merges after a certain number of approvals please see the Github documentation I know for a fact that myself and many other contributors would like to help you manage the repository We are open for discussion so let's come up with a plan to improve the flow of the repository that will enable us to take rez to the next level. I would like to see things like
I can come up with many other things but this is a good start. Will be happy to help to put some of them together given the community and you agree with this direction. Also feedback and additional ideas are welcome! Thank you. |
|
Thanks for that link Ira, I'll take a look. I'm also going to spend some
time looking into GH in general and seeing what features we can take
advantage of.
A
…On Thu, May 23, 2019 at 10:25 AM Ira ***@***.***> wrote:
Hello Allan
In terms of allowing merges after a certain number of approvals please see
the Github documentation
about required reviews
<https://help.github.com/en/articles/enabling-required-reviews-for-pull-requests>
on how to enable it.
I know for a fact that myself and many other contributors would like to
help you manage the repository
by doing tasks such as the ones mentioned by Brendan.
We are open for discussion so let's come up with a plan to improve the
flow of the repository that will enable us to take rez to the next level.
I would like to see things like
- multiple maintainers/reviewers to get code into the repository
quickly and allow people to work on new tasks
- issue replies and management (closing, proper tagging such as type
etc and assigning)
- a pinned task list maybe in the form of a roadmap so that we can
assign ourselves to tasks and avoid work duplication - maybe each task
should include effort required so that if it is a big undertaking
contributors can collaborate on the same task (mini teams)
- well defined procedures and templates for everything that has to do
with the repo - merge requests, issue creation, code styling, commit
styling, new branch creation, naming, tags etc
- revamp the wiki to include better contributor guidelines, links to
new slack channel etc
I can come up with many other things but this is a good start.
Will be happy to help to put some of them together given the community and
Allan agree with this direction. Also feedback and additional ideas are
welcome!
Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSWMBIFSAYJIEPWUAYLPWXQBBANCNFSM4HOJOBMQ>
.
|
|
I agree with what all of you guys said.
And we will have to define Where do you guys think we should have these conversations? In the forum? Here? Video conference? Somewhere else? By smoke signals? (Yeah, I'm open to literally all options 😛 ) Because the first thing to determine before starting a discussion is where we should do it and in which format. (at least to me it's the first step). I'm super happy to see things moving! jcmorin |
|
Hello Jc,
Agreed.
Although smoke signals sound intriguing my vote goes for a video/audio conference. No need for people to show their faces if they don't want to, I respect everyone's privacy. I think the discussion is just too involved and doing it via text messages or even worse forum posts will be time consuming and confusing with everyone typing messages frantically trying to get their opinion and ideas before someone changes the subject. The way I see it,
I am also excited to get the ball rolling, here is hoping. Ira |
|
@nerdvegas Yeah, the Github permission system can be a bit janky. You can add Collaborators to give other people "write" access, which would allow management of Issues and Pull Requests, but also gives them write and push access to the repository. You can use "Protected Branches" to prevent collaborators from pushing directly to master (or any branch), and you can use the CODEOWNERS file to set certain people (like yourself) as required Approvers on Pull Requests before they can be merged. |
|
Hi everyone, Because of the amount of ongoing activity and until Allan finds the time to implement this plan, I'd like to offer to get started doing this in the bleeding-rez repo, in ways that are applicable to this repository and can be continued here once the wheels start turning. Here are some of the things I'd like to see finalised asap.
These are the ones that apply to just my situation; which ones are you interested in seeing merged? In the chat, @wizofe mentioned wanting to work on new docs, let's set this up with GitHub pages as well. Future PRsOnce these are put behind us, there are a few more things I've got in mind on my end.
$ rez wheel --install six Qt.py pyblish-base
$ rez choco --install python==3.7
$ rez vcpkg --install physx ilmbase qt==5.12
$ ...(Note that those issues are still being worked out before being submitted here, primarily awaiting merging of the above PRs) Next StepsI'd like to invite you to submit PRs that Allan's approved but hasn't had the time to merge just yet, be it yours or anyone elses that you could benefit from, like the custom package orderer. Some of them involve refactoring. The PR section has got a few gems in it! Then I'd like to assign you with maintainer roles so we can test out the above theory of continued collaboration, and enable the Kanban-board style of issue triaging to see where that goes. By this time next week, I expect we'd be able to reduce the PR section by 50%, and have a fully functional version of Rez for Python 3 and Windows on PyPI and from there the sky's the limit! Let me know your thoughts! |
|
Hi @mottosso , I'd say we could probably wait a little bit more. I don't see anything urgent that forces us to move to another place yet. It's not like Allan didn't answer over a year or something or disagreed with changing the maintainer model, etc. He answered last weekend (ish) and showed some great openness. Moving in your repo would also mean that if some PRs are merged there but are never merged here (for whatever the reason is), it might force you to continue your public fork and so might cause some confusions in the community as to which rez to use. This is just a theory yes, but it's a possibility and should be taken into account IMO. But at the end, we probably all have forks with changes that will probably never made it to the upstream, because they are too specific to our workflows (Like custom repository types for example) or we know it wouldn't benefit the entire community or goes against it. I would personally stick to basically what @lambdaclan JC |
|
How about moving development to a github organization? We'd have more control over permissions, and if we decide to go the route of creating a centralized package repository for common packages, then the repos could be organized together in one place.
To be fair, this problem didn't start a week ago when this issue was opened. The long list of open PR's and Issues didn't appear overnight. I think it's fair to say that there are contributors and maintainers who would contribute more to rez development, but can't (or aren't motivated to) because they don't have permissions on the repo and their contributions aren't being given clear yes or no decisions.
I think it's fair to say we're discussing moving community development to another repo, so that's kind of the point.
We don't need to have a convention and meeting notes to fork a repo. And there's no reason we have to be particular about who can contribute. I'd be fine with forking the repo and giving anyone who's contributed in the last year write access if they want it. That's probably less than a dozen people. |
That's a good idea, it would also make the ownership a little less personal (hosted under an individual username) and a little more collaborative (multiple users in a given organisation). I had a quick look and both rez and rezolve usernames are occupied. :( What's a good alternative organisation name?
Technically unimportant, but good for branding and new-user (and studio!) appeal. |
|
Out of those, I think I'd prefer rez-dev or getrez There's also
|
|
Hi all,
I will first echo what JC has said - I'm up for opening access and I just
want to review GH options for doing that before I commit. I have time
tonight to look into this, although I'll probably spend most of my time
getting on top of the PRs that people are more interested in (as noted by
Marcus earlier), until I hear some more feedback from this thread. But to
reiterate - I am in favour of opening permissions on the project, I just
want to ensure that the right amount of oversight is still in place when we
do that.
The first step I am interested in taking, is opening merge access to
contributors, with the caveat that PRs require an approval from me. This is
just a first step - if everything goes well then permissions will be opened
further. This isn't so much about me keeping control, it's more about
keeping the project healthy. I can tell you there have definitely been a
number of PRs in the past that initially made changes that would have had
negative impact - rez is a big project now and without a lot of familiarity
with it, it's hard to know what all the implications of one change are
going to be. It's just inherently easier for newer contributors to make
mistakes in this regard - I don't mean that as a judgement of anyone's
abilities, I think it's just something that's inherently true in software
development.
I don't think moving to another repo would be a good move at this stage. It
may make sense from the point of view of developers who want to iterate on
the project more often; but bear in mind that hundreds of studios (I
guestimate) are using rez, and a lot of those are going to value stability
over anything else. I fear that a different repo could cause confusion and
a split in development that broadly splits between new/smaller studios and
individuals, and larger established studios. However, another reason is
because at this stage I'm still thinking that a move to an ASWF project is
possibly on the cards too, and I don't think shifting the project twice
would be helpful to anybody.
Happy to hear people's thoughts.
A
Ps:
To touch on some specific points/PRs that have been raised here:
Py3 support: I would love to merge this PR, but if it includes all previous
PRs, it's almost certainly going to break multiple things at once, that the
tests don't happen to cover. This will probably result in a new rez version
that some studios who use rez extensively, simply won't be able to use. I
agree with the approach and am glad to see futurize used, as that was my
thought also; but it would be better to merge this as its own feature and
deal with the conflict on other PRs one-by-one, especially as I don't see
that these conflicts would be too complicated to deal with.
CustomPackageOrderer: Unfortunately as elrond mentions, this PR is not
compatible with master. The reason as I recall has to do with its support
for applying different orderers on a per-family basis. Master does this
already, but in a way that's more optimal. However, I completely agree with
what this PR brings to the table (especially the ability to configure
orderers in the config, which has been wanting for ages). I would like to
work on a new PR incorporating this feature in a way that's compatible with
the existing PackageOrderer classes (or would welcome someone else doing
the same). IIRC elrond and I happened to work on package orderers around
the same time, and this conflict in approaches has been there from the
start.
Reversed version range: I think I will merge this one shortly. I had
reservations, because I wanted to be confident that the change would not
impact on resolve times. However, the only way to be confident of that is
to have an extensive rez benchmarking program (something I've wanted to
work on for some time now). What I intend for this is to take a copy
Method's existing packages (payloads removed and names anonymized); then,
produce a list of resolves that form the benchmark, and provide tooling for
running these resolves and plotting out the results. You have to be careful
making changes that can affect resolve times (as I have found in the past,
sometimes painfully) - a change that looks like it's sped up resolves can
sometimes also make slow resolves even slower, for example.
PyPi/wheel/rez-pip: I'm fine with merging these PRs, I just need to check
what the latest state of things is first. I've voluntarily taken a backseat
on this aspect of rez development, as I'm more interested in features that
improve rez as a package manager in its own right, as opposed to bridging
it with other managers. I'll spend some time tonight catching up on this.
If GH allows it, it could make sense to have a branch opened up to merges
from all contributors, and only clamp down on permissions when merging to
master.
Windows support: Similar issue to above, I don't develop on Windows and I'm
happy to accept PRs that improve the situation. A dedicated branch could
also be good for this case.
Wiki: I don't follow what the issue is here. All the docs are in the wiki/
folder of the project, and there's a bash script there that pushes all
updates to github wiki. Are you referring to updates to wiki/ in
outstanding PRs, that haven't been pushed to github wiki yet?
Wrt performance improvements. That's quite a big conversation. I've done a
lot of work on the solver (where the biggest gains are to be made) but
there are still some improvements I have in mind. We should talk about
this. One thing to bear in mind is that time spent loading package
definitions off disk isn't very relevant - a production rez deployment
should be using memcached, and in this setup, disk access is already
heavily minimised.
…On Sat, Jun 1, 2019 at 11:54 PM Jean-Christophe Morin < ***@***.***> wrote:
Hi @mottosso <https://github.com/mottosso> , I'd say we could probably
wait a little bit more. I don't see anything urgent that forces us to move
to another place yet. It's not like Allan didn't answer over a year or
something or disagreed with changing the maintainer model, etc. He answered
last weekend (ish) and showed some great openness.
Moving in your repo would also mean that if some PRs are merged there but
are never merged here (for whatever the reason is), it might force you to
continue your public fork and so might cause some confusions in the
community as to which rez to use. This is just a theory yes, but it's a
possibility and should be taken into account IMO.
But at the end, we probably all have forks with changes that will probably
never made it to the upstream, because they are too specific to our
workflows (Like custom repository types for example) or we know it wouldn't
benefit the entire community or goes against it.
I would personally stick to basically what @lambdaclan
<https://github.com/lambdaclan>
said in #630 (comment)
<#630 (comment)>.
That is, plan things or at least discuss things before moving forward.
(Yep, I'm also that boring guy that prefers to well plan things ahead)
JC
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSRC3PINBADNXYLX3N3PYJ5PPANCNFSM4HOJOBMQ>
.
|
Agreed, it would only cause confusion, the development might seem slow for some and could generate frustration for others (which I understand) but the reality is that Rez is certainly not stalled to the point where I think it requires shaking the whole tree. Cheers, Thomas |
|
@nerdvegas How about moving the repo to an organization? It gives us more options for permissions, including visibility into who has permissions, and we'd get a bunch of cool features like teams/discussions/projects/etc. If you need help setting up the Github permissions, let me know, they're really not that difficult.
I agree, That's even more of a reason that you want more people invested in doing code reviews and approving PR's. No one is going to submit perfect PR's the first time every time (including you), but the solution to that isn't to restrict merge approvals and code reviews to a single person.
Honestly, it's not really about how fast the project is moving. It's more about just having a clear direction and motivation to do more work on the repo. There's very little point for contributors to discuss issues and do code reviews if they have no authority to approve any changes and their PR's never get any feedback from the one person with merge access. It's okay to say no to a PR. It's far worse to let PR's that you know you'll never merge stay open and let people keep working with that direction in mind. |
|
Below.
On Sun, Jun 2, 2019 at 3:41 PM Brendan Abel ***@***.***> wrote:
@nerdvegas <https://github.com/nerdvegas> How about moving the repo to an
organization? It gives us more options for permissions, including
visibility into who has permissions, and we'd get a bunch of cool features
like teams/discussions/projects/etc. If you need help setting up the Github
permissions, let me know, they're really not that difficult.
I'd rather enable more collaboration on the existing project first, and go
from there.
I can tell you there have definitely been a
number of PRs in the past that initially made changes that would have had
negative impact - rez is a big project now and without a lot of familiarity
with it, it's hard to know what all the implications of one change are
going to be. It's just inherently easier for newer contributors to make
mistakes in this regard - I don't mean that as a judgement of anyone's
abilities, I think it's just something that's inherently true in software
development.
I agree, That's even more of a reason that you want *more* people
invested in doing code reviews and approving PR's. No one is going to
submit perfect PR's the first time every time (including you), but the
solution to that isn't to restrict merge approvals and code reviews to a
single person.
I definitely do want more people involved in code review and approving PRs,
and I think you're right that this will mean people are more invested in
the work.
I don't think moving to another repo would be a good move at this stage.
It may make sense from the point of view of developers who want to iterate
on the project more often;
Honestly, it's not really about how fast the project is moving. It's more
about just having a clear direction and motivation to do more work on the
repo. There's very little point for contributors to discuss issues and do
code reviews if they have no authority to approve any changes and their
PR's never get any feedback from the one person with merge access.
It's okay to say no to a PR. It's far worse to let PR's that you know
you'll never merge stay open and let people keep working with that
direction in mind.
You can look at the history of the 258 merged PRs in this project to see
that there's been a lot of feedback from me. And wrt the PRs that are
outstanding, I don't think there are any that I intend not to merge -
typically, older PRs have fallen into an "it's complicated" status for one
reason or another, and the odd few have ended up as dead ends, as the
project have developed over time. I have on occasion declined PRs.
What I want to do from here on in is the following:
* Open up more collaboration in a controlled manner. This means making a
change to workflow / permissions, assessing how that goes (including
feedback from contributors), and iterating;
* Work on a roadmap detailing where I see the project going, and creating
tickets related to this. There are some major features that need to be
worked on to turn rez into a fully fledged package manager, and it'd be
great to see a focused effort on this. In order to really drive adoption in
the industry, I think people need to be able to easily install entire
dependency chains of packages from a public repository using rez. We aren't
there yet.
* Dedicate more of my time to moving the project forward. What I would like
to do is spend less time on development, and more time giving feedback on
PRs and getting those merged.
To that end, I propose:
* Adding as collaborator anyone who has done rez development thus far and
who expresses interest in becoming a collaborator;
* Restricting merges to master, for the time being.
I'd like to see how the team actually does collaborate for a while, before
we determine what the next steps are. Bear in mind that this is an 8 year
old project, that's getting real use, and that studios regard as pretty
stable (and that's fairing better than a lot of VFX OSS projects!). Any
large and sudden changes (including code- and governance- wise) may put
that at risk. Of course, it's a free world, and anyone is free to fork the
project, but it'd be a shame to see it potentially diverge.
A
—
… You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSR5JZDNLWDEIRV3NLLPYNMQ3ANCNFSM4HOJOBMQ>
.
|
|
Making some good progress here! Overall, it sounds like we're in agreement about one thing:
What remains is finding a suitable compromise. Breaking Changes
I think we can all agree this is unwanted. Zooming out a bit, this has to do with making a potentially breaking change and how to deal with it. From where I'm standing, I see two contradicting audiences to Rez.
Maybe there's a way to appeal to both. For example, we could introduce
In practice, we could do something along the lines of:
That way, extensive users seeking stability use a stable version, and let the rest of us get on with development and release (beta) versions early and often. The all-knowing contributor
This is something I've seen echoed a few times both on the mailing list and chat, and it's a problem.
So is there nothing we can do? I think there is. Tests only really have to cover expected behaviour, which is a much smaller subset of things to test. If everything expected is covered, then tests wouldn't catch all breakage (e.g. , but it would catch breakage of what is expected. If we can manage that, then suddenly:
Can it be done? Not as a one-off, I think. Expected behaviour changes and grows within any project, and the way to counter it is to write tests for (1) the behaviour you intend alongside any change or feature and (2) for what should have been, once a problem occurs. This is something we could start doing right now. With beta-releases in place, swapping between stable and beta is made easy, which in turn make testing easy.
Again, this comes back to having to understand everything about the system before making contributions. My guess is you probably didn't look at the issue, because if you did you'd see that not only does a Right this second, we could pick one each, solve it, and be back in time for dinner. Frontseat Driver
Just a minor note on this as I've seen this echoed before; taking a backseat is one thing, getting out of the car and locking the door is another. :) If you really had a backseat, those would be merged by now. I invite you to try and actually take a backseat. If it backfires, you can always revert commits and give whomever is responsible the business. Fork vs. Branch
Could you elaborate on this? Do you mean a separate branch with its own release cycle and userbase? Like a fork? This seems counter productive. The PRs are ready now, and fit perfectly with Linux and Mac. Moving House
I hear what you and Thomas are saying, but this is a solvable problem.
ASWF
Surely, ASWF doesn't require that you move the repository? I had a quick look, and they do have an org with a few projects, some of which are hosted both there and elsewhere. Frankly, the more I read about ASWF the less I think it is in our interest to join; they seem to enforce a great deal of stability (read: Process) into development which would bring us right back here again. It makes sense for software embedded in and shared amongst DCC vendors, like Alembic and VDB. But there is only ever one version of Rez, and that's the one right here. We should use that to our advantage. Wiki
Sorry, should have been more clear. Having said thatJust to cover all grounds, there's one other extreme I'd like to touch on. It's possible Rez has over-matured. That what users has done with it over the past few years prevents or discourages change. It may even be in the interest of users to not see change, only maintenance. This isn't your average text editing app whereby you can easily swap it out for some alternative; whomever has committed to Rez has gone all-in and staked all of a companies software-assets on its continued survival. If so, we need to set course for a future where this is less likely to happen again (e.g. #634) and either (a) increment the major version or (b) consider starting anew. |
Wanted to underline this as I know first-hand how hard it can be to hear you aren't doing enough when you're doing everything you can (noticing you wrote this at 3 AM on a Sunday). The issue isn't a lack of contribution, but a lack of parallelism. Nobody can say you haven't done enough or should do more. This is indeed a lot more active and used than a lot of open source projects and I think we all agree you're doing a marvellous job in keeping the project together and on track all this time. 🥇 |
|
Just keeping it short and in point form as I'd like to catch up on all the
email tonight..!
* Py3: Why do you see this causing backwards incompatiblity? I was under
the assumption you'd gone with futurize specifically because it is able to
produce py2/3 compatible code.
* A beta branch is something I've considered, but without oversight (ie
anyone able to commit) this won't solve anything. Although it will protect
the master branch, it will also result in large PRs to master containing
lots of unrelated changes, that will be virtually impossible to curate.
However, *with* similar restrictions as master, a beta branch would be
useful - regressions do happen, I'm guilty of that myself (just look at the
release notes), and a beta branch would avoid these to a large extent.
* Performance. Yes I looked at your issue. But it was not clear if this
profiling was done in a situation where all packages had been cached to
memcached yet (and that's the situation that matters, because that's the
99% case in production). I was confused by this too tbh, as at Method we
regularly resolve environments that contain hundreds of packages and that
touch tens of thousands, and these resolves don't necessarily take as long
as this. And, when they do, it's the solver that most of the time is spent
in. I've done a lot of profiling in the past (and use runsnakerun also -
that squaremap is win). But some of the timings I see in your results are
completely at odds with what I've seen before. For eg, 40 seconds in
platform_.py? And pyparsing - where is that coming from? That should only
be getting used when loading the resolve graph (indirectly via pydot).
Perhaps things are looking pretty different on Windows? In any case, it's
worthy of further investigation. Note btw that there's a `rez-env
--profile` option for cprofiling (in case you weren't aware of it).
* Windows dev. Isn't the oldest outstanding windows PR from 19th April?
That isn't a terribly long time. I'll make it a point to get this merged
soon. To help with tracking I'll also add some new label types, including a
`windows` one.
* Wiki - see my comment on that issue. It's working fine - the "Configuring
Rez" chapter is a special case and its content is derived directly from
rezconfig.py, as the comments in that sourcefile state.
* ASWF - officially sponsored projects are forked onto their page and
become the new development location.
* Starting again. This takes far longer than you'd think, and takes far
longer to reach the same adoption levels as the original project than you'd
think. I know this because I wrote all of rez-v1 and most of rez-v2 (which
was basically a complete rewrite). Had I the spare time, I would like
nothing more than to start from scratch. It's a very tempting idea, but
it's also often a huge undertaking that doesn't have anything to show for a
long time.
…On Sun, Jun 2, 2019 at 8:01 PM Marcus Ottosson ***@***.***> wrote:
Making some good progress here! Overall, it sounds like we're in agreement
about one thing:
- We'd like to increase the development pace, but acknowledge that
stability and project direction is important
What remains is finding a suitable compromise.
Breaking Changes
Py3 Support ... This will probably result in a new rez version that some
studios who use rez extensively, simply won't be able to use
I think we can all agree this is unwanted. Zooming out a bit, this has to
do with making a potentially breaking change and how to deal with it.
From where I'm standing, I see two contradicting audiences to Rez.
1. Extensive users want stability
2. New users and developers want progress
Maybe there's a way to appeal to both. For example, we could introduce
beta releases.
- rez-2.30.0 Latest stable release
- rez-2.31.0b Latest beta release
In practice, we could do something along the lines of:
- The master branch is made protected, and contains an always-stable,
latest-released version of Rez, e.g. rez-2.31.0. No pushing here, only
pull-requests, and merging is done rarely by one or few people.
- A beta branch is writable by contributors and is considered
beta-stability. Meaning no WIP features or partial commits, but breakage is
permitted and to be expected from anyone using it. Releases made here are
tagged beta, e.g. rez-2.31.0b
That way, extensive users seeking stability use a stable version, and let
the rest of us get on with development and release (beta) versions early
and often.
The all-knowing contributor
rez is a big project now and without a lot of familiarity with it, it's
hard to know what all the implications of one change are going to be.
This is something I've seen echoed a few times both on the mailing list
and chat, and it's a problem.
- At one extreme, no change can be made without fully understanding
everything. That's obviously bad and would prohibit contributions from
anyone (including yourself).
- At the other extreme any breaking change is picked up by tests. That
would of course be great, but even tests cannot encompass everything.
So is there nothing we can do? I think there is. Tests only really have to
cover *expected* behaviour, which is a much smaller subset of things to
test. If everything expected is covered, then tests wouldn't catch all
breakage (e.g. , but it would catch breakage of what is expected.
If we can manage that, then suddenly:
1. The pace of PRs can increase, as we wouldn't have to worry about
breakage or take the time to fully grasp the contents of the PR and
implications of the PR into the greater whole.
2. Contributors would be encouraged to try and implement something
that both adds value and passes the tests. If it does, we all win.
Can it be done? Not as a one-off, I think. Expected behaviour changes and
grows within any project, and the way to counter it is to write tests for
(1) the behaviour you intend alongside any change or feature and (2) for
what should have been, once a problem occurs.
This is something we could start doing right now. With beta-releases in
place, swapping between stable and beta is made easy, which in turn make
testing easy.
Wrt performance improvements. That's quite a big conversation.
Again, this comes back to having to understand everything about the system
before making contributions. My guess is you probably didn't look at the
issue, because if you did you'd see that not only does a rez env take *200
seconds*, it also pinpoints exactly what is it that's taking so long,
down to the individual call and their total contribution.
Right this second, we could pick one each, solve it, and be back in time
for dinner.
Frontseat Driver
I've voluntarily taken a backseat ..
I don't develop on Windows ..
Just a minor note on this as I've seen this echoed before; taking a
backseat is one thing, getting out of the car and locking the door is
another. :) If you really had a backseat, those would be merged by now. I
invite you to try and actually take a backseat. If it backfires, you can
always revert commits and give whomever is responsible the business.
Fork vs. Branch
Windows .. A dedicated branch could also be good for this case.
Could you elaborate on this? Do you mean a separate branch with its own
release cycle and userbase? Like a fork? This seems counter productive. The
PRs are ready now, and fit perfectly with Linux and Mac.
Moving House
I don't think moving to another repo would be a good move at this stage
... hundreds of studios are using rez
I hear what you and Thomas are saying, but this is a solvable problem.
1. Whenever a project moves within GitHub, GitHub forwards any
requests to a former location to the new one. This includes those coming
from a browser *and* made via git clone/pull/push. The only noticeable
change to the end-user is the address bar automatically changing in their
browsers on visit.
2. Alternatively, keep the old project here, and insert a "Project has
moved to X!" banner.
ASWF
However, another reason is because at this stage I'm still thinking that a
move to an ASWF project is possibly on the cards too
Surely, ASWF doesn't require that you move the repository? I had a quick
look, and they do have an org with a few projects, some of which are hosted
both there and elsewhere <https://github.com/imageworks/OpenCue>.
- https://github.com/AcademySoftwareFoundation
Frankly, the more I read about ASWF the less I think it is in our interest
to join; they seem to enforce a great deal of stability (read: Process)
into development which would bring us right back here again. It makes sense
for software embedded in and shared amongst DCC vendors, like Alembic and
VDB. But there is only ever one version of Rez, and that's the one right
here. We should use that to our advantage.
Wiki
I don't follow what the issue is here.
Sorry, should have been more clear.
#600 (comment)
<#600 (comment)>
Having said that
Just to cover all grounds, there's one other extreme I'd like to touch on.
It's possible Rez has over-matured. That what users has done with it over
the past few years prevents or discourages change. It may even be in the
interest of users to not see change, only maintenance. This isn't your
average text editing app whereby you can easily swap it out for some
alternative; whomever has committed to Rez has gone all-in and staked
*all* of a companies software-assets on its continued survival.
If so, we need to set course for a future where this is less likely to
happen again (e.g. #634 <#634>)
and either (a) increment the major version or (b) consider starting anew.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSUYW4ISKJWPSYWSQV3PYOK57ANCNFSM4HOJOBMQ>
.
|
|
Hey guys, so here are my thoughts on the last couple of messages (and hope my answers will be clear and not too unordered. It's getting hard to comment with these quite big comments). I agree with almost everything that @nerdvegas said in #630 (comment). Especially with:
Stability is extremely important for open source projects. I would even go one step further and say that the general line of thought of a project is also really important and needs to be kept as much as possible. In other words, if we let everyone merge what they want, the project will just become a big pile of features that do not work well together and that might not have a common vision. Talking about stability, if rez becomes too unstable, we won't be able to do any progress. A really good recent example in the open source is pipenv. Pipenv didn't see a release in over a year. One of the reason is it's stability. The maintainers had to deal with a lot of instabilities (in pipenv itself and in their dependencies (setuptools, pip, and the other 80 dependencies)). So they had to stop the development of new features and focus on stability. (Note that this is a brief overview and it won't represent the entire/real story of why they didn't release in over a year as the real answer is way too long to write in what will be a way too long post of my own in here) From Allan:
I can't agree more (as I've already stated earlier). From Allan:
That too I agree. And I re-iterate that I'm willing to work on the new features like having a shared repository, localization, DB repos, refactoring, etc. But I'm also looking at rewriting the test suites too. Or working on the installer. From @mottosso :
@mottosso And here I agree too :) ! I think the compromises is what Allan is trying to do right now. And to me is proposition is a good first step. Note the word first. I don't think we would be able to come up with something that is perfect the first time. From @mottosso :
From what I see, extensive users want stability yes, but they also want progress (and quite a lot). New users will probably want stability first and then progress. Because if you start using rez and it's unstable, it's highly possible you will ditch it away. Though your 2 points also represents the audience too. As for the beta proposition you are making @mottosso, I think it makes sense, but only if we had 100% (or almost) test coverage (unit and integration and behavior). Though we can still have a beta branch that studios can try. Also from @mottosso :
This is why projects have maintainers. Maintainers exists for this really particular reason. And it's what differentiate them from contributors.
As I just said, this could be solved by having more maintainers that shares knowledge. But I don't agree that this problem would prohibit someone from contributing. It's normal that not all contributions will have the same level of difficulty. Normally the core parts of a project (in a package manager we have solvers) will be well protected and won't be touched by a lot of people, due to their complexity and implications. This is fortunately a solvable problem. Documentation of the internals is normally a good first step into solving this problem. A good contribution guide can also help quite a lot. A complete test suite is also fundamental as you say below.
Yes tests will help a lot into removing fears of breakage, but someone or multiple people still have to sit and think about the changes and how well they will fit with any future work or how well it fits with the general philosophy of the project. So the "take the time to fully grasp the contents of the PR and implications of the PR into the greater whole" part cannot be removed of the PR process.
This is effectively something that came up a couple of times, from time to time. I already showed my interest in helping getting a complete rewrite, and so for @lambdaclan. Though as Allan said, that would mean no new features for a quite long period of time, and probably find some money to pay the people that would work on this. As for issue #634, I think we need to do quite a lot of cleaning before really starting to expose a specific set of the API as being public. Without going into a full rewrite, we can rewrite/refactor parts of rez while developing new features, and while doing this, determine what is to be exposed and how. At least that's how I see things. To be discusses in the issue itself I guess. All in all, I'm happy to see these conversations going :) |
To clarify, I'm not suggesting we throw anything away. What I meant was (a) increment the major version, and thus allow for breakage and new features or (b) fork Rez, call it Tez and more forwards. Either way, we maintain momentum without sacrificing stability. Best of both worlds! But again, this only applies if Rez really has over-matured, which I don't think it has. |
No one wants rez to be unstable. Thousands of open source projects manage to function with multiple maintainers and their projects don't fall apart. In fact, I'd venture to say that nearly every successful open source project has multiple people responsible for maintaining them. Also, if the flipside to "stability" is that a significant portion of your users have to work out of their own forks, in production, that's not healthy for the project either. from @mottosso @JeanChristopheMorinPerso
I think we really need to commit to deciding what changes we want, and making sure they get pushed to master. If a change isn't good enough to go to master, it really shouldn't be going into beta either. I just don't want to get into a situation where we're deferring decisions and instead just merging things to beta until it diverges so much from master that it can't really ever be merged. But it brings up a good point, which is that adding maintainers without also granting merge access to master doesn't really solve our problem. It might be more convenient to work out of the same repo instead of trying to manage a half dozen different remotes, but functionally, it doesn't change anything about PR's. Unless something else changes, we're going to be in the exact same boat a week from now. @nerdvegas I understand the desire to introduce these workflow changes slowly instead of all at once. That makes sense. But I don't want to have this same discussion every other week. These workflow changes are only going to work if you're the one championing them and moving them forward. |
|
Hello everyone, compulsory this is my opinion statement, you are free to agree or disagree with it, not trying to impose anything on anyone I am happy to see the discussion picking up stream. I am sure at end of the day everybody wants the same outcome, keep improving rez for all its users (stable and bleeding edge), expand its userbase and ultimately attract more contributors and increase the potential pool of maintainers. Overall I am in line with JC as commented here but I would like to offer a broader view of looking at things to make you all consider a few other important points. I see a lot of people requesting more maintainers (which I am also in favour of if done appropriately), putting themselves down for it but let us not forget that a maintainer is not only responsible for merging pull requests or putting tags on issues. Also there should be more emphasis about who becomes a maintainer and why, becoming a maintainer should take effort and not happen just because of dire repo situation. Do they have the time and skills necessary to do so? Keep in mind programming skill is not the main skill required albeit an important one. Communication is key. I would like to point you all to a very nice article about managing open source projects written by someone (developer of swaywm a linux window manager and sourcehut an alternative to Github) who through successful management of a FOSS projects has managed to gain enough support to do it full time so I am assuming he is doing something right. I highly recommend you give it a read. There are far bigger projects than rez with thousands of open issues and countless PRs that manage perfectly fine to maintain a healthy release schedule adding stability and new features for all users without multiple forks syncing with each other. It is all done on a single central repository. How is that possible? Call me old school but as JC put it
There needs to be a plan, there needs to be a roadmap, there needs to be a scope, there needs to be order in the repository and the community as a whole. For example Problem: Allan
Marcus
Answer: Is Windows support in scope? Is it in the roadmap? Is it a frequently requested feature that Without a roadmap, plan or a scope is hard to come up to a conclusion, anyone is free to walk in as a contributor and request a feature to be added to master, it is tested, maintains backwards compatibility and the code is good. What do we do? Accept it? Reject it? What do we base that decision on? If we accept anything regardless of how good it is there will be mayhem. The project needs to stick to its plan decided by the maintainers anything else goes into the consideration list. Now if you want a feature that is not in scope or in the roadmap then fork is the way to go. There needs to be some limitations and constraints otherwise rez will diverge from its main purpose. Having a roadmap will make it immediately apparent to prospective contributors what can be potentially merged to master before working on it. This requires an open mind from both the maintainers to listen to what the person requesting/ offering a feature PR has to say and the contributor to accept and respect the maintainers decision to comply or not comply. An example from pyenv: Issue: Windows Support
There is no vision right now apart the one in our heads, everything is go which is why we see this happening. What I am trying to say is that handling an open source project is much more than coding, there needs to be clear communication between the community members, an understanding of the overall goals of the project and unison amongst the maintainers in order to "maintain" order and keep the project moving forwards. From Brendan
Agreed, most importantly:
Plan, roadmap, scope please. From JC
Agreed 100% and very close to what the linked article above boils to. An open source project, or in fact any software project cannot please everyone or meet every studios needs. It is virtually impossible. There bounds to be a specific requirement that will be so closely related to an internal workflow which does not make sense to be part of rez. rez has allowed multiple studios to achieve amazing things in terms of automation and that is great but if at one point a studio needs to diverge then is perfectly fine, this is how new projects are being born and many times later merged again or continue on as individual projects to meet the needs of two distinct markets. Someone needs to decide where that line is. From Brendan:
This is what I would call a diverge, doing so is not problem but we should not expect anything in that If we are going to create branches then I propose:
From Brendan
The highlights speak for themselves. The state of the repository is very important as a first impression for a new contributor. That needs improvement as well.
Most importantly a healthy and friendly community striving to make the application better by working towards a common goal and encourage people to get involved. I am all up for discussions to keep going but sooner than later we will need to take some action as well for the benefit of the project. First important step to achieve this, as stated from Allan
👍 -- Ira |
|
I'd be interested to hear @instinct-vfx opinion on all of this. |
|
Rest assured that i am following this discussion. There is a LOT being written and it is getting hard to properly answer all the points. With some internal Rez milestones this week and a lot of personal stuff happening i am a bit constrained this week. So i will just talk to a few things that i consider very important.
In conclusion i would once again like to repeat and stress that the project needs a vision and a scope. What does Rez do and what does it NOT do (even more importantly). What are the core concepts and principles Rez wants to maintain? What are supported platforms and environments? etc. I think based on that it also gets easier to answer other questions like "Rewrite or not" ;) As a side-note: I think that making more things plugin-based may help as it allows more things to be done in a custom way without polluting the core. It can also be a curse though with everyone running their own flavour of the WSL integration and causing ticket influx. In the end i would like to say that i really do welcome seeing this discussion happening and also see it happen in a constructive way. Keep it coming! |
|
I also think a roadmap is important, and I'm going to prioritise getting
that done soon. Watch this space (or rather, wiki).
I'm going to get through a couple of tickets now, and there'll be some more
activity tomorrow.
Thx
A
…On Mon, Jun 3, 2019 at 5:12 PM Thorsten Kaufmann ***@***.***> wrote:
Rest assured that i am following this discussion. There is a LOT being
written and it is getting hard to properly answer all the points. With some
internal Rez milestones this week and a lot of personal stuff happening i
am a bit constrained this week. So i will just talk to a few things that i
consider very important.
-
While it seems "easy enough" to give people merge permissions there
are a lot of pitfalls and as Allan noted above it can be very tricky to
oversee the potential side-effects of changes, or even more importantly
when you are implementing "against" some of the core principles of Rez. I
am guilty of that many times and i was really happy to get Feedback from
Allan in these cases. As much as i am frustrated by some PRs being stale
for longer periods of time (and the work this creates to update them to
master again etc.) i still see quite a bit of a risk there. I kind of like
the idea of having a sign-off and others doing the actual merge work etc.
as a first step. In the long run? I don't know, maybe Rez needs a BDFL?
-
I am rather strongly opposing forking in a way that was described
here. Because even if not intended this will diverge away quickly and we'd
end up with contesting code bases. I have seen that both out in the public
and even internally (with quite some care being taken heh). Also see my
first point. As the fork(s) would lack Allan's input i am pretty sure
they'd reach a state that is in conflict with upstream master rather sooner
than later.
-
I am agree violently that the project needs a vision, a roadmap and
planning. Also some more in-depth guardrails would help to get more people
up to a point where they can better judge the impact of PRs etc. Things
like "Complete encapsulation of Rez's env and the envs it provides" etc.
should be available in written form and be part of the developers guide. (I
may be missing that that exists even? If so it ain't visible enough ;) ).
Some random points here:
-
The github issues are perfectly fine for task planning besides just
bug tracking i think. No need to go elsewhere (at least to start with).
-
Github issues can also be used for release planning and roadmapping to
some extent (see bigger projects like the vscode project for example. They
currently have nearly 5500 OPEN issues and yet manage good pace and monthly
releases.
-
Speaking of monthly releases: I really like these (gitlab does that,
vscode does that). It does not have to be monthly, but having a release
schedule also helps to plan features and fixes into these releases and
bring predictability.
-
Managing issues and grooming them, labling them etc. is a lot of work
in itself and something that can be done by active contributors right away
i'd guess?
-
WRT a rewrite. Tempting. A full rewrite is always a tempting thing
getting more and more tempting the older a code-base gets. But it is also
quite a risk and quite an effort, even with funding and resources. Remember
XSI 1.0? ;) That said i am not in opposition here, just needs a lot of
careful planning to make sure we're not abandoning 2.x without creating 3.x
-
As mentioned above, proper tests and test coverage would ease my mind.
Setting up CI would help there. (There is a workstream in ASWF currently on
CI, maybe their best practices can help).
In conclusion i would once again like to repeat and stress that the
project needs a vision and a scope. What does Rez do and what does it NOT
do (even more importantly). What are the core concepts and principles Rez
wants to maintain? What are supported platforms and environments? etc.
I think based on that it also gets easier to answer other questions like
"Rewrite or not" ;)
As a side-note: I think that making more things plugin-based may help as
it allows more things to be done in a custom way without polluting the
core. It can also be a curse though with everyone running their own flavour
of the WSL integration and causing ticket influx.
In the end i would like to say that i really do welcome seeing this
discussion happening and also see it happen in a constructive way. Keep it
coming!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSU45GBJR57JEMC3TILPYS74JANCNFSM4HOJOBMQ>
.
|
|
@nerdvegas Saw this on #629, but wanted to comment here
I think this should be possible by making
And then adding a CODEOWNERS in master and making yourself the default code owner for all files. Then you could selectively grant merge rights to portions of the repo by adding other code owners for different files and directories. |
|
Oh, good find. I didn't drill down that far, but curiously this suggestion
didn't come up after doing some googling either. I'll sort this out soon.
Wrt collaborators. I'm still looking into what the best approach is. Like
any OSS project, opening collaboration directly to master for all new
developers would not be a good idea. Don't think of this like me
considering giving you that access - think of it in general terms, ie how
do the collaborators of this project want to control access to new members,
moving forward? How we determine who becomes a collaborator and when should
be a known process that we all understand from day one. I would like to
avoid a situation where I'm arbitrarily choosing who has what access - I
think it would be better for everyone if that process is objective. This is
what I'm looking into and getting advice on at the moment.
Cheers
A
…On Fri, Jun 7, 2019 at 3:38 AM Brendan Abel ***@***.***> wrote:
@nerdvegas <https://github.com/nerdvegas> Saw this on #629
<#629>, but wanted to comment here
Been looking into permissions. Unfortunately it isn't possible to restrict
access to master in personal GH repos
I think this should be possible by making master a protected branch and
checking the "Require pull request reviews before merging" and "Require
review from Code Owners" options
[image: image]
<https://user-images.githubusercontent.com/622914/59053407-3e8c9680-8846-11e9-85e9-9e892e063b19.png>
And then adding a CODEOWNERS
<https://help.github.com/en/articles/about-code-owners#example-of-a-codeowners-file>
in master and making yourself the default code owner for all files.
* @nerdvegas
Then you could selectively grant merge rights to portions of the repo by
adding other code owners for different files and directories.
/src/rezplugins/ @bpabel
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSULRF2ICB2NBOS57EDPZFDS3ANCNFSM4HOJOBMQ>
.
|
Quoted for agreement! |
|
Hi all, I've enjoyed this topic and others like it, but I've been informed that my PRs and issues take up too much of Allan's time, so much so that they negatively affect his ability to develop his roadmap. So I'll take my leave and divert attention to the bleeding-rez project instead. Best case, progress made there can help inspire and push progress here (no point pushing in parallel). Worst case it's a fork on a different path (no point pulling from both directions). Neither of which is all that bad, both of which means progress. Have a good weekend! :) |
|
That's unfortunate, but it's a free world. However, I think this
misrepresents what I actually said.
Excerpt follows:
*[AJ] Well, I think rather than spreading our time over a lot of threads,
we should spend more time on the ones with traction, and get things done,
then revisit things that don't have consensus yet. There's a finite amount
of time to do things, right now I feel like we're making slow progress. I
have an hour or two, 5ish days a week so I literally can't spend it on long
threads all the time - if it's a long back and forth then that can be two
days gone, then perhaps the PR/issue gets closed and I've not made any
progress. *
*I don't mean it as a criticism that you're communicating too much per se,
more that I just need to have a way to get things done within a finite
amount of time. Typically I'd be doing development myself to ensure
progress is being made, but I'm trying to move to a place where I'm not
doing so much development, in order to keep checkins going faster. But I
currently find myself in a catch-22 where there's not much progress.*
*So, for example right now there's good work being done in 3 different PRs
(installer, preprocessor-defined-in-config and request-iterator-in-rex).
Two of those haven't had any input for some time now - so I think it's a
good example of where we can concentrate more effort (one is also holding
up another developer). Then things are getting done and I can spend more
time merging older PRs, responding to the longer conversations, and
developing (sometimes maybe! There's some interesting meaty problems to
solve).*
A
…On Sat, Jun 22, 2019 at 5:06 AM Marcus Ottosson ***@***.***> wrote:
Hi all,
I've enjoyed this topic and others like it, but I've been informed that my
PRs and issues take up too much of Allan's time, so much so that they
negatively affect his ability to develop his roadmap. So I'll take my leave
and divert attention to the bleeding-rez
<https://github.com/mottosso/bleeding-rez> project instead.
Best case, progress made there can help inspire and push progress here (no
point pushing in parallel). Worst case it's a fork on a different path (no
point pulling from both directions). Neither of which is all that bad, both
of which means progress. Have a good weekend! :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#630>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSQGGDVGWKFHE7EHPKLP3URDJANCNFSM4HOJOBMQ>
.
|
|
A bit sad to come back to this thread only to realise that there has been a hard fork of Rez. Feels like wasted energy to me, instead of having a single repository we essentially now have two competing ones. @mottosso : I haven't followed precisely the changes you made in bleeding-rez but are you at a point where the codebases deviated so much that they cannot be reconciled and merged together? |
Hey @KelSolaar, I think it isn't as much about whether it's possible, but about whether it's wanted. Generally, I'm less interested in the 100 studios using Rez as I am in the 100,000 studios not using it; that is, I'm pushing towards lowering the barrier of adoption and making it useful to a widget audience. That involves using Rez for project configurations, the simplified installation method ( I wouldn't say one is better, but that the two projects address different requirements.
And as someone not bound by any particular studio, I'm also able to provide dedicated support to those on a deadline, feel free to get in touch. |
Hi all, @nerdvegas in particular!
I just wanted to put a finger on the pulse for a second with regards to future development and pull-requests in particular; I've noticed a number of useful features that were agreed upon but never actually merged, like #355 and #597, some of which are years old, others weeks to months.
This isn't a critique! We all get busy and open source is often a labour of love with little to no accountability.
The issue however with leaving PRs for too long is that users start using their own forks in place of master, like Luma and mackievision, or worse yet limit themselves to a stale version. The benefit of having all PRs be blessed by a single maintainer can be consistency, but comes at a cost. Case in point, because I have so many unmerged feature branches, it prevents me from continuing development until these have been merged, else be forced to submit a "mega-PR" like the one for Python 3 support, #589.
You're lucky enough to have a pool of active contributors here, I would recommend assigning more responsibilities to one or more and take a more hands-off approach to development.
What I expect you'll find is a project that encourages growth, and takes some of the stress off from your end. In my experience, I've found that it's fine to let contributors break a build, even break a release; that's what versioning is for. So long as it's versioned, the end-user can choose to upgrade and roll-back at will.
There's benefit to letting contributors break a release; it gives them ownership and can make one feel part of a project. I've had my projects broken many times, only to be quickly rectified by the original developer, the developer having gained ownership and learnt a valuable lesson on backwards compatibility; with little to no cost to the end-user.
Now on the other hand, if this repository isn't your normal open source project, and is instead coupled with your particular studio and your studio has requirements that limit where the project is able to go - then that is useful information too. In that case, I would recommend going the Red Hat route of splitting the project into two; Red Hat and Fedora, for "coorporate" and "experimental". Where you let one grow unbounded, and merge features that work over a longer period of time into the other.
Another and perhaps more sensible option, if the studio really is an outlier, perhaps Rez should be open source, and the studio would maintain its own fork.
If possible, it would be great to see a 1-2 year plan of where you personally see things going, and what we could do to help.
Food for thought, let me know what you think!
Best,
Marcus
The text was updated successfully, but these errors were encountered: