[Labs-l] Hello, and the short term plans

[Tim Landscheidt]

"Marc A. Pelletier" <marc at uberbox.org> 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 <lists at schwen.de> 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