On Tue, Jan 8, 2019 at 2:00 PM Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Tue, Jan 08, 2019 at 11:55:32AM -0500, Ben Rosser wrote:
> Sorry for the delay in responding here; I admit I wasn't thinking too
> much about Fedora over vacation...
> Thanks a lot for the feedback! I think it definitely makes sense to
> broaden the proposal to include more than just cleaning up after the
> pagure migration-- though I still think that's a good place to start,
> since it's something that happened relatively recently.
Welcome back, and thanks for reminding me to reply to this. First of all, I
really appreciate your proposal. I agree with the others that a larger scope
is appropriate for an objective (while at the same time, I'd like there to
be definite measurable expected results, too).
I'd like to see this include packager experience for our new packaging
technologies -- modularity, container images, flatpaks. Having tried to
modularize a traditional Fedora desktop application recently, I know for
sure that the packager experience is sub-optimal. The current Modularity
objective itself is at the end of its timeframe and it's possible that
instead of renewing that, those further improvments should be part of this
Sure, I think it makes sense for improvements to
container/flatpak/module packaging to fall under the scope of this
objective as well!
I admit that Modularity is part of my motivation for filing this
objective-- I'd like to make sure we keep the packager experience in
mind as the modularity rollout continues. My worry with modularity
(which I've expressed before on the devel list) has been that the
added overhead of creating and maintaining a module will end up
detracting from the other benefits of being able to modularize
stuff... so it would be nice to help make sure that doesn't happen!
Additionally, some people have been working on a "source
). Do you think that might be in
scope? There's a talk coming up on this at DevConf.cz:
This is an interesting idea! My initial thought was that the majority
of packages probably don't *need* something like this, as they don't
differ much, if at all, from upstream. But I think even for those
packages, being able to browse a package's sources through a git
repository via Pagure rather than having to fetch and unpack the
tarballs would be a major improvement. So yes, I think trying out
source-git would be something that could fall under the scope of this