-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Noah Kantrowitz skrev 30-05-2008 19:28: |> -----Original Message----- |> My preferred route for functionality like this (and MasterTicket / |> Dynamic Report Variables / etc) would be to bless some plugins with |> auto inclusion into the trac install (disabled by default). I greatly |> value that trac is simple to use. I recently helped teach a Software |> Engineering class that made use of trac. I feel that it could not |> have been used if it was more toward the bugzilla side of issue |> tracking (way too complex for a first go at software management). |> That said, part of the project was to estimate and track time (which |> is convenient since I wrote the plugin). I am sure that others will |> want to have only ticket dependancies and not time tracking, or only |> custom reports with a variable filling form. All of these are |> essential for the group of users that need them and the system cannot |> be complete without them. By blessing and including these plugins |> with trac we can keep the simplicity, while easily enabling plugins |> that fill out the functionality we need. | | I agree with this approach. Keep the Trac codebase small, and just bundle | snapshots of some plugins (perhaps determined by community voting once t-h | gets moved to 0.11) along with a set of release media. If people want new | versions of those plugins, they can upgrade, but this is enough of a stopgap | until ... | |> One thought I have been kicking around is a package management plugin |> for trac that would be able download and install a plugin and update |> trac from the web admin screen. But this would really need to be |> included in Trac (or as a blessed / pre-included plugin) to alleviate |> the same frustrations that users are expressing in this thread. With |> a package manager and "blessed" plugins, I think that the |> disagreements over what functionality should be included by default |> can be mitigated to some extent. | | ... we really fix the problem with a 1-click plugin installer. I have been | working on this for quite a while now, and have hit a large number of brick | walls. The short version is that we need to fork PyPI (TracPI or something) | because I can't get the catalog-sig to acknowledge any patches I send them. | This would be a part of the long-fabled trac-hacks++ Alec and I have been | discussing over the last year or so. I think this installer will solve the | _real_ problem people are having. Its not that lots of plugins are a bad | idea, they are just annoying to get working. Put this installer in Trac | core, and you get the experience I think everyone wants.
Caveat: I'm *not* a trac developer, I've barely scratched the surface of some ~ plugins ~ However, I do manage a few small-to-medium trac installs, recently ~ migrated from 0.10 to 0.11 My take on this is that: a) keeping trac core simple is a good idea b) having essential features in plugins is a good idea ~ 1) It implies anyone can add essential functionality that ~ they require without having to fork trac - because a solid ~ plugin api is available ~ 2) any such improvements should be relatively easy to reuse These two points are just arguments for avoiding tight coupling, and stimulating code reuse. But what I think Trac need, is a proper framework for futureproofing plugins, and make it easy for developers/maintainers to implement automatic updates. I understand the pre 1.0 releases have an unstable api -- but a plugin upgrade path will still be needed from 1.0 to 2.0 etc. I'm not sure if pypi is the perfect model -- I think eggs work great, and some kind of repository standard would be nice (preferably something simple along the line of Debian's Aptitude -- all you'd need for hosting a mirror is a webserver). What I'd like to see is a model where new releases of trac (like 0.10 -> 0.11) come with a migration script that also automatically wraps plugin updates (provided a plugin has been ported to the new version). Something along the lines of: Upgrade trac: 1) shut down running instance 2) upgrade core 3) migrate wiki, database etc if necessary 4) for each plugin: ~ a) check metadata for a source/ search in a global repository ~ b) if an upgrade exist: ~ i) download ~ ii) run pre-install code that: ~ * upgrades datamodels, transforms wiki-references ~ * fixes workflows etc ~ * upgrades plugincode ~ c) if no upgrade exist - disable plugin ~ * note there should be stage 0) that checks all plugins for compatability So, the main difference between this, and throwing all eggs under pypi-control, and just running easy_install -U would be a defined framework/api for providing migration-scripts integrated in the plugin-bundles, that does something sensible with your legacy data/install if needed/possible -- and is able to give a warning if what you're about to do will hopelessly break your install. On a side note, it would be nice to have a simple robust way for setting up local mirrors, hosting plugins etc -- again something along the lines of aptitude (and probably pypi -- as I said I'm not quite sure how that stuff really works). I'd also like to see some an installer or something along those lines that would allow one to do: ~ trac-install [--with-plugins=plugin1,plugin2(...) ~ [--use-local-files=/tmp/plugin1.egg ]] And maybe even: ~ trac-install --with-suggested-plugins If i understand you correctly Noah, this is similar to what you have in mind (if we have a well-defined repository adding support for listing available, compatible plugins in webadmin would probably be 3 lines of code, or so -- it's not exactly rocket science). So, again -- what I think we really need is some easy way for plugin devs to implement automatic updates -- and a framework for automating such upgrades in a "runnning" trac -- as well as an easy way to install trac with the plugins one needs. The only type of features I think should go into trac core, is the kind that expands available metadata and apis in a reasonable way, that would be useful to have work across many different plugins. Webadmin is a perfect example of this -- all plugins will need to expose various configuration settings via the web ui -- so having simple hooks for that in trac makes sense. Best regards, - -- ~ .---. Eirik Schwenke <[EMAIL PROTECTED]> ( NSD ) Harald Hårfagresgate 29 Rom 150 ~ '---' N-5007 Bergen tlf: (555) 889 13 ~ GPG-key at pgp.mit.edu Id 0x8AA3392C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQvUtxUW7FIqjOSwRAkg/AKDTbXE2zd2vLC+DGFUDWPPt5Tq8JACfQF5O ZBcQVhez4wYiKi5aPwf06G0= =nYY1 -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
