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. > 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. :) regards Stefan Schmidt ------------------------------------------------------------------------------ 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
