Heads up; F22 will require applications to ship appdata to be listed in software center

[Kevin Fenzi]

On Thu, 23 Jan 2014 15:26:24 -0800
Adam Williamson <awilliam at redhat.com> wrote:

> Well, let's say it's certainly not 'low-hanging fruit' :)
> 
> I'm not saying I have all the answers, just suggesting a possibly more
> productive course. At least now we have people co-operatively
> discussing the possibilities and potential dangers of doing an
> *intelligent* pruning, rather than throwing crap at each other from
> entrenched positions about whether a *dumb* pruning is a good idea or
> not. I'd say that's an improvement.
> 
> If I was the one drawing up a proposal to do this, I'd start from the
> *easy* cases. The *hard* cases you can handle later, and it would
> obviously be perfectly reasonable to adopt a 'conservative' posture,
> where the default expectation is that packages will be kept, and there
> has to be a strong argument/consensus/whatever for throwing a package
> out.

Agreed. 

So, this is closely related to the non responsive package maintainer
process, which I think almost everyone agrees now is not very good. :( 

I think ideally any process around this should have at least two parts: 

a) an automated/scriptable part. 

In this part the script uses cold hard facts to look for possible
packages that are unloved or package maintainers that are not active. 
There's tons of data we have now with fedmsg. Sadly, we don't have
bugzilla in fedmsg, but we could scrape it directly. 
it generates a list that feeds to the next part. 

b) The generated list is examined by humans and action taken. 

Some things that are the list will be false positives. Try and adjust
the script to not generate them. 

As a bonus, the script could also possibly try and figure out components
that 'need help'...ie, lots of unanswered bugs or something. 

If someone wants to write up a concrete proposal around this, I think
that would be great. 

kevin
-------------- 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/20140123/af8146a0/attachment.sig>