Feature Freeze and Review Board

Albert Astals Cid aacid at kde.org
Wed Oct 24 12:10:43 UTC 2012


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 at kde.org
> >> https://mail.kde.org/mailman/listinfo/release-team
> > 
> > _______________________________________________
> > release-team mailing list
> > release-team at kde.org
> > https://mail.kde.org/mailman/listinfo/release-team
> 
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team


More information about the release-team mailing list