On Wed, 27 Jul 2016 11:19:14 +0200 Stefan Schmidt <[email protected]> said:
> Hello. > > On 27/07/16 03:28, Simon Lees wrote: > > Hi all, > > > > Currently EFL and e have very different backporting policies which has > > caused various issues such as the one listed below and on the other hand > > at times several important efl fixes have missed being backported. > > > > The current efl policy seems to be everyone backports there own fixes, > > while the e policy is zmike backports everything just before release. > > These conflicting policies are leading to the issues so we really should > > settle for one policy across both projects. > > > While the idea sounds good on paper I do not expect it to fly. Let me > explain why. > > Either 1. everyone marks > > there fixes with @fix and someone runs a script just before release to > > make sure everything is backported (this may not fix the revert issue). > > We tried to use @fix as an indication here for valid backports. Sadly by > now it has lost its meaning completely. It was intended for patches that > fix an issue in code that was _already in the last release_ but by now > people use it for every fix they do. Even for code they just committed a > few minutes ago. > > Using the @fix tag would thus result in many, many patches that would > simply not apply to the stable branch(es). > > https://phab.enlightenment.org/w/git_practices/ > Commit Messages section. > > If you would be able to educate people to use the @fix tag as intended > the automatic backport might work but to be honest here I personally > think its to late for teaching people this. It has been in different use > for to long already. But be my guest if you think its still possible to > change. this can sometimes be a bit tricky because you are not sure if the bug was in the last release. i don't use it for something i know was created since last release... if i'm not sure i put an @fix in anyway. i'd like to think the script would get a list of POTENTIAL fixes to go in the NEWS file then some hand filtering. > > Or as that involves someone doing work we would have to settle with 2. > > which is people can backport what they want when they want and release > > managers should send a email to the list reminding people a few days > > before they do releases (current efl approach) > > There is another reason I have a different approach. The amount of > developers participating in the projects is very different. A handful of > people normally commit code to E (maybe some more people with a few > commits) while efl had over 70 in the 1.17 release alone. > > Which makes it impossible for me to track all commits and see if they > are suitable as a backport without the help of the author. (It might not > apply, the issue might not be in the last release, it might be to > dangerous, etc) > > maintaining both just > > gets confusing for people not paying attention. > > I just do not think we will find a common ground here. I love to get > pleasantly surprised though. :) i do agree that we need to have a consistent policy at least between efl and e. as those are core core core projects. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
