RFR: GIT Package VCS

[Toshio Kuratomi]

On Thu, 2007-06-07 at 22:25 +0200, Nicolas Mailhot wrote:
> Le jeudi 07 juin 2007 à 13:00 -0700, Toshio Kuratomi a écrit :
> > On Thu, 2007-06-07 at 20:37 +0200, Nicolas Mailhot wrote:
> > > Le jeudi 07 juin 2007 à 11:06 -0700, Toshio Kuratomi a écrit :
> > > 
> > > > Absolutely -- they have different reasons for wanting this than we do. 
> > > 
> > > Wanting what?
> > > 
> > > If what = kill centralised cvs for modern scm exploded trees, with
> > > cvs/svn/whatever gateways, while keeping the current srpm export/import
> > > modes, why not
> > > 
> > Yes.  But what is the end of your proposal?
> > 
Could you please answer this question?  You seemed to have an idea but
didn't finish your thought.

> > > If what = get everyone to use _insert_preferred_scm_there and kill other
> > > access modes → not good
> > > 
> > To be sure I understand, what are the other access modes?
> 
> archive + patches, srpm import/export, export gateways to other vcs
> 
I agree with you.  We must be able to take the information in our DRCS
and generate srpms that contain multiple patches just like today.  Not
being able to do that is to make rpm emulate the build methods of debian
packages. *shudder*.

> 
> > 2) Having the ability to pull arbitrary patches out of our VCS vs
> > pulling a discrete patch out of our current CVS system is a postive
> > thing for working with upstream.
> 
> You're describing heavy forking which is not Fedora's target and not
> needed by the overwhelming majority of fedora packages.
> 
Not at all.

Config files -- local changes that shouldn't be merged upstream but we
might change over time.  They would benefit from being revision
controlled.

Backports -- Our backport would benefit from a DRCS's history and
merging features to help update the patch when the upstream fix changes.

Local changes that are submitted upstream -- We would want to track the
history of changes that make up each patch just as if we were doing the
changes directly in upstream's tree.  If upstream asks us to modify the
patch in any of the ways that I described the DRCS helps us do that.

> You're assuming upstream has the same vcs as you
> 
No.  Nothing in 2) depends on upstream sharing the same DRCS.  What are
you visualizing that makes you think that it does?

> And I'm not sure even in this case we'd want all your coding attempts
> traced in a public vcs. Seems a lot of stuff you should do in local, and
> then produce clean patches for the fedora vcs and upstream

Having things in an exploded tree DRCS makes it easy to work locally
because you can make a local feature branch of the Fedora exploded tree,
work on the code for the patch and when done, push it back to the Fedora
tree.  But just because something is going to be submitted upstream as a
patch doesn't mean that a lack of history is desirable.  Work done in
our tree and then merged to upstream's tree is helped just as much by
having history for us to look at as upstream being able to see the
changes they made in their tree.  Backporting a fix from upstream's
development branch to one of our stable packages is an easy example of
where having history would be desirable since the changes may need to be
reworked anytime upstream makes a new release to their stable branch.

> > > > 2) Better able to rebase our local changes.
> > > 
> > > We don't want to get good at local changes, we want to push changes
> > > upstream, and even cvs is good enough for our basic rebasing needs today
> > > 
> > We do want to be good at making local changes.  We want to be so good at
> > it that when we submit the changes to upstream, upstream has no trouble
> > recognizing that they're good changes and has no issues with accepting
> > them.
> 
> And upstream will ask targeted localised patches not huge vcs feeds it
> has to sift through
> 
Right.  Which is why you can't just drop everything into an exploded
tree but have to construct something like the Ubuntu page describes.
This allows you to easily manage logical changesets within the DRCS and
send them upstream as discrete patches.

-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-devel-list/attachments/20070607/7be1d048/attachment.sig>