branches/KDE/3.5/kdevelop/lib/astyle

[Matt Rogers]

On Friday 21 September 2007 08:12:38 am Andreas Pakulat wrote:
> On 21.09.07 06:54:40, Matt Rogers wrote:
> > On Friday 21 September 2007 03:45:07 am Amilcar do Carmo Lucas wrote:
> > > On Friday 21 September 2007 03:11:11 Matt Rogers wrote:
> > > > > @KDevelop developers: Should we ask the release-team about removing
> > > > > branches/KDE/3.5/kdevelop? Also that would make sure the next KDE
> > > > > release won't release kdevelop from branches/KDE/3.5/kdevelop...
> > >
> > > I vote for merging the changes back to KDE/3.5 branch.
> > > The "excuse" the KDE team had for the freeze, was the i18n string
> > > freeze. Well, we solved that one, KDevelop/3.5 is translated now, so
> > > basically: "There are no new strings!"
> >
> > well, we need to hurry up and decide then. tagging for KDE 3.5.8 is on
> > 10/7. I'd prefer a merge.
>
> Then we should ask the release-team about the merge as that will break
> the feature freeze.
>
> > > If we merge it back, it will make releasing it a lot easier, and we can
> > > choose whatever version we wont, 3.4.2 or 3.5.0 for it.
> > >
> > > > We need to just let the 3.x version of KDevelop die already.
> > >
> > > KDevelop 4.0 is not ready, KDevelop 3.x works but has bugs.
> > > I'm all in favor of fixing some of them, otherwise people might start
> > > thinking that KDevelop is buggy and start moving to other IDEs.
> >
> > How do you figure that? People somehow can't live with the bugs? They
> > live with bugs in other products all the time.
>
> Well, but in other "products" they get answers like "fixed for 4.0"
> which means getting a fix at the end of this year. While for KDevelop
> this means getting a fix at some undetermined point in time. Personally
> I will keep scratching itches I find when using KDev3 for KDev4
> development, until KDev4 is in a state where I can use it for hacking.
>

No, we can say it will be fixed in the KDevelop 4.0 release. There's nothing 
wrong with that. We also don't have to let people know when our release is 
going to be when we don't even know ourselves. 

The fact that they can look forward to a fix at some point in the future is 
better than just closing a valid bug or wish, IMHO, even if that release that 
contains that fix may be a long time coming.

> > > > Why do we continue to divide our
> > > > resources, thus keeping KDevelop 4.0 from actually being finished
> > > > anytime soon?
> > >
> > > KDevelop 4.0 will take a while, let's give our userbase something they
> > > can use until then.
> >
> > They already have something they can use. KDevelop 4.0 will be done
> > faster if we quit wasting efforts on keeping an older branch alive.
>
> So you want to setup a policy that kdev3 is in full freeze including no
> bugreports? I can live with that, but it won't stop me from scratching
> itches as I said above, it only keeps me from comitting them.
>

No, not really. I'm not into limiting the freedom of a developer to scratch an 
itch or fix a bug or two here or there. 

> And I think you have to agree that since the start of this year
> KDevelop4 development didn't fall behind because people work on kdev3.
> At least I can't see any indication for that, I rather see kdev4
> development stalling because people don't have time for kdevelop hacking
> at all.
>

I can surely agree with that. I just don't know what to do about it.
--
Matt