Re: Re: Re: Release Team BoF Summary
On Friday 13 July 2012 12:37:19 Torgny Nyblom wrote: On 13.07.2012 08:14, Martin Gräßlin wrote: On Thursday 12 July 2012 23:23:39 Albert Astals Cid wrote: El Dijous, 12 de juliol de 2012, a les 17:06:12, Allen Winter va escriure: On Thursday, July 12, 2012 08:43:12 PM Albert Astals Cid wrote: == Note 2 =There is a suggestion that every feature commit should have an associated bug number so it can be better tracked. Someone suggests trying with frameworks when its more ready I wonder if we could make special Big Feature Bugs on bugzilla and then create the feature list web page from a query of those bugs?? Each of these big features would have a milestone release number. yes.. I sorta like this idea. Thoughts? The idea is cool, problem is always forcing people to follow it :D random ideas to get devs motivated: [...] * once soft freeze is in place use git-hook to enforce that commits need a bug number (either it's a bugfix or it's a feature which needs to be listed in bugzilla) -1 for this last part. As I see it this will only decrease the motivation for fixing bugs as you find them since you will need to either find the report in bugzilla or create a new report just to close it a minute later. Concerning the first point I hope that till we would start with that once our bugtracker is cleaned up, so the developer would a) know what is in there b) has an interest to actually close the bug report as otherwise it would just start to get useless again. Second concern is of course really important as it would look like bureaucracy to a dev. But if a developer finds a bug himself in the freeze state there is something wrong. I hope that till then we have a quality team which finds the issues early. Btw. I create bug reports when I find a bug which I fix myself. So yeah something like this can only be done once the bugtracker is in a useable state and till there I agree on the -1. Cheers Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
[release-buddy] /: remove ksecrets as it is not part of kde sc 4.9 any longer
Git commit 25a5934d5651f76e70796db4f223e46fc411ec47 by Allen Winter. Committed on 13/07/2012 at 15:15. Pushed by winterz into branch 'master'. remove ksecrets as it is not part of kde sc 4.9 any longer CCMAIL: release-team@kde.org M +0-4kde-4.9.rc http://commits.kde.org/release-buddy/25a5934d5651f76e70796db4f223e46fc411ec47 diff --git a/kde-4.9.rc b/kde-4.9.rc index 7e1c021..9380cc1 100644 --- a/kde-4.9.rc +++ b/kde-4.9.rc @@ -427,10 +427,6 @@ Desc=KGpg is a simple interface for GnuPG, a powerful encryption utility. Url=%(Git)s:kremotecontrol Desc=KRemoteControl (formerly known as KDELirc) is a KDE frontend for your remote controls. -[Project:ksecrets] -Url=%(Git)s:ksecrets -Desc=Here you'll find the code of the secrets management infrastructure for KDE. Please visit TechBase - see link below. - [Project:ktimer] Url=%(Git)s:ktimer Desc=KTimer is a little tool to execute programs after some time. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On 2012-07-12, Martin Gräßlin mgraess...@kde.org wrote: My understanding is that there won't be a kde-runtime once there is=20 frameworks. Correct. Runtime bits go to the libs that has them as a implementation detail. /Sune ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KSecrets State?
Albert, Did ksecrets get into the 4.9 rc2? if so it should probably be removed from the final release at least. Jeremy On Thu, Jul 12, 2012 at 3:58 PM, Nicolás Alvarez nicolas.alva...@gmail.com wrote: 2012/7/10 Albert Astals Cid aa...@kde.org: El Dimarts, 10 de juliol de 2012, a les 10:01:53, Rex Dieter va escriure: On 07/10/2012 09:56 AM, Jeremy Whiting wrote: It seems it has been moved to playground from kdelibs, but the application in kdeutils is still sitting there. Shouldn't that be moved to playground also until it works? yes, +1 If noone disagrees, I'll ask sysadmin on thursday to move the app to playground too. I have now moved KSecretsService (repo ksecrets.git) to playground/utils. (as you probably know, this doesn't affect the git clone URL, only projects.kde.org) -- Nicolás ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
On Friday, July 13, 2012 07:44:38 PM Albert Astals Cid wrote:
El Divendres, 13 de juliol de 2012, a les 14:31:35, Aurélien Gâteau va
escriure:
Le jeudi 12 juillet 2012 20:43:12 Albert Astals Cid a écrit :
So here comes the summary of the Release Team BoF, the attached picture
is
all we wrote during the BoF itself so all written here is me trying to
remember what we said, if any of the presents disagrees or remembers
more,
please do not hesitate to comment.
Something which we discussed in the KDE Quality BoF and is of interest to
the KDE Release Team is the numbering of unstable versions.
Up to now we have been using 4.N.8* and 4.N.9* for alpha, beta and rc. The
problem with those is it is difficult when you get a report on 4.8.85 to
know if the user is running beta1, beta2, rc1 or something else.
To address this we proposed the following numbering scheme:
4.N.7{1,2,3} = N+1 alpha 1, 2, 3
4.N.8{1,2,3} = N+1 beta 1, 2, 3
4.N.9{1,2,3} = N+1 rc 1, 2, 3
With this scheme, 4.10 alpha 1 would be 4.9.71, 4.10 beta 2 would be
4.9.82
This helps with remembering but breaks our traditions, to be honest i
don't care, any other opinion?
I don't see the benefit, but I don't (as Kubuntu packager) see any harm. As
long as it's communicated in advance so users know, I don't think it matters
(this gives me a slight bias towards the status quo). Those version numbers
don't mean anything special for us from a packaging point of view.
Scott K
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
On Friday 13 July 2012 13:54:23 Scott Kitterman wrote:
On Friday, July 13, 2012 07:44:38 PM Albert Astals Cid wrote:
El Divendres, 13 de juliol de 2012, a les 14:31:35, Aurélien Gâteau va
escriure:
Le jeudi 12 juillet 2012 20:43:12 Albert Astals Cid a écrit :
So here comes the summary of the Release Team BoF, the attached
picture
is
all we wrote during the BoF itself so all written here is me trying to
remember what we said, if any of the presents disagrees or remembers
more,
please do not hesitate to comment.
Something which we discussed in the KDE Quality BoF and is of interest
to
the KDE Release Team is the numbering of unstable versions.
Up to now we have been using 4.N.8* and 4.N.9* for alpha, beta and rc.
The
problem with those is it is difficult when you get a report on 4.8.85 to
know if the user is running beta1, beta2, rc1 or something else.
To address this we proposed the following numbering scheme:
4.N.7{1,2,3} = N+1 alpha 1, 2, 3
4.N.8{1,2,3} = N+1 beta 1, 2, 3
4.N.9{1,2,3} = N+1 rc 1, 2, 3
With this scheme, 4.10 alpha 1 would be 4.9.71, 4.10 beta 2 would be
4.9.82
This helps with remembering but breaks our traditions, to be honest i
don't care, any other opinion?
I don't see the benefit, but I don't (as Kubuntu packager) see any harm.
As long as it's communicated in advance so users know, I don't think it
matters (this gives me a slight bias towards the status quo). Those
version numbers don't mean anything special for us from a packaging point
of view.
Right. They do help for bug triaging and bug fixing, so I'm very much in favour
of more readability in the version numbers.
Traditions are no reason not to improve.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
On Friday 13 July 2012 19.44.38 Albert Astals Cid wrote:
El Divendres, 13 de juliol de 2012, a les 14:31:35, Aurélien Gâteau va
escriure:
Le jeudi 12 juillet 2012 20:43:12 Albert Astals Cid a écrit :
So here comes the summary of the Release Team BoF, the attached picture is
all we wrote during the BoF itself so all written here is me trying to
remember what we said, if any of the presents disagrees or remembers more,
please do not hesitate to comment.
Something which we discussed in the KDE Quality BoF and is of interest to
the KDE Release Team is the numbering of unstable versions.
Up to now we have been using 4.N.8* and 4.N.9* for alpha, beta and rc. The
problem with those is it is difficult when you get a report on 4.8.85 to
know if the user is running beta1, beta2, rc1 or something else.
To address this we proposed the following numbering scheme:
4.N.7{1,2,3} = N+1 alpha 1, 2, 3
4.N.8{1,2,3} = N+1 beta 1, 2, 3
4.N.9{1,2,3} = N+1 rc 1, 2, 3
With this scheme, 4.10 alpha 1 would be 4.9.71, 4.10 beta 2 would be 4.9.82
This helps with remembering but breaks our traditions, to be honest i don't
care, any other opinion?
I like the idea.
/Torgny
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
