Thoughts on when to put/remove applications to/from CVS

[Matthias Welwarsky]

--Boundary-02=_0wvA+bsR6ctxEh3
Content-Type: text/plain;
  charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Wednesday 18 December 2002 21:42, Neil Stevens wrote:
> On Wednesday December 18, 2002 03:43, Matthias Welwarsky wrote:

> > 2) KDE as a platform must benefit from the inclusion.
>
> I'd say
>
> 2) A significant number of KDE users across platforms must find the
> application useful.
>
> but whichever version is better depends on whether KDE is released for the
> OS vendors or the users.  Vendors only care about the platform, users only
> care about using KDE.

Yes, well, but this does not necessarily contradict. Not every application=
=20
that users find useful, is a candidate for inclusion into a release (even i=
f=20
it's available on all hardware/OS platforms). For example, I think that=20
Quanta is not really a candidate. Same for kpovmodeler or artsbuilder. Sure=
,=20
some people use them, both are great applications, but they are so=20
specialized that users would not expect them to be part of a KDE release.=20
Also, those who need this functionality will very probably actively search=
=20
and find them even outside of a KDE release. We only have to advertise them=
=20
properly :)

> > 5) It must be maintained and development progress and process must be
> > visible, i.e. it should be actively developed using the KDE CVS.
>
> This must be interpreted carefully, as to not be mandating feature creep.
> If an app is stable and mature, there's no reason to be constantly messing
> with it.

Correct. What I'm trying to say is what Waldo said:

"KDE CVS should be the primary development location. (The software should n=
ot=20
be developed in sourceforce CVS or some company internal CVS and then copie=
d=20
to KDE CVS once in a while)"

> > 7) developers must be willing to accept the dictate of the KDE release
> > cycle
>
> This should be interpreted as to allow the developer to make outside
> releases from cvs, and to use alternate non-released branches to further
> development when the release cycle would hinder that development.

Hm. Perhaps we should now clarify what we're really talking about. I starte=
d=20
this thread to talk about a CVS inclusion/removal policy, but it has mature=
d=20
into a discussion about what should be in a KDE release. I feel that we=20
cannot discuss both issues separately, because basically, when we're talkin=
g=20
about core CVS modules, we're really talking about KDE releases.

So under this assumption, I have to disagree here: Everything that is in a=
=20
core module is automatically (if no technical reasons contradict) part of a=
=20
release. So the development process must be in line with the KDE release=20
cycle. If not, it does not qualify for the release.

regards,
	matze

=2D-=20
Matthias Welwarsky
=46achschaft Informatik FH Darmstadt
Email: matze@stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"

--Boundary-02=_0wvA+bsR6ctxEh3
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+AvwzANO+fpRuZ2IRAkIDAKDUBq4fecjhhDLcOUb36vs4FZwPsQCfWrKu
61w4zywigPK5CjAf1YGqVhY=
=X33f
-----END PGP SIGNATURE-----

--Boundary-02=_0wvA+bsR6ctxEh3--