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]
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.
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.
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.
Just my 3 cents :)
[1] https://bugs.tryton.org/issue3597
[2] https://bitbucket.org/nantic/trytond-patches/src
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
