where should rpm-ostree project live

[dustymabe]

I think this one is up to @cgwalters, but figured I'd start the conversation. Some options include:

• github.com/coreos org
• github.com/ostreedev
• leave it where it is (will want to move it eventually)
• new org?

[cgwalters]

It also goes right into coreos/rpm-ostree#405

[dustymabe]

It also goes right into coreos/rpm-ostree#405

would a potential rename dictate where (i.e. what toplevel org) we move the project?

[jlebon]

coreos/rpm-ostree sounds cool. Though given that rpm-ostree will still be heavily used in other contexts (e.g. Silverblue and IoT), I think I'm leaning more towards ostreedev/rpm-ostree? (We could also make it a new org, though rpm-ostree/rpm-ostree will be twice as painful if we ever do rename the project).

[dustymabe]

though rpm-ostree/rpm-ostree will be twice as painful if we ever do rename the project).

🤣

[ghost]

I discussed this with Colin face to face as well. It's a good time to revisit the name now. Alternatively, live with it and definitely plan not to rename from now on, then put it under its own organization. I am strongly against putting it under CoreOS due to the reasons @jlebon mentioned above.

[cgwalters]

I think I'm leaning more towards ostreedev/rpm-ostree

Mmmm. Not unreasonable but undercuts some the rationale behind having it be a separate org in the first place - the idea here is that e.g. Debian or OpenEmbedded or whatever should feel that as ostree upstream we'll make sure to consider their needs too. Whereas rpm-ostree was intended to be fairly opinionated - e.g. we don't even really try to support non-Fedora-derived content sets today. Having them in the same org is a little weird from that perspective - but I'm not opposed to it either.

How about coreos/coreos-img?

[dustymabe]

Mmmm. Not unreasonable but undercuts some the rationale behind having it be a separate org in the first place - the idea here is that e.g. Debian or OpenEmbedded or whatever should feel that as ostree upstream we'll make sure to consider their needs too. Whereas rpm-ostree was intended to be fairly opinionated - e.g. we don't even really try to support non-Fedora-derived content sets today. Having them in the same org is a little weird from that perspective - but I'm not opposed to it either.

I think it would only be unreasonable to have it in ostreedev if we would not accept something like deb-ostree(with all of the same customizations for debian) into ostreedev as well.

How about coreos/coreos-img?

I'd really like to not have the "coreos" word propagate into an infinite number of places like the atomic word did. I still don't see any good reason to rename rpm-ostree to something else. It's explicit and makes sense. Either way we should probably not have the re-naming discussion here and should probably keep that in coreos/rpm-ostree#405 right?

[cgwalters]

I am strongly against putting it under CoreOS due to the reasons @jlebon mentioned above.

To me, the organization denotes focus but doesn't imply exclusivity. If rpm-ostree were part of the coreos/ org, it doesn't mean it can't be used by Fedora IoT or whatever.

[dustymabe]

Honestly wherever we put it will probably be fine, but I do just want to make one point:

To me, the organization denotes focus

This may be a good enough reason for another project to make an uninformed decision to not use it. This might be a bad analogy, but if GNOME were under the Fedora organization on GitHub would it be as successful as it is today?

[cgwalters]

This might be a bad analogy,

Not sure it's bad, but I am not sure it's useful 😄 - the ways in which these things are different IMO rather outweigh any similarities.

Either way we should probably not have the re-naming discussion here

Everything that in issue so far pre-dated the merger. But I don't have a strong opinion on where the discussion lives, I added a new comment there.

[dustymabe]

Moving this conversation along. Is it accurate to say these are the two frontrunners?

• github.com/coreos org
• github.com/ostreedev

Maybe we have colin and jonathan (the two main contributors to rpm-ostree) to decide since they have the most invested in the project. Alternatively, if colin and jonathan want other input we can vote in the ticket.

Are there other options, other than the above two that are in the running?

[jlebon]

Added some thoughts there: coreos/rpm-ostree#405 (comment).

Are there other options, other than the above two that are in the running?

If we definitely decide not to rename, then github.com/rpm-ostree/rpm-ostree ?

[dustymabe]

so options are:

• github.com/coreos org
• github.com/ostreedev org
• github.com/rpm-ostree org

??

Another question.. Does it make a lot of sense to have ostree not with rpm-ostree ?

[cgwalters]

There's also https://github.com/rpm-software-management/

[cgwalters]

Does it make a lot of sense to have ostree not with rpm-ostree ?

IMO, yes since ostree is used by other projects and I don't want to create the impression that RPM is required by ostree. I would prefer to keep ostree where it is for now.

[jlebon]

(Just as a precaution against name squatting, I created https://github.com/rpm-ostree. If we decide to not put it there, I'll delete it.)

[jlebon]

There's also https://github.com/rpm-software-management/

Ahh, good one. Of the already existing orgs, that's probably the most appropriate one since being RPM-based is definitely the one property of rpm-ostree that will not change. :) We'll have "rpm" twice in the repo URL, so no one can say we're not RPM based! And rpm-ostree also has strong ties to many of the other projects there. My only minor/bikeshed gripe is that it's wordy, but meh.

So now, I'm leaning more towards one of those two:

• github.com/rpm-ostree
• github.com/rpm-software-management

[dustymabe]

my votes:

• top choice: github.com/ostreedev
• 2nd choice: github.com/rpm-software-management (if they'll have us)

[LorbusChris]

I like github.com/rpm-software-management/rpm-ostree best

[LorbusChris]

This encompasses coreos/rpm-ostree#405

[cgwalters]

github.com/rpm-ostree

A new org just for it? I dunno, feels like overhead.

I like github.com/rpm-software-management/rpm-ostree best

I lean towards this, let's ask them.

[dustymabe]

@jlebon has volunteered to ask the rpm-software-management github org about the move

[cgwalters]

Although I think we kind of dropped the github.com/coreos option without really working through it. @sanjabonic I am trying to understand #19 (comment) more - it's similar to the Ignition case for example. I can imagine some IoT use cases (or potentially even Silverblue-style ones) wanting to use Ignition, we wouldn't tell them no right? (Although it could get weird if e.g. Ignition started learning about desktop-specific things, like how kickstart has a bit of that)

[jlebon]

Got a response that rpm-software-management would have no problem with rpm-ostree moving there.

it's similar to the Ignition case for example. I can imagine some IoT use cases (or potentially even Silverblue-style ones) wanting to use Ignition, we wouldn't tell them no right?

Yeah, that's true. Though rpm-ostree is today already pretty focused on supporting both Silverblue and AH/*COS. E.g. there's a lot of UX stuff we've worked on recently that really only benefits the Silverblue use case. That said, at this point, I'd be cool with either coreos/rpm-ostree or rpm-software-management/rpm-ostree. I completely agree that being under coreos/ in no way implies we're unfriendly to other use cases. (E.g. etcd was there for a while before finally moving to etcd-io/, right?). It's really just a URL string detail in the end. (And much less consequential than the actual project name, discussed in coreos/rpm-ostree#405. Though they're of course related).

[cgwalters]

Got a response that rpm-software-management would have no problem with rpm-ostree moving there.

OK, let's do that then if there is no one opposed!

[cgwalters]

I know this is going to suck but I keep having second thoughts on this...the thing is rpm-ostree straddles two entirely different worlds. On one hand we do want to integrate with the RPM ecosystem - that's not going away. On the other side...Container Linux IMO is popular because a lot of admins don't want to think about packaging. They like the "image based" background updates - it's a very different thing from owning/managing a traditional yum/apt style system.

In the future I'd really like to strengthen rpm-ostree's connection to not-RPM as well - things like this idea. And here's related food for thought - if there's some software we don't care about shipping in traditional systems, nothing stops us from e.g. building binaries in container images and then converting that to an ostree ref to inject into rpm-ostree. If we don't care for example about supporting Ignition on traditional RPM based systems we could just build it in a Dockerfile or whatever.

That doesn't mean we shouldn't be in the rpm-software-management organization. But I think it is clear that rpm-ostree isn't just about that.

[cgwalters]

Since my previous comment, we now support non-RPM content on the compose side, and I do plan to extend that to the client side as noted. For example, I want to make it easy and convenient to layer a git repository (would work best for noarch content).

Further, one way I often explain the new "CoreOS" is a pairing of (Ignition, ostree) and while I know in FCOS land we have a lot of tension around to what degree we support layered packages etc - I think rpm-ostree would work best in the coreos/ github organization.

I am working on CI related things, specifically integrating with OpenShift Prow. I think things will be cleaner if it's in the coreos/ org.

Any opposition?

[dustymabe]

we now support non-RPM content on the compose side

Yeah I just hit this the other day when I was trying to find out where a file came from on the filesystem and no rpm owned it. It would be nice if we have an equivalent to rpm -qf inside of rpm-ostree that would give us user friendly meaningful infrormation about where the file came from. Maybe I should open an RFE?

I think things will be cleaner if it's in the coreos/ org.

I still think it would make since to put it in ostreedev, but you have the most say and the greatest context to know where to put it so coreos org sounds good to me.

[cgwalters]

Yeah I just hit this the other day when I was trying to find out where a file came from on the filesystem and no rpm owned it.

Right. I actually hit this all of the time when I do podman run -ti somecontainerimage - I want to know "where did the layered container put its stuff". I don't even know if there's a convenient CLI way to browse the layers.

I can tell you that having rpm -qf do something else will depend on coreos/rpm-ostree#1789

[dustymabe]

I can tell you that having rpm -qf do something else

I'm even looking for a precursor to that next step of having rpm -qf do something else. If there was the equivalent of an rpm-ostree -qf I think that would suffice for now.

[jlebon]

No strong opinion here on which org to move to, so coreos/ SGTM if it provides real value in org/CI management. We can always move it again in the future if the winds of change blow us elsewhere.

[cgwalters]

It is done: https://github.com/coreos/rpm-ostree

Closing this for now.