KDE SC 4.11 Release Schedule

[Albert Astals Cid]

El Divendres, 18 de gener de 2013, a les 03:13:05, Christian Mollekopf va 
escriure:
> On Tuesday 15 January 2013 23.27:53 Albert Astals Cid wrote:
> > El Dimarts, 15 de gener de 2013, a les 16:30:50, Allen Winter va escriure:
> > 
> > I'd like to propose some changes for 4.11, i'd like everyone to comment
> > 
> > 1) Drop Betas to 1
> > 
> > 	It doesn't seem "to me" that having extra betas gives us much more
> > 	quality,
> > 
> > so my suggestion is to drop Beta 2 and move Beta 1 to happen in Beta 2
> > time
> > (moving also Hard Freeze) which gives us 2 more weeks for feature
> > development
> 
> +1
> 
> > 2) Drop RCs to 1
> > 
> > 	Same thing, it did not feel to me as that it gave us much, drop RC2 and
> > 	RC1
> > 
> > one week into the future
> 
> +1
> 
> > 3) Increase RC time between tag and packaging
> > 
> > 	One day between tagging and release is crazy, let's have 5/6 days as we
> > 
> > have for the other releases
> > 
> > 4) Don't release if any if the tests are failing in builds.kde.org
> > 
> > 	If we have tests, they have to work
> 
> I think that would be a very good idea. That would also give some level of
> confidence that tests actually work, as some of the tests are not entirely
> trivial to run (with dedicated akonadi/nepomuk instance etc.), and if you're
> not even sure that they actually work...
> 
> > 5) Introduce an pre-commit check after Feature freeze
> > 
> > 	That check would look for "SCHEDULE-CHECK: bugfix" in the commit log 
and
> > 
> > reject the commit otherwise. This would fix the fact that people seem to
> > be
> > commiting features and then saying "oh, but i did not read the emails you
> > send every month saying we are in a feature freeze so i did not know I
> > couldn't do this", this way at least they would be forced to say their
> > stuff is a bugfix.
> 
> If the feature freeze is short enough (see 1), it might be even nicer if a
> corresponding bugreport has to exist, which could help QA people to see
> what's happening and track QA efforts. As always, there has to be a way to
> circumvent this e.g. by a keyword in the commit message. If it just becomes
> a no-brainer to always add a keyword to the commit it probably won't help a
> lot though.

Yes Fabio D'Urso worked for fun on some implementation of this and he had a 
SCHEDULE-CHECK: force and lots of more bells & whistles i did not add here 
since i regarded them as implementation detail. I think that what is worth 
discussing is if the idea of forcing people to say "yes this is a bugfix" 
makes sense or not.

Cheers,
  Albert

> 
> Cheers,
> Christian
> 
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team