2014-02-20 11:30 GMT+01:00 Stefan Schmidt <ste...@datenfreihafen.org>:
> Hello. > > On Wed, 2014-02-19 at 14:03, Tom Hacohen wrote: > > On 19/02/14 13:45, Stefan Schmidt wrote: > > > Hello. > > > > > > Its time for release busy work. For the 1.9 cycle we decided to ditch > > > ChangeLog and NEWS updates during the development and fill it up at > > > the end. Thats what I'm starting right now. > > > > > > For evas generic loaders and emotion generic players I updated the > > > NEWS file to the current beta1 state and will update it when more > > > changes come in. I also added notices to the ChngeLog file that it is > > > out of date and that people should use git log for fine grained commit > > > messages. The NEWS file will stay for a high level overview of what > > > has changed in last release. > > > > > > Doing this for the above mentioned projects was plain and easy. If you > > > want you can have a look here and give Feedback. > > > > http://git.enlightenment.org/core/emotion_generic_players.git/commit/?id=861b389b5e4dc0f314e157c4e6ba6c58529be4ba > > > > http://git.enlightenment.org/core/evas_generic_loaders.git/commit/?id=a9e051d30df4f0c00bbdd31dd5cf04aee1fd6f1c > > > > > > It boils down to looking through the commit list, ignoring all trivial > > > changes, putting the others into the correct category and maybe > > > massage some messages. It was plain and easy for these two only > > > because they had so little commits. Commits between 1.8.0 and > > > 1.9.0-beta1: > > > > > > (Git hint for number of commits between two tags: > > > git rev-list v1.8.0..v1.9.0-beta1 --count) > > > > > > Emotion Generic Players: 12 > > > Evas Generic Loaders: 10 > > > Elementary: 532 > > > EFL: 725 > > > > > > The pure numbers show that it will be way more difficult for me but > > > that my problem. You problem might be that your fancy new feature > > > might not get the attention it deserves. Here is you chance to fix > > > this. If you or your team added a nice new features or improved > > > something or fix a serious bug you might want to write some lines > > > about it here: > > > > https://phab.enlightenment.org/w/efl_and_elementary_1_9_release_announcement/ > > > > > > Bonus points for Stanluk and his team as they already did it! > > > > > > If I find good commit messages describing a bigger feature I will also > > > try to put them in the release notes. If your commits messages suck > > > your contribution might be only one line in the NEWS file instead a > > > nice reading in the release announcement. Your chance to fix this. :) > > > > > > Please also take some time to proof read the release notes wiki page > > > as well as the NEWS files once I have them ready and pushed. Its easy > > > to have mistakes comming in here. > > > > Good job, and yeah, you have your work cut out for you. > > > > By the way, I think it's time to start discussing the 1.10 release > > schedule, changes to the process, and lessons learned from the 1.9 > release. > > Some intial random thoughts on that. More shoudl follow once I formed > a better opinion: > > o The three months looks like a reasonable timeframe. Enough stuff > pilled up and not to frequently. > o The jury is still out on the two merge windows I would say. My > feeling is that the second merge window makes the first stabilization > phase uninteresting for people. Hard to say if that is true or not. > I have the same feeling about the first stabilization period: people (me included) do not give it the necessary attention. IMO is better to concentrate on the final one, so I'm with you to make the last one 3 weeks long, or either longer for me would be better. > o Having three weeks for the final stabilization would be better > imho. Maybe cutting the second merge window by one week for it? > o I need to be crystal clear on the freeze dates. Not being so makes > people grumpy. My bad, but easy enough to fix. > o Mondays are good for the cut off dates as it gave me the workday to > work on parts of it and on the other hand it allowed people to finish > things over the weekend. > o I let some things slip through but in general I was happy to see > that people did not try to sneak things in. Good job. > o The release is not out yet but from my view I think the new 3 months > schedule was a success. Obviously I'm biased on that so please form > your own opinion. :) > > > One of the things I'd love seeing in 1.10 that will make your life much > > easier is tagging changes in the commit log. So for example, having > > #fix/#feature in the commit log will indicate a fix and a feature > > respectively. I went with the hashtag, because that's what people are > > used to from the web world, however we can use whatever identifier we > > would like. It's good to have a unique identifier, because it's easier > > to grep. > > Tagging could be helpful but the first line needs way more thinking > and love in any case. I'm going through a lot of these right now when > working on the NEWS file. Some examples that make many of the first > line summarires useless: > > o Out fo context. The line might be clear when you write it in your > current thinking but has little to no meaning if someone else reads it > after some months. e.g "Fix rounding bug" (made up example because I > don't wanted to blame specific people. But its near enough to what I > see) > > o Missing work area. What I and others do is putting the work area of > a commit at the first place e.g. "eina/list: Fix appending of list > items" This helps a lot to set the corect context. > > o Summary lines are way to long. Please try to have them 80 chars > max. Don't put full 20 chars function names in them or try to squeeze > the whole commit message in it. Its just the summary line. > > I know all this makes it way more time consumping to write the summary > line and commit message. Still I think its worth the time. We have to > work with this in the future as well better have something we can make > sense of at that point. :) > > regards > Stefan Schmidt > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
