User: Password:
|
|
Subscribe / Log in / New account

I'm seeing a serious flaw

I'm seeing a serious flaw

Posted Sep 10, 2009 4:06 UTC (Thu) by jmorris42 (guest, #2203)
Parent article: Developing applications "Quickly"

In the quest to make it simple it just might have been made too simple. Defining an entire project's workflow in a simgle template is asking for trouble.

Already discussing having ubuntu-project and ubuntu-project-with-gconf but it will quickly devolve into:

ubuntu-project
ubuntu-project-with-gconf
ubuntu-project-with-emacs
ubuntu-project-with-emacs-and-gconf
ubuntu-project-with-gvim
ubuntu-project-with-gvim-and-gconf

The KDE users will have nothing to do with the defaults being GTK so

kubuntu-project
kubuntu-project-with-gconf
kubuntu-project-with-emacs
kubuntu-project-with-emacs-and-gconf
kubuntu-project-with-vim
kubuntu-project-with-vim-and-gconf

Then somebody who has an existing project adopts this to manage the ubuntu version while maintaining contact with an existing project repo.... A few more people do likewise an repeat all of the above with:

-and-git
-and-cvs
-and-subversion

And so on. Then a few Fedora folk pick up on it and repeat all of the above replacing ubuntu with fedora.... then debian, suse, etc. Bug fixes and improvements to base templates will start failing to make it into the more obscure variants and everything blows up.

The word for this is combinational explosion and the solution is to realize what is going to happen and break the template into pieces now and have the project sane default along with user local preferences for things like editors, default UI toolkit for new projects, etc.


(Log in to post comments)

I'm seeing a serious flaw

Posted Sep 10, 2009 5:22 UTC (Thu) by drag (guest, #31333) [Link]

It does not necessarily have to be like that. The nice thing about having a templating system done right means that you can have a mixture of templates.

As far as the editor stuff goes... the easy thing to do there is honor the $EDITOR variable, or the XDG .desktop specifications for mime types, like every other decent program does.

As long as the developers concentrate on maintaining core templates and making sure those always work and not to do anything really wild and break backwards compatibility to much, AND keep the templating system as simple as possible and well documented then the rest of everybody can fend for themselves for their little nit picks like favorite editor or preferred DCS. You'll end up with something that is easily extensible like Firefox, Emacs, or Vim.

It does not have to be everything to everybody. Remember the point is to get something up and running quickly. That is 90% of the work.. after that then it's just a matter of customizing the last 10%. and only really experienced people are going to give a damn. :)

I'm seeing a serious flaw

Posted Sep 10, 2009 6:41 UTC (Thu) by didrocks (guest, #57449) [Link]

>As far as the editor stuff goes... the easy thing to do there is honor the $EDITOR variable, or the XDG .desktop specifications for mime types, like every other decent program does.

-> That's already the case in fact (it's using sensible-editor too). We had a comment from an user telling us "sweet, I typed quickly edit and it opened emacs" :).
The failsafe if nothing is specified is gedit

>It does not have to be everything to everybody. Remember the point is to get something up and running quickly. That is 90% of the work.. after that then it's just a matter of customizing the last 10%. and only really experienced people are going to give a damn. :)

->Exactly, that's why we made default choices and as usual, choices are controversial. But people can help and ship their own default, starting from an existing base.
As of today, Quickly core and Quickly ubuntu-project template are two separate packages. We could imagine one package by template and playing on the plugin side as you mentioned.

I'm seeing a serious flaw

Posted Sep 10, 2009 21:53 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

Before I move on to criticism let me say that I think quickly looks like a reasonable good approach for rapid development for interpreted languages. It will be interesting to see how it develops and there is pressure to build up a more feature rich IDE interface on top of its core functionality.

But on to the criticism....I think name spacing at the distribution level is probably short sighted as a policy model to follow. Now GNOME and KDE namespaces for templates make sense...as these upstream projects do define a framework on which to hang applications. What does it mean to be a fedora project or an ubuntu project or a debian project really?

Distributions do not define a technology framework. I understand that Canonical is pushing launchpad backed bzr and desktopcouch pretty hard because they think they are best of breed technologies...and I respect that. But does it make sense to brand that combination of technologies as Ubuntu specific? And then to encourage other distributors to brand a different stack of technologies as yet another template and have competing technology frameworks? I don't think it does. For new projects, a distribution specific namespace is an arbitrary definition at best. At worst its going to end up being a barrier to adoption across distribution boundaries. What independent project writer really wants to see their end-user application bound up in distribution specific naunces or dependant on distribution patches to upstream codebases? Amd what I would really hope that Canonical realizes is that pushing technologies like desktopcouch needs to be done in a brand agnostic fashion. The last thing Canonical needs is for a competitor to think of desktopcouch as Ubuntu-centric...and then introduce a competing framework for application writers to choose.

-jef

I'm seeing a serious flaw

Posted Sep 11, 2009 6:01 UTC (Fri) by drag (guest, #31333) [Link]

The only really Ubuntu-specific things I noticed was the integration into
Launchpad and PPA's... both of which do not really have a equivalent in other
distributions. Sure you have bug track and things like that, but PPA allows
people to setup their own personal repositories easily and have other people
use them. I can't really see that as anything but a nice feature.

Otherwise everything else seems to be distro agnostic, except you'd have to
replace debs with rpms, but that should not be a big deal.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds