Future KDevelop 3.4.x releases

Hi,

All the indications from the release-team indicate that the
KDE 3.5.x branch 
will continue to remain frozen for new features and new i18n
strings. So, 
because of that, I'd like to ask that we focus our efforts
now on KDevelop 4 
and let KDevelop 3.4.x rest in peace.

However, we still have bugs and wishlist requests that might
also possibly 
need attention. Let's also leave those bugs alone unless we
actually fix them 
on trunk. Feel free to comment on them or mark them as
confirmed, but do not 
close them. Just because they won't get done in the KDevelop
3.4 timeframe 
doesn't mean that they won't need to be addressed in
KDevelop 4. We can go 
through the bug database at a later date and close the ones
we don't do then 
at that time.

Thanks
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 24.05.07 16:08:05, Matt Rogers wrote:
> All the indications from the release-team indicate that
the KDE 3.5.x branch 
> will continue to remain frozen for new features and new
i18n strings. So, 
> because of that, I'd like to ask that we focus our
efforts now on KDevelop 4 
> and let KDevelop 3.4.x rest in peace.

Agreed from my point, although that leaves two user requests
unsolved:

a) the extensive height of our C++ support page, which can
only be
reduced more by some re-arrangements and thus string
changes
b) an option to disable the search for new files during
opening a
project with custom makefile manager. This can take quite
some time
during opening on large tree's.

> However, we still have bugs and wishlist requests that
might also possibly 
> need attention. Let's also leave those bugs alone
unless we actually fix them 
> on trunk.

Thats hardly possible, as most of the stuff in kdevelop3.4
is not
available in trunk/, for example the qmake manager.

> Feel free to comment on them or mark them as confirmed,
but do not 
> close them. Just because they won't get done in the
KDevelop 3.4 timeframe 
> doesn't mean that they won't need to be addressed in
KDevelop 4. We can go 
> through the bug database at a later date and close the
ones we don't do then 
> at that time.

I agree that we shouldn't go through the bug database now to
close old
bugs or something like that. However for new bugs,
especially things
that keep developers from doing their work (like crashes)
should still
be adressed and fixed, IMHO. I plan to fix and commit at
least one QM
bug and the fix for gcc filtering as well. Distributions
tend to include
fixes from svn in their packages if they fix crashes or
annoying bugs
(at least thats the case for Debian) and we have a few
svn-users which
would benefit from these changes as well. 

So, while I do agree that major focus should be KDev4 and no
new
features should be introduced into KDevelop3 I think major
bugs (and
thats not just crashes) should still be looked at and if
there's an easy
and small fix for them it should be committed (in the
constraints of the
message freeze of course).

Andreas

-- 
You have a will that can be influenced by all with whom you
come in contact.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Thursday 24 May 2007 16:28, Andreas Pakulat wrote:
> On 24.05.07 16:08:05, Matt Rogers wrote:
> > All the indications from the release-team indicate
that the KDE 3.5.x
> > branch will continue to remain frozen for new
features and new i18n
> > strings. So, because of that, I'd like to ask that
we focus our efforts
> > now on KDevelop 4 and let KDevelop 3.4.x rest in
peace.
>
> Agreed from my point, although that leaves two user
requests unsolved:
>
> a) the extensive height of our C++ support page, which
can only be
> reduced more by some re-arrangements and thus string
changes
> b) an option to disable the search for new files during
opening a
> project with custom makefile manager. This can take
quite some time
> during opening on large tree's.
>
> > However, we still have bugs and wishlist requests
that might also
> > possibly need attention. Let's also leave those
bugs alone unless we
> > actually fix them on trunk.
>
> Thats hardly possible, as most of the stuff in
kdevelop3.4 is not
> available in trunk/, for example the qmake manager.
>

But we need to make sure that those things that are already
documented as bugs 
don't occur in KDev4. If they don't/won't occur on trunk
(after we've already 
implemented the affected bits of code) then we can say
they're fixed for 
KDevelop 4. 

> > Feel free to comment on them or mark them as
confirmed, but do not
> > close them. Just because they won't get done in
the KDevelop 3.4
> > timeframe doesn't mean that they won't need to be
addressed in KDevelop
> > 4. We can go through the bug database at a later
date and close the ones
> > we don't do then at that time.
>
> I agree that we shouldn't go through the bug database
now to close old
> bugs or something like that. However for new bugs,
especially things
> that keep developers from doing their work (like
crashes) should still
> be adressed and fixed, IMHO. I plan to fix and commit
at least one QM
> bug and the fix for gcc filtering as well.
Distributions tend to include
> fixes from svn in their packages if they fix crashes or
annoying bugs
> (at least thats the case for Debian) and we have a few
svn-users which
> would benefit from these changes as well.
>
> So, while I do agree that major focus should be KDev4
and no new
> features should be introduced into KDevelop3 I think
major bugs (and
> thats not just crashes) should still be looked at and
if there's an easy
> and small fix for them it should be committed (in the
constraints of the
> message freeze of course).
>
> Andreas

No problem with that. It's your free time after all.  
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Please don't let KDevelop 3.4.x die!

Keep in mind that the enterprise developer will stay on KDE3
minimum
the next three years.

I am using KDevelop for 2 years now, and in my opinion there
has never
been a release without major bugs so far.

A "real" stable 3.4.x release without any new
features, well
documented, would be great.

Kind regards
Daniel Schmitt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 27 May 2007 17:34:41 Daniel Schmitt wrote:
> Please don't let KDevelop 3.4.x die!
>
> Keep in mind that the enterprise developer will stay on
KDE3 minimum
> the next three years.
>
> I am using KDevelop for 2 years now, and in my opinion
there has never
> been a release without major bugs so far.
>
> A "real" stable 3.4.x release without any new
features, well
> documented, would be great.

I think that's true. We should keep fixing bugs that we
encounter, without 
adding new features. After all we'll be using kdevelop-3.4
ourselves at least 
until kdevelop-4 is out.

But I don't know who is going to update the documentation
since all developers 
are busy with kdevelop-4.

greetings, David


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 27.05.07 17:34:41, Daniel Schmitt wrote:
> Please don't let KDevelop 3.4.x die!

It will.

> Keep in mind that the enterprise developer will stay on
KDE3 minimum
> the next three years.

Then the distribution you use needs to give you support on
that for that
time, however we already dropped KDevelop3.3 completely and
our main
focus is on KDevelop4. Currently there are not even a
handful active
developers due to time constraints and thats just not enough
to fully
support 2 major versions.

> I am using KDevelop for 2 years now, and in my opinion
there has never
> been a release without major bugs so far.

I disagree here, the 3.4.0 release had a major bug in the
QMake Manager
but the 3.4.1 release doesn't have a major bug that affects
everybody.

> A "real" stable 3.4.x release without any new
features, well
> documented, would be great.

We will try to close serious bugs if time allows and we will
certainly
fix bugs for which there are patches provided.

Andreas

-- 
Your lucky number is 3552664958674928.  Watch for it
everywhere.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 27.05.07 21:05:35, David Nolden wrote:
> On Sunday 27 May 2007 17:34:41 Daniel Schmitt wrote:
> I think that's true. We should keep fixing bugs that we
encounter, without 
> adding new features. After all we'll be using
kdevelop-3.4 ourselves at least 
> until kdevelop-4 is out.

No we hopefully won't, because around akademy K3Process in
KDE4 will be
creating major problems debugging KDevelop4 from inside
KDevelop3.4. As
soon as Kdevelop4 is ready for doing development (working
build, stable
editor) we should switch to it (eat our own dogfood), IMHO.

Andreas

-- 
You single-handedly fought your way into this hopeless
mess.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 27 May 2007 10:34, Daniel Schmitt wrote:
> Please don't let KDevelop 3.4.x die!
>
> Keep in mind that the enterprise developer will stay on
KDE3 minimum
> the next three years.
>
> I am using KDevelop for 2 years now, and in my opinion
there has never
> been a release without major bugs so far.
>
> A "real" stable 3.4.x release without any new
features, well
> documented, would be great.
>
> Kind regards
> Daniel Schmitt
>

There's a string freeze and feature freeze. No nice
documentation or new 
features will be allowed. Only bugfixes.
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel