Am 10.07.2014 15:22, schrieb Sergi Almacellas Abellana: > El 10/07/14 12:20, Jan Grasnick | Grasbauer UG ha escrit: >> This all is good, but I want to share my concerns with the current >> process (it's more a question than a proposition): >> >> since I always developing on the last release it's always a little >> bit hard for me to contribute: >> >> I detect a bug or think about a possible improvement. Then I edit the >> involved part of the default modules (if it looks to me like a bug) >> or overwrite a method of the core modules (if I think it could be an >> improvement). After I continue with my projects - checking if the >> changes are solving my problem or it is only wrong designed approach >> in my modules. Now I decide that it could be a contribution. Next I >> have to check out or update the trunk. Now i need to merge my changes >> to trunk, create an issue, create a code review, create a patch - >> this is a lot of work which interrupts the work I just focused in. >> Because I don't do it very often I need to read the contribution >> guideline each time (possible alzheimer, but anyway) >> >> I don't know if there is a way to simplify this - but making >> contributions on last release would make some steps obsolete. I know >> that having all tools handy for a core developer is state of art - >> but a implementer of projects not always knows all the stuff he needs >> for contribution. So we possibly loose a lot of input because >> potential contributors decide to use a custom method in here modules >> to avoid the noise a contribution could cause. While I'm writing >> this, a community role like quality manager would be nice: I make my >> contribution - community go to discuss the improvement and a person >> with all the tools handy will check in the result in the right manner >> to trunk. I know that this is more work for somebody but it could >> lower barriers for people, which is more involved in professional >> implementation than in "hard core coding". >> >> I don't know, if I'm the only one who has this view - but I think it >> could be discussed, at least at the Unconference > We are also developing on the latest release. So i will explain what > works for us. There are several cases here: > > 1. While developing something, i found something that could be > improved on core modules but doesn't block the development. I *always > fill an issue on roundup* to remeber it and continue with the > development. I have a custom query, for issues created by me not > resolved that I always have a look before contributing, so when i have > time i try to resolve this issues. An example can be found on [1] ok
> > 2. I need some patch on core modules to develop our functionality. > Then just fill the issue (explaining the needs), write the patch, and > we add the patch to a quilt queue[2], with the issue and codereview > information. Develop the functionality with the patched methods untill > we get some feedback on the patch (luckly this comes fast). If needed > (normally it needs), refactor the patch and the development. When the > development is finished normally the patch lands on trunk and we put > the latest version of the patch on the quilt queue. When upgrading to > a new version you just need to remove the patches that went to trunk. This is really nice ... > > 3. Bugs. Very similar from previous point, the unique difference is > that you have to remove the patch from the queue when the bug is > backported to the latest version. > ok > > You're right that sometimes (from my experience not a lot) the patches > need to be adapted to the trunk version, but i think the effort is > worth as you will have it fixed on the next version. Yes, you are right. Our Problem: we have modules from version 2.4 - migration over releases is time consuming and in future we need to be more recent. If not, its hard to remember if it was a fix for something and was has changed since than. So our problem is more internal. Your explanations are a good write up for best practice. Thanks Jan
