Plan for tomorrows (20070510) FESCO meeting

[Toshio Kuratomi]

On Thu, 2007-05-10 at 18:32 +0200, Thorsten Leemhuis wrote:
> Tom "spot" Callaway schrieb:
> > On Thu, 2007-05-10 at 10:41 -0500, Josh Boyer wrote:
> >> On Thu, 2007-05-10 at 09:07 -0500, Tom "spot" Callaway wrote:
> >>> On Thu, 2007-05-10 at 10:51 +0200, Christian Iseli wrote:
> >>>> Dear all,
> >>>>
> >>>> On Wed, 09 May 2007 17:05:05 -0400, Brian Pepple wrote:
> >>>>> Anyway, please find below the list of
> >>>>> topics that are likely to come up in the next FESCo meeting that is
> >>>>> scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on
> >>>>> irc.freenode.org:
> >>>> I won't be able to attend: I have voluntary firefighter training that I
> >>>> need to attend...
> >>>>
> >>>> In case the zope thing comes up again, here is my current view:
> >>>>  - I'm not in favor of a compat-python2.4 package:
> >>>>    o python maintainer doesn't want it
> >>>>    o not in line with a bleeding edge distro
> >>>>    o does not encourage other packages to update to newer version
> >>>>  - I could agree to a runzope package, or maybe even better a
> >>>>    zope-runtime sub-package
> >>> Since I probably won't be there, due to the RH Summit, my thoughts (and
> >>> votes if it comes to it):
> >>> - No compat-python2.4 package
> >> Spot, could you clarify this a bit?  Christian stated his opinion on
> >> both compat-python2.4 (a generic compat package for the distro) and
> >> "runzope" (python 2.4 packaged inside of the zope package).
> > I'm not against runzope, per-se, but I'd much much rather see an effort
> > to bring zope to current python.
> > 
> > My biggest concern with runzope packaging ideaology is that we'll leave
> > it at that, and not fix the real problem.
> 
> Well, what does that mean for compat-packages in general? Should each of
> those have a limited life time as well? Or do we need other rules like
> "packages from the repo are not allowed to use or link against compat
> packages in the devel tree at release time of a Fedora release"?
> 
> I just want consistency. We ship about 40 pacakges afaics and we should
> apply the same rules to all out packages. I fail to understand why
> python is so special. It's IMHO not just about "python for zope": people
> might have apps from other sources compiled against python-2.4 installed
> on their system -- shipping a compat-python24 for one release gives them
> time to get those apps running after a update to F7 so they can migrate
> their software to python 2.5 over the next half year until we ship F8.
> 
I'd be against a rule that very broadly banned compat packages.
compat-* packages can be useful and have minimal impact for packagers.
Jeremy's arguments about compat-python adding to the maintenance burden
for the python-2.5 maintainer are only somewhat valid to me.  There very
well could be bugs mistargeted against the current version of the
package instead of the compat- version but if it's actually causing us
problems, that's a failure in how we form channels of communication
between developers and how we guide end users into making bug reports
that we need to address regardless.

Much more telling to me is that python is a framework.  Building a
viable python2.4 is much more than building a compat-python2.4 package
and calling it done.  We have to rebuild all our python modules for
python2.4 as well.  Most of those will be easy.  Especially as long as
those packages are also available in FC6.  However, not everything will
be -- and the more releases we get from python2.4 being /usr/bin/python
the farther we will get from having packages that just work.

So I can see a justification for excluding compat-python on these
grounds.  These arguments would also apply to packages like perl, php,
and ruby where we would need to maintain a whole slew of additional
compat packages.

That said, I'm not currently in favor of outright excluding compat-* for
these either.  I think a sufficiently dedicated group of packagers
*could* do a good job of maintaining the packages.  So instead of having
a policy that denies people the opportunity to do this we should be
coming up with a set of expectations that we have for a group that is
attempting to do something like this.  Do we want them to prove the idea
is valid in a separate download repository first?  (Work could still
occur within Fedora cvs/builders but the builds would be pushed to a
separate repository.)  Do we want to specify how many packagers must be
involved?  Do we want to make sure there's some method that they use to
communicate with the maintainers of the non-compat versions of their
packages?

In other words, instead of saying, "No, we won't let you do this no
matter how dedicated you think you are to making it happen", come up
with a skeleton that says, "We don't think your project will succeed
(and that will reflect poorly on the rest of Fedora) unless you have a
plan to deal with these issues.  Here are the issues and some possible
solutions that we think would mitigate them."

These policies could share a lot with other very large projects
unrelated to compat- packages.  New official spins, a new legacy
project, official secondary arches, etc.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070515/123a5dc9/attachment.sig>