Fpm: Maintenance of FPM; Contributors needed?

[Skarlso]

Hi @jordansissel and @djhaskin987.

I would like to ask to see if anyone is still maintaining fpm? I did see that it's very time consuming to do so, but given the usage, the issue count and the PRs to go through it looks like FPM is still widely used and in need of a good overhaul.

I would like to volunteer as a tribute. I did take over https://github.com/joshbuddy/jsonpath so have a fairly good experience in these things.

What say you?
Cheers,
Skarlso.

[Skarlso]

Guess not.

[mathieu-aubin]

Let me remind you that some folks have lives and 2 days for such a request is on the low end of 'waiting for a reply'.

It sounds more like you cant wait for aknowledgement which is, well.. hrrmm.

Anyways, i guess i too like aknowledgement since i post on closed topics. To each his own

Best practice would be to propose instead of stating the obvious, dont you agree?

[Skarlso]

Propose what? Didn't I propose? :-)

And sure sure you have a life I have a life, however. Considering the size of this project, the open issues and the prs, best practice would be at least some kind of information as to the state of the matters and not just simply ignore people who are in need of assistance. Declare the project defunct so people can move on. Or seek assistance.

If I create something tájt is needed and relied upon thousands of people and if I get to a point where I no longer am able to maintain said thing, I at least make an effort to hand over said thing.

That said, emails can be missed, notifications can allude one self, sure. But in the end I think I just plain went back on my offer. Because I realised, I have a life too. :-)

[Skarlso]

Also, instead of dealing with all of this, I forked and fixed my problem and moved on. I would rather have given back to open source but I can see from many issues and conversations here that the maintainers are away a lot longer than two days.

[jordansissel]

Hi.

In many cases of fpm changes, I am not the best qualified to evaluate them.
I can advise on testing, code improvements, breaking changes, etc, but we
work together and do the best we can with the time we have.

2 days may feel like a long time, I hear you. There’s only so many hours in
the day, and it’s not a great outcome for anyone.

I rely heavily on others testing changes in order to understand the impact
of a change. Having access to the “merge” button is necessary but not
sufficient for maintaining fpm.

I’m open to helping bring this change into fpm, I haven’t had time or
energy this week to look into it. While I do read the emails, I may not
always have time or energy to respond.

If you don’t want to move forward with this change, I understand. If you’d
like it evaluated, reopening it is a good first step.

Thank you for trying to make fpm better for the community.

On Thu, Jul 18, 2019 at 8:29 PM Gergely Brautigam [e-mail]
wrote:

Also, instead of dealing with all of this, I forked and fixed my problem
and moved on. I would rather have given back to open source but I can see
from many issues and conversations here that the maintainers are away a lot
longer than two days.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jordansissel/fpm/issues/1653?email_source=notifications&email_token=AABAF2SVFL34RCSUMALD353QAEYITA5CNFSM4ID7V3QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2KO43Q#issuecomment-513076846,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABAF2XF7XS33PIRVOTEE6DQAEYITANCNFSM4ID7V3QA
.

[Skarlso]

@jordansissel Hey man!

So, I hear you brother. Maintaining an open source project is not easy, for sure. I maintain several and it is HARD. :)

And you are right that access to the merge button is not all. In fact, I would agree that it is the last thing important about here.

You are saying you need help with reviews, yet I don't see you engaging people to do so. I don't see any mention of this in the README or in a relevant document or in an ISSUE template saying to do so. You say the community has to help, yet I don't see the community being engaged at all. :) I see the IRC channel, but people moved on from IRC a long time ago ( I'm saying this while I maintain a bouncer and a level 89 IDLERPG character and still talk on IRC. :) ). But you need more people. Open a slack channel and configure integration with Pull Panda for example where people can claim reviews and tell people that they done reviews. :)

You need to enable your community to work for you. The tests need a lot of love. A lot of them are just broken and plain left there with travis saying foobar on every PR. This can't be done by the community, you have to take care of that or give someone the power to take care of it.

Fpm is full of broken windows that need to be fixed in order to enable the people to work with it better. :)

You can retain all the merge rights you want, but the rest of it needs to be done first so all you have to do is push a button once you trust your community enough to not mess things up a lot. :)

[Skarlso]

And for the record, I'm not doing this because "I want my changes merged now". No. I'm doing this because I like helping and I like giving back to something I used and enjoyed using. I don't care if my change gets rejected if it's a valid reason and there is a better solution for a certain problem.

[mathieu-aubin]

I like to see this re-opened and also with more details. Thanks and oh, no hard feelings

[Skarlso]

@mathieu-aubin hi. :) it is reopened... What more detail would you like me to add?

[rubyFeedback]

I myself have a project that has at the least a partial scope as fpm has (although my project is more of an incomplete package manager, a bit similar to homebrew but not as sophisticated, whereas fpm has a slightly different goal/focus e. g. distribution-agnostic packaging). I do not even use any issue tracker myself, though. The reason is - I could not keep up with any of this. I can not even keep up with emails. :-)

Open source projects are difficult. Time is limited for everyone.

I think what may help is to e. g. if you see some issue and don't have time, to refer to the code/patch that fixed an issue. At some later time it may be merged. That could help reduce entry barriers to a project.

[mathieu-aubin]

@Skarlso dont worry, i was already speaking at past tense. I wss happy to see the issue reopened and with more details. all is well

[jordansissel]

What do you think would help? Would having some kind of "How to contribute" guide help?

Ultimately, with most proposed changes (PRs), I go through a few stages:
1) Review the proposal, do I understand it? If I don't understand it, I need to seek understanding _or_ have confidence that someone else understands it.
2) Test the proposed change, does it work as described? Do I know how to try the feature?
3) Compatibility: Does it alter any other behaviors in FPM?
4) Does the existing test suite pass?
5) Does it add any new tests? Are these the right tests for this new change? Should there be additional tests added?
6) Do we need to update any documentation for this change? Are any new flags sufficiently documented?
7) Is there a changelog entry? Or, from the proposed change, is there enough information to be able to write a changelog entry when it comes time for release?
8) (least important, imo) Do a code review -- does anything look missing? any unsafe APIs being used? are there places where we could add/improve error handling?

I'd like everyone to feel empowered to perform any or all of the steps above. Functionally, if all[1] of the above are largely satisfied, then I'm content merging it.

[1] It's possible the above task list is incomplete.

[jordansissel]

One example, a big change adding snap support: https://github.com/jordansissel/fpm/pull/1490

1. I know that snap exists and some of what it aims to achieve. Adding snap support to FPM aligns with FPM's goal. 👍
2. I tested it and was able to create snaps. Any additional use of those snaps is beyond my expertise (I've never used snap) 👍
3. Did not appear that any compatibility changes were introduced. 👍
4. Existing suite looked ok 👍
5. New tests passed 👍
6. Documentation changes were missing (no new docs for snap on fpm.readthedocs.org). I accepted this as out of scope for the change (not a blocker). ❌ However, new flags seemed adequately documented 👍
7. No changelog entry included in PR (normal), but it was easy to write one as the release manager. 👍
8. Did a code review and didn't feel like anything significant needed changing. 👍

[Skarlso]

Right. So this is all fine. I'm not concerned about that process here. I'm concerned about giving the people a platform to communicate on, managing the community and giving a few more people some oversight.

Even in the form of github's project management flag that would be nice. Where people can pick a ticket and say alright I'll be looking into this.

This is all about enabling the community to move forward even without you being around or only being around to push the button. Make reviewers visible make them trackable and provide them the opportunity to be recognised for the hard work and time they put in.