To freeze or not to freeze?
Andreas Pakulat
apaku at gmx.de
Thu Jan 14 12:39:08 UTC 2010
On 14.01.10 12:44:38, Milian Wolff wrote:
> On Thursday, 14. January 2010 09:50:08 Andreas Pakulat wrote:
> > Hi,
> >
> > I don't think we've reached a final conclusion on wether we'll
> > feature-freeze the codebase with the next beta or not. Not doing it
> > (i.e. freezing with beta9) would probably mean delaying the release by 2
> > - 4 weeks (i.e. end of April instead of March), but would give us the
> > opportunity to add the last smaller features during the Sprint in
> > February.
>
> If trunk would be frozen, we must not add any features, hm? I.e. only
> performance tuning and esp. bug hunting during the meeting. I think I
> personally would be OK with it, I don't have any pressing features I must see
> in 4.0, and if I can't stand the freeze I could just hack on PHP/CSS plugins
> or Kate ;-)
>
> But I do wonder what we would do with features that would be nice for 4.1, I
> esp. think about the welcome page... This would maybe even be nice for 4.0...
>
> Isn't it possible to create a git-svn repo on e.g. gitorious? That way one
> could simply add the features there and merge/rebase after the freeze is
> lifted? Dunno...
You can also create a branch in svn ;)
As far as our tests here showed it should be possible for 1 person to create
a git clone from an svn repository, then publish that and others comitting
to that repository. Later on the person can pull the updates from the
published repository and then dcommit them to svn. We haven't done lots of
experiments with this setup however as we've switched completely to git
very fast...
The problem however is with branches, to get a meaningful history in svn,
you need to rebase your branch on top of the latest svn if you want to
"merge" it. Only when a branch is a fast-forward the commits from the
branch are visible inside svn.
Andreas
--
Never reveal your best argument.
More information about the KDevelop-devel
mailing list