Robert Scheck wrote:
>* Identify all modules that have a newer version available in CPAN.
>Would be nice if we had a script to compare a devel CVS checkout to CPAN
>and output a list with URLs or something.
>
>Contributors like Ville, Robert and Jose have been very helpful in
>submitting good spec rewrites for perl packages in the past. So I hope
>the community can help with cleaned up spec unidiffs (along with version
>upgrades) to be submitted to Bugzilla, one report per package. Perhaps
>discuss here who will do which package. I'll do some myself.
As of today, many perl packages have duplicate reports named differently.
Maybe we can open something like a tracker bug for the corresponding
perl packages and add the different/similar wishes, duplicates etc to them
for having a better overview what's to do for which package?
I don't know if a tracker would be the best idea. The key goal I think
we need here is to form a Fedora perl team, who receives notification of
all perl bugs and makes decisions about perl* package changes. If a
tracker would be the best way to do this, then fine.
Another option would be auto-CC in Bugzilla, where I can specify people
who should automatically be added CC to certain components. I can put
Fedora perl team members in here. I would prefer this. Thoughts?
* We should run "make test" at every package (if available of course) and
non-conditional - if it fails, something is wrong.
This would be acceptable only if those tests NEVER TOUCH THE NETWORK.
It is completely unnacceptable for rpmbuild to use the network.
There are other possible dangers in enabling "make test", some of which
were discusssed on this list in the "Regression testing" thread. For
now DO NOT enable this until we discuss this a lot more.
* Most perl packages are named perl-Foo-Bar and the CPAN "realname" is
Foo-Bar, we shouldn't define a separate variable for this as some
packages currently do, normally, the CPAN name is only needed at setup -q
-n Foo-Bar-%{version}. Macrofying is generally okay, but we're not
generating tons of spec files like DAG or so.
I really don't care about this. My mind leans slightly toward the "keep
the spec as simple as possible" and wants to avoid unnecessary macros.
This however would make sense if the macroified name is used many times
in the spec, but I don't think this is the case here.
* Valid Group and License values! See /usr/share/doc/rpm-4.4.1/GROUPS and
COPYING/README/... file of the corresponding package. Groups like
Applications/CAN, Applications/Perl, Perl/CAN etc are not valid.
Thanks for reminding us. Ugh...
We also need to seriously consider redoing those GROUPS one of these
days, but this is far beyond the scope of this perl cleanup.
* Update the %doc sections, some packages don't have this section, but the
CPAN packages normally contain some useful files like README, ChangeLog.
If they are tiny, then fine. Otherwise I'm wary because we really have
to avoid further bloating the distribution. I look forward to the
day of 2 DVD's for FC installation...
Warren Togami
wtogami(a)redhat.com