Application version numbers, SC version numbers and FIXED-IN
Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. Is there an established policy for this? Should we use KDE SC version numbers in the FIXED-IN field? Aurélien ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Akonadi-Nepomuk Feeder Improvements
On Wednesday 26 December 2012 22.28:55 Albert Astals Cid wrote: El Dimecres, 26 de desembre de 2012, a les 17:00:43, Christian Mollekopf va escriure: Hey, I have a set of patches for the akonadi-nepomuk feeder containing massive performance improvements but also fairly intrusive changes how the feeders work, as the concept used so far didn't really work out so well for us, resulting in the nepomuk getting overloaded frequently. As the feeders so far are IMO just broken, I think we can consider this a bugfix and should get it into 4.10. More information can be found in recent kde-pim archives: http://lists.kde.org/?l=kde-pimm=135653672101531w=2 The code is here: http://quickgit.kde.org/?p=clones%2Fkdepim- runtime%2Fcmollekopf%2FpimRuntimeClone.gita=shortlogh=c2ca91566953c57af1 19 634f65b5bd73bac7e7fa So if you're ok with that, I'll commit that in the coming days to 4.10. Who's the maintainer of that code? Is it you? I'd like the non-silent agreement of that person before we further discuss if we want this that late in the game. Yes that's me. I've written most of the new code, initial development has been mostly done by Volker, but he hasn't been involved much in the last year. Cheers, Christian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Akonadi-Nepomuk Feeder Improvements
El Dijous, 27 de desembre de 2012, a les 18:14:51, Christian Mollekopf va escriure: On Wednesday 26 December 2012 22.28:55 Albert Astals Cid wrote: El Dimecres, 26 de desembre de 2012, a les 17:00:43, Christian Mollekopf va escriure: Hey, I have a set of patches for the akonadi-nepomuk feeder containing massive performance improvements but also fairly intrusive changes how the feeders work, as the concept used so far didn't really work out so well for us, resulting in the nepomuk getting overloaded frequently. As the feeders so far are IMO just broken, I think we can consider this a bugfix and should get it into 4.10. More information can be found in recent kde-pim archives: http://lists.kde.org/?l=kde-pimm=135653672101531w=2 The code is here: http://quickgit.kde.org/?p=clones%2Fkdepim- runtime%2Fcmollekopf%2FpimRuntimeClone.gita=shortlogh=c2ca91566953c57a f1 19 634f65b5bd73bac7e7fa So if you're ok with that, I'll commit that in the coming days to 4.10. Who's the maintainer of that code? Is it you? I'd like the non-silent agreement of that person before we further discuss if we want this that late in the game. Yes that's me. I've written most of the new code, initial development has been mostly done by Volker, but he hasn't been involved much in the last year. Well, you are not really an impartial person in this (you wrote the code, so obviously you think it's better), it'd be cool to have someone that has knowledge to give an assesment over the risks/benefits this late change would give us http://techbase.kde.org/Projects/Release_Team lists Allen as the kdepim release coordinator, Allen can you do that assesment or find someone to do it? Cheers, Albert Cheers, Christian ___ 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: Akonadi-Nepomuk Feeder Improvements
On Thursday 27 December 2012 18.44:53 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 18:14:51, Christian Mollekopf va escriure: On Wednesday 26 December 2012 22.28:55 Albert Astals Cid wrote: El Dimecres, 26 de desembre de 2012, a les 17:00:43, Christian Mollekopf va escriure: Hey, I have a set of patches for the akonadi-nepomuk feeder containing massive performance improvements but also fairly intrusive changes how the feeders work, as the concept used so far didn't really work out so well for us, resulting in the nepomuk getting overloaded frequently. As the feeders so far are IMO just broken, I think we can consider this a bugfix and should get it into 4.10. More information can be found in recent kde-pim archives: http://lists.kde.org/?l=kde-pimm=135653672101531w=2 The code is here: http://quickgit.kde.org/?p=clones%2Fkdepim- runtime%2Fcmollekopf%2FpimRuntimeClone.gita=shortlogh=c2ca91566953c5 7a f1 19 634f65b5bd73bac7e7fa So if you're ok with that, I'll commit that in the coming days to 4.10. Who's the maintainer of that code? Is it you? I'd like the non-silent agreement of that person before we further discuss if we want this that late in the game. Yes that's me. I've written most of the new code, initial development has been mostly done by Volker, but he hasn't been involved much in the last year. Well, you are not really an impartial person in this (you wrote the code, so obviously you think it's better), it'd be cool to have someone that has knowledge to give an assesment over the risks/benefits this late change would give us Indeed. http://techbase.kde.org/Projects/Release_Team lists Allen as the kdepim release coordinator, Allen can you do that assesment or find someone to do it? The people with the most knowledge about it are probably Volker and Vishesh. David Faure and Laurent also read some of the code I think. I'd be happy to discuss/explain the problems and solutions with anyone interested, just let me know. Cheers, Christian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, e.g https://bugs.kde.org/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=2011-06-01chfieldto=Nowchfield=cf_versionfixedinchfieldvalue=4.9.4cmdtype=doitorder=Bug+Numberfield0-0-0=nooptype0-0-0=noopvalue0-0-0= You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. Cheers, Albert ___ 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: Akonadi-Nepomuk Feeder Improvements
Volker, Vishesh, David, Laurent, can any of you guys comment on the code Christian is asking to be in RC2? Cheers, Albert El Dijous, 27 de desembre de 2012, a les 18:56:11, Christian Mollekopf va escriure: On Thursday 27 December 2012 18.44:53 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 18:14:51, Christian Mollekopf va escriure: On Wednesday 26 December 2012 22.28:55 Albert Astals Cid wrote: El Dimecres, 26 de desembre de 2012, a les 17:00:43, Christian Mollekopf va escriure: Hey, I have a set of patches for the akonadi-nepomuk feeder containing massive performance improvements but also fairly intrusive changes how the feeders work, as the concept used so far didn't really work out so well for us, resulting in the nepomuk getting overloaded frequently. As the feeders so far are IMO just broken, I think we can consider this a bugfix and should get it into 4.10. More information can be found in recent kde-pim archives: http://lists.kde.org/?l=kde-pimm=135653672101531w=2 The code is here: http://quickgit.kde.org/?p=clones%2Fkdepim- runtime%2Fcmollekopf%2FpimRuntimeClone.gita=shortlogh=c2ca91566953 c5 7a f1 19 634f65b5bd73bac7e7fa So if you're ok with that, I'll commit that in the coming days to 4.10. Who's the maintainer of that code? Is it you? I'd like the non-silent agreement of that person before we further discuss if we want this that late in the game. Yes that's me. I've written most of the new code, initial development has been mostly done by Volker, but he hasn't been involved much in the last year. Well, you are not really an impartial person in this (you wrote the code, so obviously you think it's better), it'd be cool to have someone that has knowledge to give an assesment over the risks/benefits this late change would give us Indeed. http://techbase.kde.org/Projects/Release_Team lists Allen as the kdepim release coordinator, Allen can you do that assesment or find someone to do it? The people with the most knowledge about it are probably Volker and Vishesh. David Faure and Laurent also read some of the code I think. I'd be happy to discuss/explain the problems and solutions with anyone interested, just let me know. Cheers, Christian ___ 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: Application version numbers, SC version numbers and FIXED-IN
On Thursday, December 27, 2012 23:42:15 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. We can instead query the git repository directly for commit messages containing '^BUG: ' or '^FIXED-IN:' (and its alternates) within the commits between the old and new version. There's an existing script which figures out how to generate a changelog from the old XML based on a version number which would probably be easy to adapt (and I'd even volunteer to do it, if that would be helpful). The question would be what type of output is needed to make this easy to use (e.g. list of bugs, or ?) Regards, - Michael Pyne 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
Re: Application version numbers, SC version numbers and FIXED-IN
El Dijous, 27 de desembre de 2012, a les 18:27:25, Michael Pyne va escriure: On Thursday, December 27, 2012 23:42:15 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. We can instead query the git repository directly for commit messages containing '^BUG: ' or '^FIXED-IN:' (and its alternates) within the commits between the old and new version. Which means someone needs to do a lot of work (lot of work, getting all the new and old versions for more than 100 repos and then running the script and then putting it somewhere in the web) Coding the script is the easy part, finding someone to run and maintain it is the hard part. Of course the great part would be having this run automagically. There's an existing script which figures out how to generate a changelog from the old XML based on a version number which would probably be easy to adapt (and I'd even volunteer to do it, if that would be helpful). The question would be what type of output is needed to make this easy to use (e.g. list of bugs, or ?) No clue, to be honest i think we have mch more important things to do, just put the SC version in the FIXED-IN field and save everyone's time, or am i seeing things wrong? Cheers, Albert Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Application version numbers, SC version numbers and FIXED-IN
On Thursday 27 December 2012 23:42:15 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, e.g https://bugs.kde.org/buglist.cgi?query_format�vancedshort_desc_type=allwo rdssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=RES OLVEDbug_status=VERIFIEDbug_status=CLOSEDemailtype1=substringemail1=ema ilassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bu gidtype=includebug_id=votes=chfieldfrom 11-06-01chfieldto=Nowchfield cf_versionfixedinchfieldvalue=4.9.4cmdtype=doitorder=Bug+Numberfield0-0- 0=nooptype0-0-0=noopvalue0-0-0 You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. I don't think that this query could be further improved - maybe with target milestones, but they need to be set manually and would still require an app to use the SC version numbers. Back at Akademy Jeroen showed some MediaWiki magic to automize the changelog. Maybe we could transit to something like that, then the maintainers just need to provide a kind of pattern for their version numbers? Cheers Martin 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
