Daily package ownership changes?
kevin at scrye.com
Thu May 30 01:09:48 UTC 2013
On Tue, 28 May 2013 16:02:17 -0400
Rahul Sundaram <metherid at gmail.com> wrote:
> On 05/28/2013 03:17 PM, Kevin Fenzi wrote:
> > 5) update to new upstream versions in Rawhide - a tool could do bump
> > the spec, do scratch builds automatically of newer versions, if
> > that works ask the maintainer to apply a diff after reviewing the
> > changes. I suppose. It doesn't seem like it's that hard for a
> > maintainer to notice this and do that if thats all thats involved.
> It quickly adds up if you are (co-) maintaining dozens of packages
> which is not atypical in Fedora and it is fairly boring work that
> could be mostly automated freeing up time to fix bugs or whatever
> else that is more involved.
> > What items do you see needing in the web ui?
> I found a number of features in the old Fedora community UI really
> useful and the only reason I didn't continue using it because of the
> very slow UI. List of open bugs in all of the packages I maintain,
> the ability to see which package version is in which release across
> packages etc (ie) all the package maintainer specific views as
> opposed to package specific views that is in
> https://apps.fedoraproject.org/packages/. All of these could be done
> without the web UI but it is far more convenient to have a single
> location to get all the info necessary to maintain packages.
I don't think koji really is the right place for a lot of that. Sounds
like a offshoot of the packages app for maintainers perhaps.
> >> 11) automatic period rebuilds in rawhide to highlight FTBFS issues
> >> aren't done as often anymore
> > Can you expand on this? Not sure what you mean?
> What Matt Domsch was doing for
Ah, sure, yeah. FTBFS runs would be a great little project.
> > You mean, just that the file exists in repodata? Or?
> Make sure we are not abusing file dependencies when we could be
> depending on the packages directly. Essentially a way to ensure we
> are following
ok, packages that have dir/file requires outside the small set.
It seems like this could also be a QA check (There would need to be a
whitelist as well).
> Oh and one more thing, some process to keep track of un-upstreamed
> patches and making sure we do that on a regular basis will be
> useful. I have seen several packages in Fedora git which have
> unapplied patches still in the repo and that could be automatically
> checked and removed as well.
Perhaps a RFE on fedpkg... it could run 'fedpkg unused-patches' before
commit and note that they are there before doing the commit? Then
maintainers would see them and remember to remove them.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the devel