Hello. On Thu, 2014-02-20 at 10:55, Tom Hacohen wrote: > On 20/02/14 10:30, Stefan Schmidt wrote: > > 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. > > I agree. I think that part is good. > > > 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 disagree here. Just preventing the influx of commits, makes it easier > for people to find bugs and fix them. When everything changes under your > feet all the time, it's hard to get lost in a storm of bugs. Maybe > though, it's a good idea to make the first stabilization period shorter > than the second?
Dave is also thinking in the same direction. Would work for me. > > o Having three weeks for the final stabilization would be better > > imho. Maybe cutting the second merge window by one week for it? > > As said in the previous point: I think cutting the first stabilization > period by a week, and extending the second by a week would work well. See above. > > o I need to be crystal clear on the freeze dates. Not being so makes > > people grumpy. My bad, but easy enough to fix. > > Yes. Especially since you ran away and went off skiing. I'd probably > say: put a timer on phab for everything, not just the release, and when > that one expires, it's the end. Hmm, that could work. I avoided putting the time of the day behind the date to allow people to be a bit late and blame it on timezones. :) > > 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: > > I'm also an offender there. I think what we should make clear is this: > if a commit is tagged, the summary line should be the same as the would > have been written NEWS entry. > > > > > 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) > > See comment above. > > > > > 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. > > I've been pushing it for ages, I think we are improving there. Putting > it here certainly helps with validating that. :) :) > > > > 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. > > Yeah, I usually try to avoid putting func names in there, but if I feel > like I must, I usually trim them, as the context is already know, so for > example: > "Evas textblock: Fixed *_text_set" - Yeah, this is a bad commit message > just to illustrate the trimming. > > > > > 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. :) > > > > Yes. Another thing worth mentioning, is that we took off a lot of the > load by not having to merge and deal with the NEWS/ChangeLog files. > Writing what you would have written in the NEWS file as the summary is > not a lot to ask and is still way less than before. We avoided the merge conflicts and such but this still does not leave us with a good description about what happened in this release. I find it kind of surprising that almost nobody wants to write some words about what he spent so much time on during the development of this release. The release note wiki page is still almost empty. > Thank you Stefan for your great work, and let's hope we all behave in 1.10. One can always hope. :P 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
