On Tuesday, July 09, 2013 12:52:04 PM =C0lex Fiestas wrote:
> On Tuesday 09 July 2013 06:43:48 Scott Kitterman wrote:
> > I want the point releases.  The reasons for wanting them are for
> > consistency, marketing, and for distro policy releases its' much ea=
sier to
> > get a set of packages that are part of a release through the post d=
istro
> > release QA process than a set of indiviual changes.  Also, as a pra=
tical
> > matter, we manage to find the volunteer motivation to package a poi=
nt
> > release, but only rarely for individual changes.  I don't think it =
would
> > help much.
>=20
> We can have as many point releases as needed, in any version as long =
as
> there is somebody doing the backporting and the testing.
>=20
> The reality, even nowdays is that even though we do backports almost =
nobody
> is testing the stable branch (and some people even forget to do backp=
orts).
> So we end up having point releases that are less stable than their
> predecessors.
>=20
> So, in anyway (independently of 3 or 6 months release schedule) we ne=
ed a
> better way of doing minor releases.
>=20
> > A related point is KDE support policy.  AIUI, currently KDE will pr=
ovide
> > security support for the previous two releases.  After that, distro=
s are
> > on
> > their own.  Did you envision that changing to four with this propos=
al?  If
> > not, you're cutting my upstream security support in half.
>=20
> I was not aware of this, I'm sure we can include it.
>=20
> > I would like to figure out something about a better way to test poi=
nt
> > releases and be able to do them more reliably/longer.  I'll think a=
bout
> > it.
> >=20
> >  I do think this has to be addressed in some manner before going to=
 your
> >=20
> > proposed schedule.
>=20
> As i said before, we need the interested parties to do the backportin=
g and
> the testing, you are the ones that know what is bothering your users.=

>=20
> We also need to do a better work on making your life easier, use bugz=
illa
> correctly, commit tags etc.

We (not me, someone else working on Kubuntu) solved a longstanding ridd=
le in=20
our build infrastructure that was blocking having regular builds of the=
 stable=20
branches.  We're looking into the possibility of providing tip of stabl=
e=20
packages that would make it easier for our users to test the stable bra=
nch. =20
If we can get better testing and upstream developers do a good job of l=
anding=20
suitable fixes, then it ought to be mostly a matter of the KDE release =
team=20
being willing to do the releasing.

Scott K