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. 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
