On 10 Jul 13:15, Jan Grasnick | ag kommunikation wrote:
> Am 10.07.2014 13:01, schrieb Cédric Krier:
> > On 10 Jul 12:20, Jan Grasnick | Grasbauer UG wrote:
> >> Am 10.07.2014 01:10, schrieb Cédric Krier:
> >>> On 07 Jun 13:59, Udo Spallek wrote:
> >>>> Hi,
> >>>>
> >>>> Fri, 06 Jun 2014 19:27:44 +0200
> >>>> Sergi Almacellas Abellana <[email protected]>:
> >>>>> I have seen in other open source projects that they mark easy issues
> >>>>> in order to ease the introduction of newcomers to the project
> >>>>> development, for example [1].
> >>>>> I wonder if this will be a good idea for the tryton community. Do you
> >>>>> think this will be helpful?
> >>>>> In order to make this happen, this are the required tasks to do:
> >>>>> - Add some type of mechanism in roundup to mark easy tasks.
> >>>> We could use Roundup Keywords.
> >> 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)
> > For me, it is the cost to pay to have the community supports your code.
> > If you don't want, it is fine but you will pay a small part on each
> > release.
> 
> Impossible to work on a patch in stable release? Because sometimes you
> will find a bug while developing something not knowing if it could be
> fixed in trunk. So there are two ways - comprare changes in trunk or
> rewriting your module to work in trunk.

Such must be always done on every supported series. So here you are
again asking for a volunteer to do your homework.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: [email protected]
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

Attachment: pgpGlu4spgsIx.pgp
Description: PGP signature

Reply via email to