Repurpose the Build and Packaging Working group

[ferd]

Background

Engagement in the working group monthly meetings has been going down continuously for the better part of a year.

We suppose that this is part of an overall drop following Covid and OSS, but also a question of stability. As we revisited our charter and mission statement at https://erlef.org/wg/build-and-packaging, we noticed that most objectives were hit and successful, and that it's possible the working group mostly activates only in case of need, acting as a point of contact rather than an active ongoing effort.

Tasks

We want to be able to rework the working group:

• What is the frequency we want to meet if at all
• What is our updated mission statement
• What are going to be our new objectives
• Is disbanding an acceptable option?

Ideally, we'd have this done before the end of the year.

Related agenda items, issues, and pull requests.

• Meeting where this was discussed https://github.com/erlef/build-and-packaging-wg/blob/master/minutes/2022-11-01.md

[tsloughter]

I'd disagree that the objectives have been met. I believe using Elixir from Erlang is again not working well, but haven't had time myself to resolve the issues in the plugin Supersonido/rebar_mix#29

For hex packaging there is a lot of work for rebar3_hex and it has all fallen on @starbelly. He's done an admirable job, but is only one man! :)

Packaging for deployment could still use a lot of improvement in documentation at least. Some of that I consider stuff like Adopting Erlang, but I haven't had time to work on that either.

I think packaging of Erlang itself still needs work to offer automated binary builds that can be downloaded and unpacked/run anywhere? I know the work in Erlang itself was done to make this possible, but the automation for publishing releases I don't think has been -- I still mainly want this so erlup can just pull a pre-built tarball in most cases :)

I'll think of more... That was really all Erlang based stuff, I'm sure there are at least Elixir issues still around deployment if nothing else.

This isn't to say the WG should continue meeting at its current pace, if the engagement isn't there then there is no point, I just don't think the WG can be redefined with new objectives.

[josevalim]

Then we need to at least update the Short-term deliverables (or remove them) and update the Long term ones. :)

[starbelly]

I'd disagree that the objectives have been met. I believe using Elixir from Erlang is again not working well, but haven't had time myself to resolve the issues in the plugin Supersonido/rebar_mix#29

I agree with this and I myself haven't had the time either. It's still a huge speed bump IMO. OTOH, how many people are actually using elixir in erlang projects? I have some speculations about the true road block there, and it doesn't really have much to do with how well the support is and that it may be more about ergonomics, once again, speculation.

For hex packaging there is a lot of work for rebar3_hex and it has all fallen on @starbelly. He's done an admirable job, but is only one man! :)

This is true. I would also add there's work that has to be done in rebar first in order to progress in rebar3_hex in regards to organization support (see erlang/rebar3#2742)

As far as maintaining a package pipeline. While the parts are somewhat trivial, it's a lot of maintence and we don't have the volunteers (yet) to support this endeavor. This is the problem with a lot of things we'd like to see done I do believe. To be specific, I mean taking over what ESL is currently doing for the community. Getting it setup and the wheels turning is not a mountain, it's when something goes wrong, when the system breaks down is where I see problems coming into play and no one has time to fix any of it.

What is the frequency we want to meet if at all

All I can say is right now the current time doesn't work well for me, and the time I would pick doesn't work well for others. I think it's ok to revert to "async". I imagine it's no fun when one or two people keep showing up and no one else. You've carved out time for not.

What is our updated mission statement

This is hard and I can only say there's been something I've brought up a few times and I don't think we ever had consensus on it. What qualifies B&P scope? There's plenty of issues for mix, and plenty of issues for rebar3 (whether bugs or nice to haves, etc.), and other related B&P activities but does that qualify? Do those type of problems stay in their own zone so to speak? It seems like this group started off mostly with a focus on interop, and that has died down quite a bit (i.e., maybe there's not as much interop work left sans better mix support in rebar projects). Sometimes I'm not sure whether to bring an issue to the table or not because of this. erlang/rebar3#2742 is a good example of this I think. It feels right to track this in this group, but it's also rebar specific, it effects (seemingly) nothing else.

What are going to be our new objectives

I have to think about this more myself and hear back from some of you on the thought above before trying to throw out ideas.

Is disbanding an acceptable option?

It is acceptable, but maybe not warranted. I suppose the question is, is it harmful to keep working group that is not really busy atm around? Is it taxing on anyone? etc. From glancing at the python foundation there seems to be a lot of different working groups spun up, they die down, but they are never abandoned.

I also think how the last 6 months or year have been may not be a good basis to predict how things will be in a few months.

That said, it's quite easy to re-spin the group back up as well. I also, want to see what the comes out of the AGM this week and/or decisions made by the board around funding development.

[ferd]

Alright, so at least from the regulars it seems like people like the idea of keeping the group but at the very least there's a need to rework how we work, maybe update a few things. But I'm also partly concerned that we have only 4 of us even discussing this, out of the original 10+ members for the WG.

[lpil]

Hi friends! I have no particular opinions on what's best for the group but in the new year I'll be back to full time open source work so I'll be more active again then. :)

[starbelly]

Alright, so at least from the regulars it seems like people like the idea of keeping the group but at the very least there's a need to rework how we work, maybe update a few things. But I'm also partly concerned that we have only 4 of us even discussing this, out of the original 10+ members for the WG.

This seems normal though in terms of open source, no?

[ferd]

Yeah it might be. I think what could be interesting is doing a sort of "soft reset" -- in that we look at the charter for the WG, reboot the membership to active people, and re-focus on the current landscape of the ecosystem rather than just keeping on with the older stuff.

If that makes sense we can figure out how to structure this work, it shouldn't be extremely time consuming, but will help clarify purpose and methods such that it doesn't look like the group is dead and ready to be spun down by the board.

[josevalim]

Suggestion: let's start by floating around a poll for the time of the next meeting and in the meeting we discuss the new items and ask which of the participants want to join the recharter.

[ferd]

I'm even thinking of not having a meeting but having a sort of scheduled "async slack day" on the foundation slack in our channel, where any agenda item gets its own thread and we can all discuss them there, with the caveat that I'd have to gather and re-post notes to the minutes to this repo after the fact.

I don't know if that sounds like hot garbage to people but sure would make schedules simpler and invites more transparent.

[ankhers]

An async slack day may be a good idea for scheduling, but I think the tradeoff is that it may take longer than a day or two to "finish" some topics. I am not going to say it would be better or worse than the current meeting setup. Just different trade offs that need be be weighed.

If we do switch to a slack day, maybe it would make more sense for whoever brings up a given topic to post a final "this is what the discussion lead to" instead of Fred as the chair needing to summarize each topic.

With that said, my employer is willing to sponsor a couple days a month of my time towards this WF / the foundation in general.

[starbelly]

I can see myself about getting dedicated time, that surely would not be an issue, but what normally prevents me from attending any EEF related meetings is the unpredictable. I end up sounding like "Things will go back to normal now, and this time I mean it!" and in that regard, async slack makes sense. I value attending "in person meetings", but I do not like the thought of others carving out time and no one shows up.

Maybe we can start with async slack days and go from there. Maybe we have async slack days, and maybe sometimes enough people are around, we say "Let's just get on a call". Fluidity is valuable.

[ferd]

Trying async meetings for today's group at https://the-eef.slack.com/archives/CUQVCA5K8/p1670338485538259