clarification on git, central repositories and commit access lists

[Aaron J. Seigo]

On Wednesday 22 August 2007, Thomas Zander wrote:
> On Wednesday 22 August 2007 06:49:55 Aaron J. Seigo wrote:
> > > Their git trees (most likely more then one) would be published
> > > somewhere for kdepim enthusiasts to follow and develop on, but in the
> > > end you'd still need to move the patches that will eventually end up
> > > in the final release to subversion.
> >
> > which means that between releases they'd have one less person testing
> > their code and one less person making the odd fix here and there. i
> > track every module and have used HEAD/trunk kdepim for the entirety of
> > the kde2 and kde3 series for my day to day use.
> >
> > unless their git trees were synced on a very frequent basis with svn
> > and unless i could commit to svn and have it sync'd back to one of
> > their trees, there's no point in me dealing with running trunk/ apps.
>
> I think we differ in opinion not on a technical but mostly on a
> programming-workflow approach.

you're right that it isn't a technical issue. we differ based on this: "aaron 
cares about having an agreed upon plan, even a sketch of one, that doesn't 
run us the risk of causing community issues and which sounds realistic."

as far as i can see, so far we have:

- people who want will move to using git-svn
- ???
- time passes
- ???
- everyone is using git!

i understand that people are still trying to figure out how to transition our 
one big svn repo to multiple git repos, how to move things gently to git 
where there is desire to do so, etc... i'm just pointing out that these are 
not the only issues to deal with.

in fact, these are "just" the implementation detail issues. we have "design 
level" issues to figure out, too. no matter what scm we'd be discussing these 
issues would be here. hell, it's not even unique to scm's; splitting bugzilla 
out to a new distributed system would come with similar (if not as 
development critical) issues.

> > i actually consider eating dogfood to be pretty important.
>
> I agree.
> And I believe that Git actually helps by allowing others to see a more
> representative version of the software instead of one that is constantly
> in flux.

this isn't the discussion here at all. we actually agree on this point. it's 
the question of the transition period that is getting sidestepped.

> > i'd also suggest that there are already enough barriers to contributing
> > to kdelibs from application developers that we don't need to widen
> > those rifts.
>
> Right, but I don't see how adding ways for people to work widens the rift.

it matters when "adding ways" comes without reasonably workable means for 
people working in those different ways to work together.

git-svn is being offered as a solution that works when it seems that git-svn 
itself needs a lot of work still. it's also not an answer that mollifies me 
since it avoids answering the real question of how do we finally move off of 
svn itself. unless the implication is that we get everyone using git-svn and 
at that point we ditch svn.

timelines are also missing. do we target a switch to pure git for no earlier 
than 4.2? (earlier would be a mistake, imho). i think that's important to 
note so that those moving to git now are aware that they will be committing 
to using git-svn for at least that long and don't end up trying to move 
prematurely and creating unintended chaos. 

> But, you may be right that we should start at the edges (extragear or
> KOffice) and experiment there.  Showing how it can be done is typically
> the best way to take away uncertainties :)

it also means that if people playing with these things drop the ball on the 
process, it doesn't hurt things as much.

it wouldn't be optimal or even fun/pleasant, but we can live with some 
extragear apps or even koffice getting screwed for a release or two. 
realistically we don't have the same luxury for kdelibs/base or most of the 
other "core" modules.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070822/6fafa07d/attachment.sig>