Daily package ownership changes?

Kevin Fenzi 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.

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/Guidelines#File_Dependencies

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...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130529/ca131fef/attachment.sig>

More information about the devel mailing list