Re: Feature Freeze and Review Board
El Divendres, 19 d'octubre de 2012, a les 21:44:24, Martin Gräßlin va escriure: Am 19.10.2012 19:35, schrieb Albert Astals Cid: El Divendres, 19 d'octubre de 2012, a les 10:47:30, Martin Gräßlin va escriure: Hi all, I was wondering about the relation of feature freeze and Review Board. Right now we have quite some open review request for e.g. KWin or also Plasma. To me everything what is currently open as a review request is a planned feature. Now given our feature freeze policy none of these requests may be merged after the soft freeze if they are not also listed in the planned feature wiki page. This means I have now to tell everyone to edit the wiki if they want to get the feature in. I consider editing MediaWiki tables as a PITA and I consider manual work for something which already is in a computer system as quite stupid and I think the time is better spent on the code then on editing the Wiki document. Therefore I would like to request the following change in our release schedule: Trunk is frozen for feature commits that are not listed in the planned feature document. to Trunk is frozen for feature commits that are not listed in the planned feature document or opened as a review request prior to the feature freeze. Opinions? It makes sense *but* having the wiki up to date with all the features is good not only for the feature freeze scenario, it also helps promo, QA, and other people to know what is new and what has to be talked about, tested, etc. fair enough, but what about all those features which happened between July and October and which nobody added, because people only add things to the feature plan to get two more weeks of hacking? Also why enforce to change the wiki document now, when it is not required right *now*. This has nothing to do with my request, but the feature plan we currently have does not list the features we ship. It might be that developers add it after promo asked for the third time that if it's not listed it will not be in the release announcement. Currently from a developer perspective the feature plan is only used to get the two more weeks for hacking which ends up with many, many todo items to just get everything in one might work on and in the end it looks like we have nothing done at all. All I want is to overcome this for at least the things which are already in progress by being on review board. We make here the life of the developers more difficult than it has to be. Ok, seems noone else cares to give their opinion, so I think they agree with what you say ;-) So personally i'd like that you guys still add the stuff to the feature plan. And when we are at it: could we change trunk to whatever is better fitting? Can we just be smart people and accept that trunk is just a word and that the rest of the people is smart enough too and understand that for git it means master? Because what other word are you suggesting instead of trunk? maybe release branch? Not really sure that'd be clearer, is anyone reading this and has an opinion? Cheers, Albert Cheers Martin Cheers, Albert Kind Regards Martin Gräßlin ___ 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 ___ 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: Feature Freeze and Review Board
On Wednesday 24 October 2012 14.10.43 Albert Astals Cid wrote: [...] Not really sure that'd be clearer, is anyone reading this and has an opinion? Reading yes, but I agree with you both so to say :) /Torgny ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Feature Freeze and Review Board
On Wednesday, October 24, 2012 14:10:43 Albert Astals Cid wrote: So personally i'd like that you guys still add the stuff to the feature plan. And when we are at it: could we change trunk to whatever is better fitting? Can we just be smart people and accept that trunk is just a word and that the rest of the people is smart enough too and understand that for git it means master? Because what other word are you suggesting instead of trunk? maybe release branch? Not really sure that'd be clearer, is anyone reading this and has an opinion? I agree with whoever mentioned bikeshedding. trunk, master and release branch are all fine and I think clear enough. Or one could just use them all three. As to the real issue: I think stuff submitted to review board should get the same handling as if it were put on the Feature Plan, i.e. only be applied to the hard freeze. That's most in line with what we actually want to achieve. We should encourage adding it to the feature plan as well, so the RB only is just an exception we know how to handle. Now let's get back to work =) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Feature Freeze and Review Board
El Divendres, 19 d'octubre de 2012, a les 10:47:30, Martin Gräßlin va escriure: Hi all, I was wondering about the relation of feature freeze and Review Board. Right now we have quite some open review request for e.g. KWin or also Plasma. To me everything what is currently open as a review request is a planned feature. Now given our feature freeze policy none of these requests may be merged after the soft freeze if they are not also listed in the planned feature wiki page. This means I have now to tell everyone to edit the wiki if they want to get the feature in. I consider editing MediaWiki tables as a PITA and I consider manual work for something which already is in a computer system as quite stupid and I think the time is better spent on the code then on editing the Wiki document. Therefore I would like to request the following change in our release schedule: Trunk is frozen for feature commits that are not listed in the planned feature document. to Trunk is frozen for feature commits that are not listed in the planned feature document or opened as a review request prior to the feature freeze. Opinions? It makes sense *but* having the wiki up to date with all the features is good not only for the feature freeze scenario, it also helps promo, QA, and other people to know what is new and what has to be talked about, tested, etc. So personally i'd like that you guys still add the stuff to the feature plan. And when we are at it: could we change trunk to whatever is better fitting? Can we just be smart people and accept that trunk is just a word and that the rest of the people is smart enough too and understand that for git it means master? Because what other word are you suggesting instead of trunk? Cheers, Albert Kind Regards Martin Gräßlin ___ 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: Feature Freeze and Review Board
Am 19.10.2012 19:35, schrieb Albert Astals Cid: El Divendres, 19 d'octubre de 2012, a les 10:47:30, Martin Gräßlin va escriure: Hi all, I was wondering about the relation of feature freeze and Review Board. Right now we have quite some open review request for e.g. KWin or also Plasma. To me everything what is currently open as a review request is a planned feature. Now given our feature freeze policy none of these requests may be merged after the soft freeze if they are not also listed in the planned feature wiki page. This means I have now to tell everyone to edit the wiki if they want to get the feature in. I consider editing MediaWiki tables as a PITA and I consider manual work for something which already is in a computer system as quite stupid and I think the time is better spent on the code then on editing the Wiki document. Therefore I would like to request the following change in our release schedule: Trunk is frozen for feature commits that are not listed in the planned feature document. to Trunk is frozen for feature commits that are not listed in the planned feature document or opened as a review request prior to the feature freeze. Opinions? It makes sense *but* having the wiki up to date with all the features is good not only for the feature freeze scenario, it also helps promo, QA, and other people to know what is new and what has to be talked about, tested, etc. fair enough, but what about all those features which happened between July and October and which nobody added, because people only add things to the feature plan to get two more weeks of hacking? Also why enforce to change the wiki document now, when it is not required right *now*. This has nothing to do with my request, but the feature plan we currently have does not list the features we ship. It might be that developers add it after promo asked for the third time that if it's not listed it will not be in the release announcement. Currently from a developer perspective the feature plan is only used to get the two more weeks for hacking which ends up with many, many todo items to just get everything in one might work on and in the end it looks like we have nothing done at all. All I want is to overcome this for at least the things which are already in progress by being on review board. We make here the life of the developers more difficult than it has to be. So personally i'd like that you guys still add the stuff to the feature plan. And when we are at it: could we change trunk to whatever is better fitting? Can we just be smart people and accept that trunk is just a word and that the rest of the people is smart enough too and understand that for git it means master? Because what other word are you suggesting instead of trunk? maybe release branch? Cheers Martin Cheers, Albert Kind Regards Martin Gräßlin ___ 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 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
