Page MenuHomeSolus

RFC: Making Contributing to Solus Even Easier
Closed, ResolvedPublic

Description

Okay, how do I start... Solus is a great project and I love working on/with/for it. I learned a lot about compiling and packaging and as such I want to give back by maintaining a few packages and fixing minor problems.
But I'm a bit tired of sitting in IRC to ask "PersonXYZ: Can you please commit this?" so maybe this is T2616 part 2.

Phabricator has limited abilities but as we keep growing there will be more and more patch submissions. Ideally you could name more maintainers that can commit themselves, but that needs a lot of trust (and knowledge to fix broken updates). I was thinking about some categories like "just a minor patch, please commit asap" (e.g. PHP 7.2.x), "big update, maybe with breaking changes, request for comments and tests" (e.g. PHP 7.1 -> PHP 7.2) and "initial inclusion, please check for mistakes". On the other hand this would add even more bureaucracy.

To make it a bit more concrete:

  • D1582 is important for (mostly German) users to have a working VPN to their router. The SVN solution is dirty, I get that. Ikey wanted to check it out and upload it as a tarball himself, but it failed and wasn't touched since.
  • D2983 is a small patch that was tested with two OpenVPN configs and worked fine. I asked a few times in IRC, but nobody reacted.
  • Hotspots are on the Solus 4 tasklist, so I packaged D2878 and tried to start a discussion about what hotspot-integration should finally look like, but there was no response.
  • PostgreSQL 10 has been out for a while, but upgrading databases from 9.6 to 10 needs old and new binaries. So what do we do? A postgresql-10 package? Where to discuss this? With who? If it's not important right now, then what is?

An alternative could be a current roadmap to see what's being worked on and what's important in the near future. Haskell stack and kernel upgrade? Okay, I won't bother you. Software xyz needs an update? I'll be happy to help. Software xyz is already maintained by Person xyz? Sorry, that wasn't noted anywhere and I just wanted to help.
Maybe it's a lack of coordination? We are not enough to have permanent maintainers for every package but are too many without fixed responsibilities, so some work is done twice or thrice. Maybe it's just me and everyone else is happy.

I'd be happy if @ikey, @JoshStrobl and others like @kyrios123 (or everyone else) would find some time to comment.

Event Timeline

cigh033 added a subscriber: cigh033.Jun 5 2018, 2:55 PM

I can't really say much because my experience in such topic is extremely limited, but I want to make my 2 cents worth something: I agree that often packages await for inclusion for a long time, even if the diff isn't that "deep" (like for a minor release). Revision process should be speeded up.

It is not really a problem to have to wait for a patch to be committed. I think IRC is a mandatory place for packagers. When for some reasons you want a patch to be committed immediately you must explain why and check if there are not conflicts with others on-going activities like a stack update or a kernel rollback. The way of asking things on IRC does matters. If you ask something when everyone in the core team is away/busy you request will most likely be lost in the flow. Every week before the sync ikey asks if there are still things that should get in. This is, imo, a good time for requesting such things. If the impact is big, you can cancel announce it in advance. This is what I usually do and it works fine.

This still works quite well atm but it is true that this way of working can only work with a small community of contributors.

I think the idea is to have some packages with dedicated packagers who may perform direct commits on the packages they are responsible for (depending on the ABI impact of course)

DataDrake triaged this task as Wishlist priority.Oct 16 2018, 8:32 PM
DataDrake added a subscriber: DataDrake.

Marking as Wishlist because that is what this is, not because I think it is low priority.

DataDrake closed this task as Resolved.Sep 26 2019, 3:01 AM
DataDrake claimed this task.

I think we've gotten a lot better about this process stuff in the past 6 months. Any software-specific issues should be separately reported.