openerp-community-leaders team mailing list archive
-
openerp-community-leaders team
-
Mailing list archive
-
Message #00032
Re: Simple things we need from Tiny for better bug planning/management
A Dijous, 21 de gener de 2010, Raphaël Valyi va escriure:
> Albert,
>
> if we do so, say in Mars 2010 and we have a good parallel 5.2 and Tiny
> their own 5.2 too. If there is a big delta on fundamental things like how
> to handle rounding, how modules are split together (not sure the
> tax_include modules are worth as externals, not sure, mrp should depend on
> hr just because of a single field...), so I mean, in Mars 2010 when Tiny
> will say 5.2 get frozen and it's really different from our collective
> partner/experts 5.2, what do we do? This is my only concern because it is
> the path to a fork and I doubt a fork other than Tryton is a good thing, I
> have no reason to believe some leader will drive it better than Tiny
> overall, ERP is not like a CMS or a framework, almost nobody can carry
> such a project alone... Indeed, once we deployed a lot of those parallel
> versions on our customer projects and they will do the work, who will
> afford getting back to an official broken version?
Well, my idea was to only handle this for stable version... what do others
think about this?
>
> I mean I'm hot for that kind of collective/expert work but only if we have
> some guaranties with Tiny this is not a dead end.
>
> Raphaël Valyi
> http://www.akretion.com
>
>
> 2010/1/20 Albert Cervera i Areny <albert@xxxxxxxxxxx>
>
> > A Dijous, 21 de gener de 2010, Raphaël Valyi va escriure:
> > > Thoughts?
> >
> > I think if we created a stable community branch we could:
> > - Get the same fixes tiny is currently doing (those 10 commits a day).
> > - Because of the "two-step" commits we would revise, discuss and maybe
> > detect
> > some of the regressions that are getting in. (The rounding stuff is not a
> > matter of a regression introduced by a programming error. Either OpenERP
> > can't
> > handle some cases the patch is trying to solve or somebody with commit
> > permissions does not know how that works!)
> > - I think most or all patches should have to be discussed in the list. I
> > know
> > it's a lot of work, but it could possibly be worth.
> > - It opens the door to those that don't want to/can't have their own
> > branch (like ourselves) to share resources.
> > - It may reduce the number of resources that those that do have their own
> > branch need to keep it up to date.
> > - If we do the work well, tiny can pretty much relay, review and merge
> > patches
> > from a single branch (not 10s).
> > - They won't receive so much pressure because we currently have our own
> > branch. Tiny can release at their own pace.
> >
> > We all have our own points of view, but there are lots of open source
> > communities out there doing it. We won't always agree but I think we can
> > try
> > it. If meanwhile Tiny solves it's issues and can work as they intend,
> > that's
> > just perfect. If they don't succeed, we won't have lost two months more
> > waiting for them to put a solution on this. I don't think we can put all
> > the
> > responsability to them.
> >
> > Of course, there's nothing that ensures this will work. But note that
> > current
> > approach doesn't work either.
> >
> > BTW, about the marketing stuff, I don't think having a strong community
> > can be
> > bad in any sense. If this approach works it will result in better code
> > and functionality which is the best marketing there is...
> >
> > Just my 2 cents..
> >
> > > Raphaël Valyi
> > > http://www.akretion.com
> > >
> > >
> > >
> > >
> > > 2010/1/20 Albert Cervera i Areny <albert@xxxxxxxxxxx>
> > >
> > > > A Dimecres, 20 de gener de 2010, Raphaël Valyi va escriure:
> > > > > Hello,
> > > > >
> > > > > The community doesn't spend a lot of time currently on bug planning
> > > >
> > > > because
> > > >
> > > > > we still can't do it efficiently unless you do what I list here:
> > > >
> > > > snip
> > > >
> > > > > I talked about that with Fabien, Quentin and Christophe and we all
> > > > > agreed that we need some scheduled released at least (like one per
> > > > > month or per
> > > >
> > > > 2
> > > >
> > > > > months, this is up to you but I personnaly prefer one per months to
> > > > > make users benefit the more possible bugfix), so why is that not
> >
> > done?
> >
> > > > > Can't
> > > >
> > > > you
> > > >
> > > > > do it? We community have no admin rights neither authority to do
> > > > > the schedule nor the releases.
> > > >
> > > > Maybe it would be better for tiny and the community to have one
> > > > openerp-server
> > > > and openerp-addons branches owned by community-leaders or another
> > > > restricted
> > > > group that would do their own priorization and schedules? I'm not
> > > > sure, about
> > > > this, but sometimes not being able to fix some things really slows
> >
> > things
> >
> > > > down. We currently can get faster (better?) feedback from these new
> > > > mailing lists than from Tiny (they have their resources and
> > > > priorities which I understand).
> > > >
> > > > --
> > > > Albert Cervera i Areny
> > > > http://www.NaN-tic.com
> > > > Mòbil: +34 669 40 40 18
> >
> > --
> > Albert Cervera i Areny
> > http://www.NaN-tic.com
> > Mòbil: +34 669 40 40 18
>
--
Albert Cervera i Areny
http://www.NaN-tic.com
Mòbil: +34 669 40 40 18
Follow ups
References