On Tue, 28 May 2013 16:02:17 -0400
Rahul Sundaram <metherid(a)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.
I suppose.
> 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
https://fedoraproject.org/wiki/Fails_to_build_from_source
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
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
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.
kevin