On Mon, Jan 6, 2020 at 11:20 AM Matthew Miller <mattdm@fedoraproject.org> wrote:

Those are my thoughts. What other challenges and opportunities do you see,
and what would you like us to focus on?

The packaging process has changed a lot over the last couple of years (well, not the core fedpkg process) but I've been a packager for almost 12 years now (Where did the time go?!?!?) and here are some things that would help me.

Preface: I have a lot more packages but a lot less time than I did 12 years ago. Aging parents, kids, $DAYJOB, etc...

1. Make updating well behaved packages easier and/or more automated. 

I have a few upstreams that are very organized and they don't accidentally break API/ABI compatibility and I almost never need to patch anything. How about an option or build those when updated, but not a "scratch build" or a candidate build, but something in between that's gated before becoming a candidate with a report where I can easily see what changed (pkgdiff & abipkgdiff?) and then simply click a button if I want to create an update or throw it away.

2. I find the whole fedpkg, rpkg, copr-cli and their interaction between src.fedoraproject.org and pagure.io confusing.

Not only are the icons the same for the browser tab, but it seems like I'm constantly getting generic emails telling me my api token is about to expire and there's nothing in the email that differentiates the two sites, nor a link.

Also, because it's not done all THAT often (it just feels like it is) I never remember which file I have to plug the API token in!

Add to that one of them goes in .config/rpkg/fedpkg.conf which continues to blur the lines between rpkg and fedpkg. 

The other ones go in /etc which doesn't make any sense to me. Shouldn't API tokens be user specific and not machine specific?

Out of frustration I end up just pasting the key in the different files until the tool works...

Thanks,
Richard