Hello. On Fri, 2014-02-28 at 16:38, Cedric BAIL wrote: > Hello, > > On Fri, Feb 28, 2014 at 11:35 AM, Stefan Schmidt > <ste...@datenfreihafen.org> wrote: > > On Tue, 2014-02-25 at 20:02, Davide Andreoli wrote: > >> > >> @fix , not @bug... we backport fixes not bugs... I hope ;) > >> > >> Please someone should update the 2 wiki pages: > >> phab.enlightenment.org/w/git_practices/ > >> phab.enlightenment.org/w/commit_check_point/ > >> > >> I think the 2 pages should be merged in a single one (probably the first) > > > > While I see a tiny bit ov overlap these to pages different topics. The > > first was introduced during the git migration to help people dealing > > with git. The second is for reviewers. They might use git but also > > look at different parts of a commit. > > > >> and that we must add the choosed tags (@fix, @feature) on that page. > > > > I moved the commit message section over to git practice and extended > > it with a description of what I think covers what we have discussed so > > far. > > > > https://phab.enlightenment.org/w/git_practices/#commit-message > > > > It would be good if every developer could give it look and raise > > questions if things are unclear. > > So I might be late to the party, but I would like to share a pointer > to what systemd does as I do like it. > > Also that might be a silly idea, but if I do put a @backport in the > commit message, wouldn't it be possible for gitolite to automatically > try to backport in all our stable branch ?
And we would cross the fingers and hope all will be well? Who would do the testing of this code in slightly different code base? I just reverted a patch from 1.8 which does not even compile. It worked fine in master and 1.9 though. This kind of script would do exactly this kind of backporting. Without a human factor involved I have a really bad feeling about this. If you want to cover such things with machine power we would definitely need more people in the automated build and QA as well as the release team. I'm reaching the limits of what I can do wrt this. With 1.10 release handling, 1.9 and 1.8 maintenance, jenkins maintenance I was to invest more time in this than I was. Other tasks are already falling behind which is bad. And while I have a list of things I would like to see I just see no time for doing it. I focus on maintenance right now to at least make sure things are not falling apart. :) The last paragraph was not really related to your question but it felt worth like putting it here. regards Stefan Schmidt ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
