"Marc A. Pelletier" <[email protected]> wrote: >> This may be overkill for some libraries, and you can emulate >> the package management provided by the OS with a bunch of >> ad-hoc scripts and very strict SOPs, but in a environment >> where all boxes will run Ubuntu and knowledge about Debian >> packaging is relatively widespread, I think going the extra >> mile (well, rather yard) is definitely worth it.
> That's an interesting approach. Something along the lines > of a "Tool Labs PPD" then that relies on puppet for > deployment? "PPD" = "Perl Package Manager"? No, I thought of run-of- the-mill .debs that could be pushed to Debian/Ubuntu as well for users outside Labs. > There are clear upsides, there, but I see two hurdles that > need to be considered: > 1) what of tools that want or need to use different versions > of the same asset; and > 2) who gets to update that package (i.e. who decides when to > pull and build)? > The alternative, storing the shared code in gerrit, means > that the individual tools simply clone "locally" and can > merge or cherry-pick as needed. > [...] Then I had misunderstood you and Magnus. I thought you were proposing one shared directory per library. Storing code in a some form of SCM is a no-brainer. So based on my wrong assumption the answers would be: Those who decide what changes would occur in this shared direc- tory. Daniel Schwen <[email protected]> wrote: > [...] > Yeah, I don't like where this is going. > When the design for tool labs is made by "admin"-people that want > everything puppetized and packaged and what not you will screw the > "hacker"-people that probably are the majority on the ts right now. > While a "hacker" mentality can create quite a bit of chaos, it also > provides a flat learning curve and lowers barriers to "just try > something" and do stuff. Many tools are the product of a quick idea > that people want to see implemented _fast_ before the that initial > surge of motivation is gone and nobody on-wiki is interested anymore. > I've already stared in horror the discussion on the webtools project, > which to me (and this is just a very subjective opinion) seems overly > academic and out of touch with the user community. > Part of what makes the TS great (at least for me) is the possibility > for experimenting and ad hoc development. I don't think it would be even technically possible to stop hackers from deploying libraries locally :-), so development will (and should) never be impeded. But once that initial surge of motivation is gone and a tool goes into maintenance mode, I think it's much easier to keep ten libraries project-wide up to date with security fixes and changes in the MediaWiki API than to do the same for 1000 individual tools. Tim _______________________________________________ Labs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
