another branches reshuffling
Sebastian Kügler
sebas at kde.org
Thu Jul 7 17:23:39 CEST 2011
Hey,
On Thursday, July 07, 2011 16:46:38 Ivan Cukic wrote:
> On Thursday, 7. July 2011. 15.50.54 Marco Martin wrote:
> > right now the activitymanager related work is in the
> > active-development/master branch.
> > as the name tells, that's dove on top of master, that is really the
> > easiest way to develop, but...
> >
> > the first release will have to be done on top of 4.7, so this means we
> > need an active-development/4.7 on top of 4.7, with just all the patches
> > needed for activity manager/qml bindings.
> >
> > Ivan, can you isolate the needed commits? and can it work on top of a
> > 4.7 branch?
>
> When I asked about this, it was said that we can continue to work on top
> of master since there are too many changes to be able to say 'we're on the
> 4.7'. And for that reason, I've been merging master into the branch.
We need to keep the delta with 4.7 minimal (preferably only in
libkactivities), so we can properly QA it for release and to be able to pull
in our translations. With following master (of kdelibs and kde-runtime), I
don't think that's feasible, just too much churn.
Going forward, we should update the active-development/4.7 branch with:
- stable release updates (pulling in on 4.7.1, 4.7.2, etc.
- changes to libkactivities and our bindings
Ideally we only add pieces we're sure of, and which don't break BC with the
rest of kdelibs/kde-runtime. This kind of problems will turn up quite quickly,
as I'm regularly updating the packages (and thus building them on top of the
current 4.7 tree + active-development/master branch.
> I'll port all the changes to 4.7 branch, but I don't really want to deal
> with picking up the commits one by one - I'll just make one commit which
> 'ports'. Is it ok with everybody?
Yep, that's OK. Thanks...
> I'm pondering the idea to do the same for master as well - a few items
> will be lost from history, but it will be cleaner (w/o merges left <->
> right)
Not sure if you're allowed to change history in a public repo. That might be
blocked (though replacing the branch probably is fine).
Cheers,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
More information about the Active
mailing list