gtg team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

That code is now out of trunk and I'm writing it as a plugin. It should
be the best solution.
On Thu, Dec 03, 2009 at 12:34:30PM +0100, Bertrand Rousseau wrote:
> On Thu, Dec 3, 2009 at 11:03 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> >
> > Anyway, currently, there's one major concern : Luca cannot undo his merge
> > because he merged the trunk in his branch, not the opposite.
> >
> > I reverted Luca's revert as it was undoing everything since the branch
> > started (including bugzilla and tomboy plugin).
> >
> > So here, I foresee two solutions :
> >
> > 1) We play bazaar subtleties to try to undo Luca's merge
> > 2) We accept it and try to gradually change the problems.
> 
> Let's go for solution 2, there's no need to loose too much energy in
> that, that's not worth it. Besides, let's use this as a motivation to
> go forward. However, it could certainly be nice to avoid this in the
> future.
> 
> > The only drawback of solution 2 is that, for now, the trunk depends on
> > cheetah.
> 
> If it's fine for everyone I suggest reworking the code to remove
> cheetah dependency, and at least, try first to build up a solution not
> needing it.
> 
> > I think my previous mail regarding bzr rules should be put on the wiki to
> > avoid this situation in the future. I'm a bit surprised that bzr allows to
> > change the history so easily. It already happened a lot of times (I even
> > did it myself) but it not so annoying because it was only tiny changes.
> >
> > So, to all committers : be sure to read and to understand my previous mail
> > about bzr.
> >
> >
> > Lionel
> >
> > PS : Luca, don't worry about that. Not a great deal. Only those who don't
> > make anything don't make mistakes. We only have to be careful so it doesn't
> > happen anymore in the future.
> >
> >
> > On Thu, 3 Dec 2009 10:41:49 +0100, Bertrand Rousseau
> > <bertrand.rousseau@xxxxxxxxx> wrote:
> >> Well my point is more that I think we could do this without needing
> >> cheetah, or at least I would like first to know what future
> >> functionalities could bring cheetah, in a strategic point of view. And
> >> don't get me wrong: I'd also be very glad to have this in 0.2, and I'm
> >> ready to help for it.
> >>
> >> Among your solutions, my present opinion is to follow number 4: having
> >> a set of basic templates that don't depend on cheetah, and having a
> >> separate plugin called "Support for cheetah export templates" that
> >> would allow powerful export capabilities.
> >>
> >> On Thu, Dec 3, 2009 at 10:21 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> >>>
> >>> I'm personally not against the dependency and I definitely hope to see
> >>> the
> >>> export feature in 0.2. I don't think that the fact that cheetah is
> > mainly
> >>> used for web dev should be a factor. Most users don't understand the
> >>> dependencies (which user could explain why he needs to install
> > configobj
> >>> before installing GTG ?)
> >>
> >> Dependencies have/should never been/be a user concern. They are just a
> >> burden for distribution and maintenance, which also has to come into
> >> account.
> >>
> >>> One easy solution would be to have a plugin.
> >>>
> >>> So, for 0.2, I see the following solutions :
> >>>
> >>> 1) We drop the export feature (it would be really sad to do that only
> >>> because of a dependency. I'm strongly against it)
> >>> 2) We add the dependency and write about it in the release note
> >>> 3) We put the whole export feature in a plugin (our plugins already
> >>> handle
> >>> dependencies)
> >>> 4) We have the export features works alone but only have some templates
> >>> depends of cheetah. Those templates could then be packaged as plugins
> > and
> >>> their dependencies would be handled automatically.
> >>> 5) Disable the export feature if cheetah is not found.
> >>>
> >>> In fact, the idea I have is to make each export template a plugin. That
> >>> way, it would be easy for people to develop their own templates and you
> >>> can
> >>> imagine more complex templates (with pre and post processing commands).
> >>>
> >>> My choices, in order :
> >>> 4 - but maybe not possible for 0.2
> >>> 2 - IMHO, export should not be a plugin, it's a core feature
> >>> 5 - Not discoverable but better than nothing
> >>> 3
> >>> 1
> >>>
> >>>
> >>>
> >>> For now, I'm more concerned about the revert of Luca. Because the
> > initial
> >>> merge was a bit unorthodox, are you sure that the revert only reverted
> >>> your
> >>> work? Are the other commits (like Kevin fix for drag-n-drop crash)
> > still
> >>> in
> >>> trunk ?  This is, IMHO, way more important than the dependency.
> >>>
> >>> Lionel
> >>>
> >>>
> >>> On Thu, 3 Dec 2009 09:56:39 +0100, Bertrand Rousseau
> >>> <bertrand.rousseau@xxxxxxxxx> wrote:
> >>> > (sorry for the double mail Luca. I always forget to use reply all)
> >>> >
> >>> > On Thu, Dec 3, 2009 at 9:21 AM, Luca Invernizzi
> >>> > <invernizzi.l@xxxxxxxxx>wrote:
> >>> >
> >>> >> Uhm, I just pushed the code to trunk.  I believe that the benefit of
> >>> >> having the possibility to export the list in any way you want
> >>> >> overcomes
> >>> >> the downside of the added dependency. This is a feature that the
> > other
> >>> >> task editors do not have.
> >>> >>
> >>> >
> >>> > Sure, but this feature doesn't require a full-blown templating system
> >>> IMHO.
> >>> > Users could as well create python-based code generators, we could
> > just
> >>> > agree
> >>> > on what data structure is passed, that wouldn't be a lot harder to
> > do.
> >>> > Creating such code generator is not complex. I've already done many
> >>> times
> >>> > to
> >>> > generate simple to complex files.
> >>> >
> >>> >
> >>> >> Just try it. If you don't like it, I'll remove it.
> >>> >>
> >>> >
> >>> > Well, I certainly think your export feature is awesome. I could try
> > it
> >>> some
> >>> > hours ago, and it sure adds a great potential to GTG (we are clearly
> > in
> >>> > need
> >>> > of an export feature). But for me it's not worth an added dependency.
> >>> > Besides, as 0.2 is now a matter of days, I don't think it is wise to
> >>> > add
> >>> a
> >>> > new dependency now, since that should be more extensively discussed
> > to
> >>> > assess its advantages and inconveniences. So I'm personally more in
> >>> favor
> >>> > of
> >>> > introducing a simple python-based templating system for 0.2, and not
> >>> > cheetah.
> >>> >
> >>> >
> >>> >> Luca
> >>> >> On Thu, Dec 03, 2009 at 09:16:08AM +0100, Bertrand Rousseau wrote:
> >>> >> > Hi,
> >>> >> >
> >>> >> > Cheetah is a very nice templating system, I've already used it.
> > It's
> >>> >> > powerful and well written.
> >>> >> >
> >>> >> > However I'm not very fond of adding such a dependency to GTG, it
> >>> feels
> >>> >> > a
> >>> >> bit
> >>> >> > out of place for an organizer to depend on an app that is
> > generally
> >>> >> > used
> >>> >> for
> >>> >> > web development, and I fear people would be a bit astonished about
> >>> >> > having
> >>> >> to
> >>> >> > install such a powerful feature for an organizer (I would).
> >>> >> >
> >>> >> > On Thu, Dec 3, 2009 at 3:09 AM, Luca Invernizzi
> >>> <invernizzi.l@xxxxxxxxx
> >>> >> >wrote:
> >>> >> >
> >>> >> > > Sorry for the double mail. Cheetah is:
> >>> >> > > - in active development
> >>> >> > > - stable since 2001
> >>> >> > > - used (http://www.cheetahtemplate.org/whouses.html ,
> >>> >> > > http://linuxgazette.net/ uses it)
> >>> >> > > - small (200k)
> >>> >> > >
> >>> >> > > So I believe it's a good dependency
> >>> >> > >
> >>> >> > > On Wed, Dec 2, 2009 at 3:58 PM, Luca Invernizzi <
> >>> >> invernizzi.l@xxxxxxxxx>
> >>> >> > > wrote:
> >>> >> > > >
> >>> >> > > > Hello,
> >>> >> > > > for the export/print function I'm currently writing
> >>> >> > > (lp:~gtg-user/gtg/export), I'm looking into using cheetah (a
> >>> template
> >>> >> > > interpreter in python), just to avoid reinventing the wheel.
> >>> >> > > >  That means adding python-cheetah to gtg dependencies. Is that
> >>> >> > > > ok
> >>> >> with
> >>> >> > > you?
> >>> >> > >
> >>> >> > > _______________________________________________
> >>> >> > > Mailing list:
> >>> >> > > https://launchpad.net/~gtg<https://launchpad.net/%7Egtg><
> >>> >> https://launchpad.net/%7Egtg>
> >>> >> > > Post to     : gtg@xxxxxxxxxxxxxxxxxxx
> >>> >> > > Unsubscribe :
> >>> >> > > https://launchpad.net/~gtg<https://launchpad.net/%7Egtg><
> >>> >> https://launchpad.net/%7Egtg>
> >>> >> > > More help   : https://help.launchpad.net/ListHelp
> >>> >> > >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > Bertrand Rousseau
> >>> >>
> >>> >> -----BEGIN PGP SIGNATURE-----
> >>> >> Version: GnuPG v1.4.9 (GNU/Linux)
> >>> >>
> >>> >> iQIcBAEBCAAGBQJLF3UKAAoJEJwV7kAnLtWzXTEQAKfXttMeq4MGY9x8DyZResxh
> >>> >> XpLMuZcvFOYeA9pt3u0eKvhTG7Snx9r4FEfbkjFDBcBpfO0eqbxx5gTlm3LYvGk1
> >>> >> /995U30hLcDBN2jYhYH2qOici0LsxAQbFthh+19G5zxVsvgBdIqtuALPo3HPGRJg
> >>> >> xakYLv/HeLa7ErEFNivF/oWMVfUDQykx2qkgERJwWjZgqTATFn41K3xFkUjMENOW
> >>> >> +Fj4vqX38DsZbsgr9Do+beJh7WBeyL7X+SXkpZ15rodK3f2dF77ZN4XSyxlfhsfZ
> >>> >> rIjq3JMYcDz4P62b03PLrMM+rBsLXGW+v1B49qsAHxuMAaZVwvYbB5FeAFrlflsY
> >>> >> r8gF+pJa59R6TwdLflM0gjZRr3bj+YO/7x+4rd5odlo172f9F3ZeieiQ8QDjp4cS
> >>> >> 52YwV1ID7uXDlTD5uYabvXhnI7vxLVCa4yXsELFY8mDmSKtBr6/jc8okOD7jAyk0
> >>> >> Sjr+3DiaAFux/kP8RXBaSRXrg8q5EfTNTulm8bPvCFoDEGpKTHtn/wYj4V5AqNJB
> >>> >> DtJkQBm8CrXliuOw3BhSsk1SWaAycTDiMyULbF9ts9vWffHHy7YB7ZHLOXS7A0IU
> >>> >> 5LAVZ72f7Y+91m0AG8LDH/jj2fEjbdfXeZf88r/6TXVuWxrj3Vyoedd6HxT/tCFc
> >>> >> PzOPmqDn1aJ59C4JDLbP
> >>> >> =1fxa
> >>> >> -----END PGP SIGNATURE-----
> >>> >>
> >>> >>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~gtg
> >>> Post to     : gtg@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~gtg
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> --
> >> Bertrand Rousseau
> >
> 
> 
> 
> -- 
> Bertrand Rousseau
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg
> Post to     : gtg@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: Digital signature