Git repositories created and how to work with them

[Andreas Pakulat]

On 04.05.10 09:54:07, David Nolden wrote:
> I'm not sure whether that workflow is efficient.

It certainly will be more efficient than backporting manually.

> Fact is: I will always use master. When I notice a bug in master, then
> it is natural to first fix it in master, and then decide whether the
> fix is also required in the stable branch, and eventually backport it.

Thats something we'll have to fix in our behaviour IMHO. The thing is that
backporting means cherry-picking each single commit into the stable branch,
so its the same situation as right now and I'm personally not going to do
that. Frankly switching branches in git is easy and in particular you can
do the switching with a dirty checkout without problems.

Also we should probably try to reduce the release cycle as git makes it
easier to do this, master is simply branched off at some point and any
feature-branch that is not yet ready at that point is simply not merged.
That will help with the "master and stable branch are too different" as
once the big change is in, we might simply branch off a new stable branch
for the release..
 
> Also it will _always_ be problematic to backport patches between
> different versions (stable and master), what might be a bug-fix in one
> branch, might cause even worse bugs in the other branch, so I'm not
> sure if it's a good idea to make the porting semi-automatic (like the
> "every sunday merge everything" rule). It would be better if the exact
> person who does the fix also puts some thinking into the issue to
> decide whether/how it should be ported between the branches.

Well, I wanted to avoid lots of merge-commits because everybody merges when
a bugfix commit has been done. But "put some thinking into the issue" and
"doing a merge once a week" doesn't exclude one-another. You can still opt
for doing the merge yourself before pushing everything and adjusting the
merge commit to master as is needed.

> And about buildability: The problem is that we have a dependency
> between kdevplatform and kdevelop. Usually a specific version of
> kdevelop is buildable and runnable only with one specific version of
> kdevplatform, which makes "git bisect" very problematic, and makes it
> hard to find a buildable configuration. The solution to this would be
> putting kdevplatform and kdevelop into the same repository, so they
> can be changed within one commit.

Thats not really a good solution. I'd rather have kdevplatform not change
every other day. In particular the libraries should start to move towards
being stable and not changing that much. Apart from that we can easily
adjust the version numbers to reflect such changes and make the requirement
explicit so you'll get a notice during the cmake run that kdevplatform is
too old (or too new).

Andreas

-- 
Don't plan any hasty moves.  You'll be evicted soon anyway.