On Fri, 2007-06-08 at 14:05 +0200, Nicolas Mailhot wrote:
> Le Ven 8 juin 2007 00:12, Toshio Kuratomi a écrit :
>
> >> 2. we don't really care what happened between two upstream releases,
> >> that's best traced in the upstream vcs, a giant changeset between
> >> them
> >> is more pertinent at the fedora level than all the upstream change
> >> history
> >>
> > We do when we're backporting a specific fix from upstream's
> > development
> > tree.
> >
> >> 3. we don't really care what happened on the packager system either,
> >> just what was pushed as a build (or attempted-to-built package)
> >>
> > I disagree with this one quite a bit.
> >> 4. we really do not want patches that stomp on each other
> >>
> > Actually, we do.
>
> IMHO you just don't realise a srpm content and the Fedora VCS are
> intended for very different audiences than an upstream VCS.
>
I think we agree that SRPMs serve the purposes you outline but disagree
what purposes the Fedora VCS should fill. If the reasons you outline
below were sufficient for the VCS role, we wouldn't really need a VCS...
Just a way to access a sequence of SRPMs. I think we need a VCS because
we do development just like upstream. Our goal is to get the majority
of our changes (everything not specific to the distro [defaults, etc])
into upstream but that doesn't change the fact that we are programming
and would be helped by having access to VCS tools.
> Upstream VCS is for core developpers. You trace what changes were
> made, by whom, for what reasons and people who consult it are
> specialists who know the codebase.
>
> SRPMs and Fedora packaging VCSes have quite another target. It's :
> - "did Fedora break my trust in the upstream release"
> - "can I check quickly with no deep knowledge of upstream codebase
> nothing is obviously wrong"
> - "can I quickly revert a suspicious change"
>
Having quilt like commands as part of the interaction with the VCS
allows you to use the exploded tree in this manner.
> It's definitely not
> - "are Fedora patches are correct or useful fonctionnality-wise"
> - "why did the Packager did this thing"
>
Disagree wholeheartedly. I don't just take upstream releases and
package them. I also code bugfixes, backport fixes, and make changes to
the default configs. When applicable, I submit these changes to
upstream. Seeing as this is code developed against the source tree, I
want to be able to track the changes I make in a VCS. Simply adding and
removing patches in CVS is not very good for this. Working with those
patches against the exploded tree is much better.
> To this end you need:
> - small patches
> - which are not interdependant
> - and have little churn
>
Ideally, yes. But there are times when the ideal does not occur. A
patch to install data files to a hierarchy under %{datadir} could touch
all the Makefile.ams, configure.ac, and several source files. Another
patch to fix library detection could affect the same files. Large
patches and interdependent.
Little churn is great but doesn't always occur. Maybe upstream
disagrees with how to fix a problem that you've patched for rawhide.
Maybe you backported a fix from upstream and they've changed their mind
on how to fix it. When you review the changes to a patch between
trusted release 1.0-1 and new release 1.0-2, do you really find it
easier to review the diff of a diff or would it be easier to just see
what the changes to the tree were between the two rpm releases?
-Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
