Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Stephan Hermann]

On Tue, Aug 19, 2008 at 02:01:26PM -0700, Mathias Gug wrote:
> What are you referring to by package ?
> 
> The make a parallel with python, the gem command is similar to easy_intall.

And ezinstall is broken by design for a binary distro and for endusers.

ezinstall doesn't check if there is the correct version somehow
installed, but downloads from questionable sources (!) .egg files.
Most likely we (as packagers) are patching this away.

> Neil's proposal is to improve the gem command (from the libgems-ruby
> package) so that binaries are installed in /usr/local/bin (thus they're
> on the default path). If you'd use install gems from the upstream
> source, binaries would be installed in /usr/bin/. The goal is that gems
> installed by the gem command don't interfere with ruby libraries and
> binaries installed by debian packages.

Don't Use Another Package System Then The One From The Distro !

Gem is just another broken package management system for ruby.
Pear is just another broken package management system for php.
ez_install is just another broken design fullfill dependency management
system for python.
I think there are others I forgot to mention.

Gem packages are even more dangerous because they are delivering
sometimes also binaries...which can break your current installation of
the stable distro you use.

Everytime I have developers in my real life work who are trying to
convince me to use this system, I rather try to let them stay in front
of a wall and do the chinese way of getting rid of those devs. 

Mostly I'll go and try to package it in a sane way, the way of my used
distro. It will be more difficult but it helps the user and in this case
mostly the user is the sysadmin.

Developer, who are in need of the newest crack for their development can
use gem or pear or ez-install without being unhappy when they destroy
their system, they are developer, and they should know what they are
doing. (Today this is difficult to say, because most developers don't
have a clue what they are doing anyways, only when they are involved in
distro specific workflows they know about the problems).

I think we don't need another way of handling gem, we just need the time
to package all this broken gem crack..

\sh
-- 
Stephan '\sh' Hermann   | OSS Developer & Systemadministrator
JID: [EMAIL PROTECTED]  | http://www.sourcecode.de/
GPG ID: 0xC098EFA8  | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Stephan Hermann]

On Tue, Aug 19, 2008 at 05:21:21PM -0400, Scott Kitterman wrote:
> [...]
> 
> Well then I guess I'm left feeling like this is the unwritten "Server Team 
> need not apply" rule.
> 
> When I've brought this up about people who were active in #ubuntu-desktop, 
> but not #ubuntu-motu my concerns were dismissed.
> 
> I feel like it's a clear double standard.

I think we have some social problems here...

In the past, we didn't have those teams in the first place, so the very
first step was to do work in Universe...and it didn't matter what
packages we were interested in. We were doing anything...

Now we have different, specific teams, like server team, desktop team,
mozilla team, mobile team, what have you team, and many people are not
interested anymore in doing general universe package work, but are
interested in specific packages. 

Nowadays we see that happening, and yes, the distinction of universe
and main is questionable. But, people are just being pushed to MOTU team
to get their upload rights, but are not working with people from MOTU or
do some other work then their work they are interested in.

So, we have problems.

1. Most MOTUs won't know people coming from the specialised teams.
2. Those people are not interested to work for anything else then their
pet packages
3. Universe work will lose menpower, and the whole workflow becomes
questionable.

I agree, that working on particular packages is more fun, because it can
help you in your daily real life work or whereever. But having still the
universe/multiverse component, it's important that we recrute people
who are interested in doing "general" work too.

Therefore, I can understand the two viewpoints: 

a) Who is this guy, I never saw him doing any work on Universe in
general, only on those packages which are somehow split up in main and
universe.
b) We need this guy, because he's da rockstar for desktop/server/mobile
etc.

I wonder if it's time to review the whole universe/multiverse
main/restricted system...but I do see already one problem with it: more
packages won't be in the view of anyone. We will get more people working
on their favorite area (the specialised teams), and less people are
working on the more general side of ubuntu life.

Furthermore, it will be more and more difficult to judge for people we
don't know, because we never worked with them.

I don't think it's a "personal problem" but more a general problem
between the people not being inside the motu team, but doing great work
in their specialised teams.

We need to fix it...we should review our policies.

Regards,
\sh
-- 
Stephan '\sh' Hermann   | OSS Developer & Systemadministrator
JID: [EMAIL PROTECTED]  | http://www.sourcecode.de/
GPG ID: 0xC098EFA8  | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Stephan Hermann]

On Wed, Aug 20, 2008 at 07:23:27AM +0200, Reinhard Tartler wrote:
> Phillip Susi <[EMAIL PROTECTED]> writes:
> 
> > If you run into a package that does not already have some kind of
> > patch system there are 2 possibilities:
> >
> > 1)  The package has never needed to be patched before
> > 2)  The package has been patched by directly modifying the original
> > upstream files, which is a big no-no
> >
> > In the second case, the package should be fixed and the upstream debian
> > maintainer notified and asked to repair their broken package as well.
> 
> In that case, I kindly ask you to not touch any of the package I
> maintain in debian. I very much prefer managing patches to sources using
> a VCS, and adding patch system adds unnecessary noise in the debdiff.
> 
> I really wonder who brought up the (wrong) claim that *not* using a
> patch system was deprecated in the first place.

I think the problem is, that many people don't know, that debian
source packages do have this diff.gz handling, which is also a "patch"
system. Not the best one, but actually it works.

A debianized source tree (with debian/ already applied) can be changed
outside debian/ dir and those changes are going in the resulting
diff.gz. No orig.tar.gz source is being touched.

I do the same...a source package which doesn't have a patch system (like
dpatch, cdbs-simple-patchsys, quilt, or even dokos python patch system
,-)) applied, will go with diff.gz. Or, if it's possible and I have the
time, I'll get a VCS branch and do what the debian maintainer did.

As Lars said, we have everything in place...

Only packages I introduced in Ubuntu will have explicit patch system in
future (like I did now e.g. for zend-framework). So others and
especially I can track the patches I applied from upstream.

Regards,

\sh
-- 
Stephan '\sh' Hermann   | OSS Developer & Systemadministrator
JID: [EMAIL PROTECTED]  | http://www.sourcecode.de/
GPG ID: 0xC098EFA8  | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Reinhard Tartler]

Phillip Susi <[EMAIL PROTECTED]> writes:

> If you run into a package that does not already have some kind of
> patch system there are 2 possibilities:
>
> 1)  The package has never needed to be patched before
> 2)  The package has been patched by directly modifying the original
> upstream files, which is a big no-no
>
> In the second case, the package should be fixed and the upstream debian
> maintainer notified and asked to repair their broken package as well.

In that case, I kindly ask you to not touch any of the package I
maintain in debian. I very much prefer managing patches to sources using
a VCS, and adding patch system adds unnecessary noise in the debdiff.

I really wonder who brought up the (wrong) claim that *not* using a
patch system was deprecated in the first place.

> In the first case, if you are going to start patching you need to use
> one of the patch systems to do it. 

I disagree with the necessity with doing that. And I strongly disagree
telling Debian Developers to use one.

However, after reading this thread a bit more, I can agree that adding a
patch system can make sense if the following applies:

 - the package does not have any source patches outside debian/ yet
 - the package can trivially extended with a patch system
 - the patch is not trivial

Rationale: It does not really make sense to introduce quilt or dpatch
for a 2 line manpage patch. that can very easily obtained using
filterdiff on the diff.gz.

For more complicated patches that really need commenting, I can see that
patches really should be documented. E.g. I have been doing that in the
ffmpeg package, cf. the patches in [1].

http://svn.debian.org/viewsvn/pkg-multimedia/unstable/ffmpeg/debian/patches/

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Steve Langasek]

On Sat, Aug 16, 2008 at 11:31:27PM -0700, Jordan Mantha wrote:
> On Sat, Aug 16, 2008 at 9:49 PM, Nicolas Valcarcel
> <[EMAIL PROTECTED]> wrote:

> >Currently there is no policy about how to make changes in the 
> > packages,
> > there are some good practices and a lot of developers try to use patch
> > systems whenever they can and don't touch the source code outside
> > debian/ directly, but that's still at the developer's discretion.
> >For that reason i wanted to start a discussion on the topic, to start
> > working with debian on preparing the packages with a patch system, so we
> > (and other derivatives) can make patches without the need of changing
> > the packaging. Also i will suggest to the revu reviewers to ask the
> > packagers to add a patch system on their packages.
> >What did you think about it? Any comments?

> > 1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195

> I think our job as downstreams is to provide patches to Debian, not
> tell them how to maintain their packages. IMO anyway, it's our
> obligation to either 1) give ordinary diff patches 2) use whatever
> patch system or lack thereof that upstream uses. There are so many
> common ways to patch and maintain a package (debhelper, cdbs, quilt,
> dpatch, svn, git, bzr ...) that I can't foresee a comprehensive,
> archive-wide policy.

> Additionally, IMO again, a primary goal of at least MOTU should be
> minimizing the divergence from Debian. The more changes we make, and
> the more useless they are (bumping standards version??) the more time
> we spend maintaining the divergence and the less time we have for more
> important tasks. Adding a patch system really *should not* be done in
> Ubuntu. If we're maintaining that much divergence we need to talk to
> Debian about how we can better minimize and maintain it.

If you have more than one change to the upstream source of a Debian package,
then you need some system to manage the changes to indicate which parts of
the patch belong to which functional change -- i.e., a "patch management
system".  This can be a set of VCS feature branches, if you prefer (in which
case it's important to use the Vcs-* headers in debian/control in the Ubuntu
upload), or it can be an in-package patch system; but it is important to
have /some/ mechanism for labelling your changes so that you aren't left
with a single massive diff.

If the Debian maintainer already has a patch system in place, it's far
better to continue using that one (no matter how bad it is, sometimes);
otherwise, adding a patch system *should* be done when needed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Emmet Hikory]

Steve Langasek wrote:
> If you have more than one change to the upstream source of a Debian package,
> then you need some system to manage the changes to indicate which parts of
> the patch belong to which functional change -- i.e., a "patch management
> system".  This can be a set of VCS feature branches, if you prefer (in which
> case it's important to use the Vcs-* headers in debian/control in the Ubuntu
> upload), or it can be an in-package patch system; but it is important to
> have /some/ mechanism for labelling your changes so that you aren't left
> with a single massive diff.

Why?  Why should the Debian Maintainer care about the monolithic
patch as applied in Ubuntu (perhaps also cluttered by several
changelog entries about merges that have happened, or rebuilds).  Is
it not best practice to send those patches relevant to Debian to bugs
in the BTS, as separated patches?  If this is done, to whom is it
useful to track the patches independently, so long as the patches
remain easy to maintain?

> If the Debian maintainer already has a patch system in place, it's far
> better to continue using that one (no matter how bad it is, sometimes);
> otherwise, adding a patch system *should* be done when needed.

I generally argue against the introduction of patch systems, as 1)
I am very much opposed to working with a package that has both changes
in diff.gz (from the original packaging), and 2) a patch system.
These are painfully ugly, and the monolithic diff frequently becomes
completely unreadable (was this a change to a previous Debian change,
to an upstream change, or to a combination?); and 2) I have heard a
number of Debian maintainers complain about the "useless" introduction
of a patch system when they maintain the package in a VCS with no
patch system.  That said, in the case where there are no previous
diff.gz changes external to debian/, I think it is best practice to
review other packages with the same Debian Maintainer to attempt to
determine the preferred patch system of that maintainer (which may be
monolithic diff.gz), and follow that practice.  In the rare case where
there are no patches external to debian/ in any of the packages
maintained by that Maintainer, the introduction of a patch system
seems the least bad way to do things, but this is very much an
exceptional case, and for most packages we would do well to instead
follow the existing practice (even where that is a monolithic
diff.gz).

-- 
Emmet HIKORY

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Emmet Hikory]

Scott Kitterman wrote:
> For a legalistic reading of policy, I think there is nothing wrong with that,
> but how is a typical user of a gem going to know that if they install gem X a
> library used by gem Y, Z, and package A will be replaced/overridden?  As a
> practical matter I think this declares it all to be the sysadmin's problem
> without giving them a way to know what risk they are taking or how to manage
> it.
>
> As I said in an earlier message in the thread it seems very like Windows DLL
> hell.  Hopefully it will mature.  I doubt that as a distro we can do much to
> improve this where it is now.

Indeed.  The use of gems in this way on an end-user system is
bound to create problems, of the same sort (as previously pointed out)
of end-user use of cpan, ezinstall or maven.  That said, policy
specifically doesn't forbid the use of such tools by end-users, and we
do have support for upstream behaviour for all of cpan,  ezinstall,
and maven.  Creating correct upstream behaviour for gems as well, in a
manner that doesn't damage the areas typically managed by the
packaging system, is a good thing.

Of course, such support cannot be used to build policy-compliant
packages, and so any gem that is packaged and has dependencies will
require either a patched gem install to handle it, or an alternate
build system to be put in place.  Ideally, for a given release, all
interesting gems would be packaged and be immediately available for
use: further users would be encouraged to use the gems from the
repositories (as is done for perl, python and Java).

-- 
Emmet HIKORY

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Scott Kitterman]

On Tuesday 19 August 2008 19:56, Mathias Gug wrote:
> On Tue, Aug 19, 2008 at 07:28:02PM -0400, Scott Kitterman wrote:
> > >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote:
...
> > >> >Neil's proposal is to improve the gem command (from the libgems-ruby
> > >> >package) so that binaries are installed in /usr/local/bin (thus
> > >> > they're on the default path). If you'd use install gems from the
> > >> > upstream source, binaries would be installed in /usr/bin/. The goal
> > >> > is that gems installed by the gem command don't interfere with ruby
> > >> > libraries and binaries installed by debian packages.
> > >>
> > >> Do you mean NOT on the default path then?
> > >
> > >No. The binaries included in the gem are installed in /usr/local/bin/,
> > >which is on the default PATH.
> >
> > Doesn't that mean they'll get used in place of installed system packages?
>
> See my comment below.
>
> > >> >Upstream provided the necessary hooks to do so and Neil used the
> > >> >update-alternatives system to handle multiple version of gems being
> > >> >installed in /usr/local/bin/ rather than /usr/bin/.
> > >>
> > >> It does sound like progress.  As long as we aren't actually packaing
> > >> the gems themselves it seems like a reasonable way to go until Ruby
> > >> Gems
> >
> > grows
> >
> > >> enough features to support proper integration of gems into the distro
> > >> package space.
> > >
> > >Exactly. Neil's proposal is *not* aimed at integrating gems with the
> > >distro package space but rather improve gem installation from source so
> > >that it doesn't conflict with distro packages. Proper integration is a
> > >long-term goal and we're looking at the Intrepid timeframe.
> > >
> > >The current rubygem package provides a gem command that installs gem
> > >binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH.
> > >Neil's proposal uses update-alternative to make these binaries available
> > >in /usr/loca/bin/ so that they're located in the default PATH. End
> > >users won't have to modify their environment and gems will work OOTB.
> >
> > I can see how this doesn't conflict from an installation perspective, but
> > unless I misremember where that is in the path, it will be used in place
> > of anything provided through the distro.  Am I missing something?
>
> Nope - you're right. Binaries installed by the gem command will be used
> in place of binaries provided by packages since /usr/local/bin comes
> first on the PATH.
>
> I assume that users installing gems from source (ie with the gem
> command) want to use the upstream version of the gem rather than the one
> provided by the distro. Using the gem command to install from source can
> be viewed as a local customization of the system by the system
> administrator - thus the usage of /usr/local/bin/.

For a legalistic reading of policy, I think there is nothing wrong with that, 
but how is a typical user of a gem going to know that if they install gem X a 
library used by gem Y, Z, and package A will be replaced/overridden?  As a 
practical matter I think this declares it all to be the sysadmin's problem 
without giving them a way to know what risk they are taking or how to manage 
it.

As I said in an earlier message in the thread it seems very like Windows DLL 
hell.  Hopefully it will mature.  I doubt that as a distro we can do much to 
improve this where it is now.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Mathias Gug]

On Tue, Aug 19, 2008 at 07:28:02PM -0400, Scott Kitterman wrote:
> >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote:
> >> Which we generally patch into submission when we find it.  In 
> Debian/Ubuntu 
> >> if ezsetup is installing external Python modules it's bug.
> >
> >Do you mean that ezsetup tries to install debian packages of the python
> >modules ?
> 
> No ezsetup tries to download and install modules from outside the packaging 
> system.  Ideally we'd patch that out and the provide proper dependencies to 
> proper packages through the package management system.

IIUC, if ezsetup is used by the upstream source file during the build
phase and downloads an external python module, that portion is replaced
with proper dependencies when creating the package for Debian/Ubuntu.

In the case of the gem command, there isn't any interaction with the
package system.

> >> >Neil's proposal is to improve the gem command (from the libgems-ruby
> >> >package) so that binaries are installed in /usr/local/bin (thus they're
> >> >on the default path). If you'd use install gems from the upstream
> >> >source, binaries would be installed in /usr/bin/. The goal is that gems
> >> >installed by the gem command don't interfere with ruby libraries and
> >> >binaries installed by debian packages.
> >> 
> >> Do you mean NOT on the default path then?
> >
> >No. The binaries included in the gem are installed in /usr/local/bin/,
> >which is on the default PATH.
> 
> Doesn't that mean they'll get used in place of installed system packages?
> 

See my comment below.

> >> >Upstream provided the necessary hooks to do so and Neil used the
> >> >update-alternatives system to handle multiple version of gems being
> >> >installed in /usr/local/bin/ rather than /usr/bin/.
> >> >
> >> It does sound like progress.  As long as we aren't actually packaing the 
> >> gems themselves it seems like a reasonable way to go until Ruby Gems 
> grows 
> >> enough features to support proper integration of gems into the distro 
> >> package space.
> >
> >Exactly. Neil's proposal is *not* aimed at integrating gems with the
> >distro package space but rather improve gem installation from source so
> >that it doesn't conflict with distro packages. Proper integration is a
> >long-term goal and we're looking at the Intrepid timeframe. 
> >
> >The current rubygem package provides a gem command that installs gem
> >binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH.
> >Neil's proposal uses update-alternative to make these binaries available
> >in /usr/loca/bin/ so that they're located in the default PATH. End
> >users won't have to modify their environment and gems will work OOTB.
> >
> I can see how this doesn't conflict from an installation perspective, but 
> unless I misremember where that is in the path, it will be used in place of 
> anything provided through the distro.  Am I missing something?
> 

Nope - you're right. Binaries installed by the gem command will be used
in place of binaries provided by packages since /usr/local/bin comes
first on the PATH. 

I assume that users installing gems from source (ie with the gem
command) want to use the upstream version of the gem rather than the one
provided by the distro. Using the gem command to install from source can
be viewed as a local customization of the system by the system
administrator - thus the usage of /usr/local/bin/.

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Scott Kitterman]

On Tue, 19 Aug 2008 15:46:34 -0700 Mathias Gug <[EMAIL PROTECTED]> wrote:
>
>On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote:
>> On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <[EMAIL PROTECTED]> 
wrote:
...
>> >The make a parallel with python, the gem command is similar to 
>> easy_install.
>> 
>> Which we generally patch into submission when we find it.  In 
Debian/Ubuntu 
>> if ezsetup is installing external Python modules it's bug.
>
>Do you mean that ezsetup tries to install debian packages of the python
>modules ?

No ezsetup tries to download and install modules from outside the packaging 
system.  Ideally we'd patch that out and the provide proper dependencies to 
proper packages through the package management system.

>> >Neil's proposal is to improve the gem command (from the libgems-ruby
>> >package) so that binaries are installed in /usr/local/bin (thus they're
>> >on the default path). If you'd use install gems from the upstream
>> >source, binaries would be installed in /usr/bin/. The goal is that gems
>> >installed by the gem command don't interfere with ruby libraries and
>> >binaries installed by debian packages.
>> 
>> Do you mean NOT on the default path then?
>
>No. The binaries included in the gem are installed in /usr/local/bin/,
>which is on the default PATH.

Doesn't that mean they'll get used in place of installed system packages?

>> >Upstream provided the necessary hooks to do so and Neil used the
>> >update-alternatives system to handle multiple version of gems being
>> >installed in /usr/local/bin/ rather than /usr/bin/.
>> >
>> It does sound like progress.  As long as we aren't actually packaing the 
>> gems themselves it seems like a reasonable way to go until Ruby Gems 
grows 
>> enough features to support proper integration of gems into the distro 
>> package space.
>
>Exactly. Neil's proposal is *not* aimed at integrating gems with the
>distro package space but rather improve gem installation from source so
>that it doesn't conflict with distro packages. Proper integration is a
>long-term goal and we're looking at the Intrepid timeframe. 
>
>The current rubygem package provides a gem command that installs gem
>binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH.
>Neil's proposal uses update-alternative to make these binaries available
>in /usr/loca/bin/ so that they're located in the default PATH. End
>users won't have to modify their environment and gems will work OOTB.
>
I can see how this doesn't conflict from an installation perspective, but 
unless I misremember where that is in the path, it will be used in place of 
anything provided through the distro.  Am I missing something?

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Caucho Resin

[Emil Ong]

Hi Michael,

Sorry for the late reply, I just saw your message...

On Fri, Aug 08, 2008 at 09:34:44AM +0200, Michael Bienia wrote:
> 
> > There are a couple of hitches, though.  We dual-license Resin as GPL
> > and a closed source professional (upsell) version with a bit of extra
> > code for added performance/clustering.  We'd like to distribute the
> > latter in the non-free repository (similar to flashplugin-nonfree).
> > At the moment, we don't have a package of the GPL version and I'm
> > not sure whether/when we'll be doing that.
> 
> Is the Pro version redistributable? That's a basic requirement for
> packages in multiverse (== non-free in Ubuntu)
> 
> Most people prefers to work on free software (and not on close source
> one), so it would be a good idea to package the GPL version too.

I checked and the Pro version is not redistributable, but of course the
GPL version is.  We'll probably just package the GPL version for
distribution in the Ubuntu repository (and hopefully to the main Debian
repository too).  For the Pro version, we'll either just post the .deb
on our site or do an installer.

> > Part of the rational is that the professional version just reverts
> > to the open source functionality if it doesn't find a license.
> > Another reason for the Pro package is that it contains some
> > platform-dependent code in C, while the pure GPL version contains
> > only Java; we wanted to remove the need for users to compile that
> > additional code.
> 
> For which architectures is this C-code precompiled?

x86, x86_64, and possibly SPARC, IIRC.

> > What is the procedure for submitting something to the nonfree 
> > repository?  The REVU page (https://wiki.ubuntu.com/MOTU/Packages/REVU) 
> > that I saw doesn't seem to address this case, but I'm guessing 
> > there's some process because of Flash, et al.  Can someone point me 
> > in the right direction?
> 
> It's the same as for packages to "universe" but don't expect that a
> multiverse package gets a high priority (and packages get currently
> reviewed very slowly already).

Hmm... ok.  Will the GPL version be eligible for universe?  Are universe
packages reviewed more quickly?

> > If I understand correctly, the flashplugin-nonfree package actually
> > downloads the plugin from Adobe.  I should note that our package
> > will include the actual binaries.
> 
> That's no problem as long as the license of the pro version allows
> redistribution of the binaries.

Gotcha.  

Thanks for the info,
Emil



Emil Ong
Chief Evangelist
Caucho Technology, Inc.
mailto:[EMAIL PROTECTED]
http://blog.caucho.com/

Caucho: Reliable Open Source
--> Resin: application server
--> Quercus: PHP in Java
--> Hessian Web Services

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Mathias Gug]

On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote:
> On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <[EMAIL PROTECTED]> wrote:
> >On Tue, Aug 19, 2008 at 03:15:15PM -0400, Scott Kitterman wrote:
> >> On Tuesday 19 August 2008 15:11, Neil Wilson wrote:
> >> 
> >> > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a
> >> > gem based framework and is completely integrated with the gem package
> >> > manager. In Intrepid I would expect users to continue to use gem to
> >> > install Rails and for that to be feasible we need a Rubygems package
> >> > that works as people expect it to work. I have implemented a patch
> >> > that uses the alternatives system so that we can have gem install
> >> > binaries in the $PATH without gem and apt running into each other and
> >> > without violating Debian policy.  This will close a long standing bug
> >> > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267).
> >> >
> 

> >> I think the answer (as Python has largely learned and Java is learning) 
> is you 
> >> have to have a system that will let a package use the installed system 
> >> libraries and not try and work around the package management system?
> >
> >What are you referring to by package ?
> >
> >The make a parallel with python, the gem command is similar to 
> easy_install.
> 
> Which we generally patch into submission when we find it.  In Debian/Ubuntu 
> if ezsetup is installing external Python modules it's bug.

Do you mean that ezsetup tries to install debian packages of the python
modules ?

> >Neil's proposal is to improve the gem command (from the libgems-ruby
> >package) so that binaries are installed in /usr/local/bin (thus they're
> >on the default path). If you'd use install gems from the upstream
> >source, binaries would be installed in /usr/bin/. The goal is that gems
> >installed by the gem command don't interfere with ruby libraries and
> >binaries installed by debian packages.
> 
> Do you mean NOT on the default path then?

No. The binaries included in the gem are installed in /usr/local/bin/,
which is on the default PATH.

> >Upstream provided the necessary hooks to do so and Neil used the
> >update-alternatives system to handle multiple version of gems being
> >installed in /usr/local/bin/ rather than /usr/bin/.
> >
> It does sound like progress.  As long as we aren't actually packaing the 
> gems themselves it seems like a reasonable way to go until Ruby Gems grows 
> enough features to support proper integration of gems into the distro 
> package space.

Exactly. Neil's proposal is *not* aimed at integrating gems with the
distro package space but rather improve gem installation from source so
that it doesn't conflict with distro packages. Proper integration is a
long-term goal and we're looking at the Intrepid timeframe. 

The current rubygem package provides a gem command that installs gem
binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH.
Neil's proposal uses update-alternative to make these binaries available
in /usr/loca/bin/ so that they're located in the default PATH. End
users won't have to modify their environment and gems will work OOTB.

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Scott Kitterman]

On Tuesday 19 August 2008 16:41, Lars Wirzenius wrote:
> ti, 2008-08-19 kello 16:34 -0400, Phillip Susi kirjoitti:
> > I have to disagree.  If you are applying patches you must use a patch
> > system to comply with the debian packaging guidelines ( otherwise you
> > modify the .orig.tar.gz and you shouldn't be doing that ).
>
> That's not actually correct. The Debian packaging tools don't require
> you to modify .orig.tar.gz if you're not using a patch system: instead,
> any changes you make outside debian/ end up in .diff.gz, just like the
> changes you make inside debian/.

Yes and our merge tools generally handle this case very well.  I support using 
patch systems, but if the Debian maintainer hasn't bothered, I think it's not 
worth the trouble for us to add it.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Scott Kitterman]

On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <[EMAIL PROTECTED]> wrote:
>
>On Tue, Aug 19, 2008 at 03:15:15PM -0400, Scott Kitterman wrote:
>> On Tuesday 19 August 2008 15:11, Neil Wilson wrote:
>> 
>> > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a
>> > gem based framework and is completely integrated with the gem package
>> > manager. In Intrepid I would expect users to continue to use gem to
>> > install Rails and for that to be feasible we need a Rubygems package
>> > that works as people expect it to work. I have implemented a patch
>> > that uses the alternatives system so that we can have gem install
>> > binaries in the $PATH without gem and apt running into each other and
>> > without violating Debian policy.  This will close a long standing bug
>> > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267).
>> >
>> > I've been working closely with the Rubygems upstream team and the
>> > package is based on the latest source code from their repository which
>> > will be released as Rubygems 1.3.0 very shortly. Getting this into
>> > Intrepid will mean that it has the very latest Rubygems containing
>> > User based gem support, which is required so that Rails' automatic gem
>> > installation tasks work correctly.
>> 
>> Does it have any notion of versions yet?  
>
>What are you referring to exactly ? Which use case do you have in mind ?

It's my understanding that gems produces one complete package (gem) with 
all Ruby libs needed to run the application and that there is no internal 
notion of versioning.

>> If one has two different gems that use the same binaries how does that 
work?
>
>Binaries are installed in /usr/local/bin using update-alternatives. The
>last installed gems wins.

This sounds very like Windows DLL hell.

>> I think the answer (as Python has largely learned and Java is learning) 
is you 
>> have to have a system that will let a package use the installed system 
>> libraries and not try and work around the package management system?
>
>What are you referring to by package ?
>
>The make a parallel with python, the gem command is similar to 
easy_install.

Which we generally patch into submission when we find it.  In Debian/Ubuntu 
if ezsetup is installing external Python modules it's bug.

>Neil's proposal is to improve the gem command (from the libgems-ruby
>package) so that binaries are installed in /usr/local/bin (thus they're
>on the default path). If you'd use install gems from the upstream
>source, binaries would be installed in /usr/bin/. The goal is that gems
>installed by the gem command don't interfere with ruby libraries and
>binaries installed by debian packages.

Do you mean NOT on the default path then?

>Upstream provided the necessary hooks to do so and Neil used the
>update-alternatives system to handle multiple version of gems being
>installed in /usr/local/bin/ rather than /usr/bin/.
>
It does sound like progress.  As long as we aren't actually packaing the 
gems themselves it seems like a reasonable way to go until Ruby Gems grows 
enough features to support proper integration of gems into the distro 
package space.

Sc

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Jordan Mantha]

On Tue, Aug 19, 2008 at 2:21 PM, Scott Kitterman <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Aug 2008 13:57:29 -0700 "Jordan Mantha" <[EMAIL PROTECTED]>
> wrote:
>>On Tue, Aug 19, 2008 at 12:56 PM, Michael Bienia <[EMAIL PROTECTED]>
> wrote:
>>> On 2008-08-19 20:51:20 +0200, Reinhard Tartler wrote:
 Michael Bienia <[EMAIL PROTECTED]> writes:
>>
>>> Or to put it an other way: what makes a person a "MOTU"?
>>> - is it the membership in the ~motu team (and it's a coincidence that
>>>  the team has upload rights)
>>> - or is it the upload rights to universe/multiverse (which are granted
>>>  by being a member of ~motu)
>>
>>I think it's basically both indistinguishable from each other. A
>>person can have great technical skills (like say a Debian Developer)
>>and that doesn't give them an automatic MOTUship, primarily because
>>MOTU involves both upload rights and a correct understanding of
>>Universe policies and relationship with the Universe community. It's
>>these last two bits that are relevant to this thread. What concerns me
>>about granting MOTUship to people who don't do any significant work in
>>Universe or contribute to the Universe community (in #ubuntu-motu or
>>on the mailing list) is that the difference between Universe and Main
>>is often more than just which LP access team you're in. There are
>>sometimes subtle but significant policy differences. There are
>>noticeable cultural differences as well.
>>
>>> Perhaps I see a difference where no exists, but it depends on how one
>>> defines "being a MOTU". And I currently don't know which view is correct
>>> (if there is a correct view), perhaps it's like the "wave  particle
>>> duality" of a photon.
>>
>>/me <3 photons  ;-)
>
> Well then I guess I'm left feeling like this is the unwritten "Server Team
> need not apply" rule.
>
> When I've brought this up about people who were active in #ubuntu-desktop,
> but not #ubuntu-motu my concerns were dismissed.
>
> I feel like it's a clear double standard.

Well, IMO, that's an entirely different discussion. I haven't
particularly seen a double standard, though I have seen a general lack
ok "inquisitiveness" about applicants. Perhaps people get more
inquisitive when it comes to applicants from the Server Team (for
whatever reason, probably lack of familiarity) and that's what you're
interpreting as a double standard?

One one level I might say "Server Team need not apply", just the same
as I'd say "Desktop Team need not apply" because I want MOTUs, not
Server/Desktop Team members with Universe upload rights. But maybe
that's just me.

-Jordan

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Robert Collins]

On Tue, 2008-08-19 at 16:34 -0400, Phillip Susi wrote:
> 
> I have to disagree.  If you are applying patches you must use a patch 
> system to comply with the debian packaging guidelines ( otherwise you 
> modify the .orig.tar.gz and you shouldn't be doing that ).

Where did this meme turn up? As Lars says, the packaging toolchain
happily supports changes of most sorts anywhere in the cleaned source
tree and will happily detect and place in the debian diff changes
outside of debian.

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Scott Kitterman]

On Tue, 19 Aug 2008 13:57:29 -0700 "Jordan Mantha" <[EMAIL PROTECTED]> 
wrote:
>On Tue, Aug 19, 2008 at 12:56 PM, Michael Bienia <[EMAIL PROTECTED]> 
wrote:
>> On 2008-08-19 20:51:20 +0200, Reinhard Tartler wrote:
>>> Michael Bienia <[EMAIL PROTECTED]> writes:
>
>> Or to put it an other way: what makes a person a "MOTU"?
>> - is it the membership in the ~motu team (and it's a coincidence that
>>  the team has upload rights)
>> - or is it the upload rights to universe/multiverse (which are granted
>>  by being a member of ~motu)
>
>I think it's basically both indistinguishable from each other. A
>person can have great technical skills (like say a Debian Developer)
>and that doesn't give them an automatic MOTUship, primarily because
>MOTU involves both upload rights and a correct understanding of
>Universe policies and relationship with the Universe community. It's
>these last two bits that are relevant to this thread. What concerns me
>about granting MOTUship to people who don't do any significant work in
>Universe or contribute to the Universe community (in #ubuntu-motu or
>on the mailing list) is that the difference between Universe and Main
>is often more than just which LP access team you're in. There are
>sometimes subtle but significant policy differences. There are
>noticeable cultural differences as well.
>
>> Perhaps I see a difference where no exists, but it depends on how one
>> defines "being a MOTU". And I currently don't know which view is correct
>> (if there is a correct view), perhaps it's like the "wave particle
>> duality" of a photon.
>
>/me <3 photons  ;-)

Well then I guess I'm left feeling like this is the unwritten "Server Team 
need not apply" rule.

When I've brought this up about people who were active in #ubuntu-desktop, 
but not #ubuntu-motu my concerns were dismissed.

I feel like it's a clear double standard.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Mathias Gug]

On Tue, Aug 19, 2008 at 03:15:15PM -0400, Scott Kitterman wrote:
> On Tuesday 19 August 2008 15:11, Neil Wilson wrote:
> 
> > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a
> > gem based framework and is completely integrated with the gem package
> > manager. In Intrepid I would expect users to continue to use gem to
> > install Rails and for that to be feasible we need a Rubygems package
> > that works as people expect it to work. I have implemented a patch
> > that uses the alternatives system so that we can have gem install
> > binaries in the $PATH without gem and apt running into each other and
> > without violating Debian policy.  This will close a long standing bug
> > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267).
> >
> > I've been working closely with the Rubygems upstream team and the
> > package is based on the latest source code from their repository which
> > will be released as Rubygems 1.3.0 very shortly. Getting this into
> > Intrepid will mean that it has the very latest Rubygems containing
> > User based gem support, which is required so that Rails' automatic gem
> > installation tasks work correctly.
> 
> Does it have any notion of versions yet?  

What are you referring to exactly ? Which use case do you have in mind ?

> If one has two different gems that use the same binaries how does that work?

Binaries are installed in /usr/local/bin using update-alternatives. The
last installed gems wins.

> I think the answer (as Python has largely learned and Java is learning) is 
> you 
> have to have a system that will let a package use the installed system 
> libraries and not try and work around the package management system?

What are you referring to by package ?

The make a parallel with python, the gem command is similar to easy_intall.

Neil's proposal is to improve the gem command (from the libgems-ruby
package) so that binaries are installed in /usr/local/bin (thus they're
on the default path). If you'd use install gems from the upstream
source, binaries would be installed in /usr/bin/. The goal is that gems
installed by the gem command don't interfere with ruby libraries and
binaries installed by debian packages.

Upstream provided the necessary hooks to do so and Neil used the
update-alternatives system to handle multiple version of gems being
installed in /usr/local/bin/ rather than /usr/bin/.

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Jordan Mantha]

On Tue, Aug 19, 2008 at 12:56 PM, Michael Bienia <[EMAIL PROTECTED]> wrote:
> On 2008-08-19 20:51:20 +0200, Reinhard Tartler wrote:
>> Michael Bienia <[EMAIL PROTECTED]> writes:

> Or to put it an other way: what makes a person a "MOTU"?
> - is it the membership in the ~motu team (and it's a coincidence that
>  the team has upload rights)
> - or is it the upload rights to universe/multiverse (which are granted
>  by being a member of ~motu)

I think it's basically both indistinguishable from each other. A
person can have great technical skills (like say a Debian Developer)
and that doesn't give them an automatic MOTUship, primarily because
MOTU involves both upload rights and a correct understanding of
Universe policies and relationship with the Universe community. It's
these last two bits that are relevant to this thread. What concerns me
about granting MOTUship to people who don't do any significant work in
Universe or contribute to the Universe community (in #ubuntu-motu or
on the mailing list) is that the difference between Universe and Main
is often more than just which LP access team you're in. There are
sometimes subtle but significant policy differences. There are
noticeable cultural differences as well.

> Perhaps I see a difference where no exists, but it depends on how one
> defines "being a MOTU". And I currently don't know which view is correct
> (if there is a correct view), perhaps it's like the "wave–particle
> duality" of a photon.

/me <3 photons  ;-)

-Jordan
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Lars Wirzenius]

ti, 2008-08-19 kello 16:34 -0400, Phillip Susi kirjoitti:
> I have to disagree.  If you are applying patches you must use a patch 
> system to comply with the debian packaging guidelines ( otherwise you 
> modify the .orig.tar.gz and you shouldn't be doing that ).

That's not actually correct. The Debian packaging tools don't require
you to modify .orig.tar.gz if you're not using a patch system: instead,
any changes you make outside debian/ end up in .diff.gz, just like the
changes you make inside debian/.



-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Reinhard Tartler wrote:
>> I think our job as downstreams is to provide patches to Debian, not
>> tell them how to maintain their packages.
> 
> Excatly.
> 
> Please note that adding a patch system to a package that previously
> didn't adds additional noise in the debdiff. So please, don't.
> 
> (well, perhaps debdiff could be taught somehow to handle patch systems
> more sensibly, which would alleviate the issue here)

I have to disagree.  If you are applying patches you must use a patch 
system to comply with the debian packaging guidelines ( otherwise you 
modify the .orig.tar.gz and you shouldn't be doing that ).  If you run 
into a package that does not already have some kind of patch system 
there are 2 possibilities:

1)  The package has never needed to be patched before
2)  The package has been patched by directly modifying the original 
upstream files, which is a big no-no

In the second case, the package should be fixed and the upstream debian 
maintainer notified and asked to repair their broken package as well.

In the first case, if you are going to start patching you need to use 
one of the patch systems to do it.  Ideally you would want to coordinate 
with the debian package maintainer to use whichever patch system he 
prefers so he will accept the diff adding the patch and the patch 
system.  Practically speaking though, it can take weeks, months, or 
sometimes years to get a debian developer to pay attention to your 
patch, so really you just want to go ahead and diverge by adding a patch 
system, try to get it added to debian, and if the debian maintainer ever 
manages to add the patch, even if he uses a different patch system, you 
can just drop the ubuntu changes when merging from debian.

Sure, you will have to manually merge debian updates until they accept 
the patch, but using the patch system in the first place makes this as 
simple as grabbing the debian package, inserting the patch system again, 
and copying over the patch file from the last ubuntu package.



-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Michael Bienia]

On 2008-08-19 20:51:20 +0200, Reinhard Tartler wrote:
> Michael Bienia <[EMAIL PROTECTED]> writes:
> 
> >> > This leads me to the question: what the main point on becoming a MOTU?
> >> > - is it the next reward for Ubuntu members who work hard on improving
> >> >   Ubuntu (development)? They have good technicals skills and we trust
> >> >   them enough to make them MOTUs (and allow them to upload directly)
> >> > - or is it: they have good technicals skills and we trust them enough to
> >> >   work unsupervised and allow them to upload directly (make them a
> >> >   MOTU).
> 
> I'm not really sure that I understand the actual difference here. 

I try to make more clear what I meant. In some way it's the same
(membership in the MOTU team == upload rights to universe), but
depending on how one looks at MOTUship one can emphasize one side
or the other side a little more.

> We
> generally have some certain expectations from propective Ubuntu
> Developers (in no particular order, and certainly not exhaustive):
> 
>  . they are technically skilled to maintain packages
>  . they are experienced enough to review and sponsor patches from other
> prospective contributors
>  . they are recognized in the existing MOTU community
>  . they are familiar with ubuntu development policies and procedures
>  . they agree to the ubuntu philophy (think code of conduct, etc.)
> 
> In some ways granting membership to a contributor that fulfills the
> expectations I outlined above is a reward, true. AFAIUI, we currently
> grant membership if the motu-council (and previously the technical
> board) is convinced that an applicant fulfills the expectations.

So given an applicant who meets our expecations:
Are we granting membership because the applicant meets the expectations
(and the upload rights are a "bonus"), or are we granting upload rights
to ease them contributing (and the membership is just technical detail)?

Or to put it an other way: what makes a person a "MOTU"?
- is it the membership in the ~motu team (and it's a coincidence that
  the team has upload rights)
- or is it the upload rights to universe/multiverse (which are granted
  by being a member of ~motu)

Perhaps I see a difference where no exists, but it depends on how one
defines "being a MOTU". And I currently don't know which view is correct
(if there is a correct view), perhaps it's like the "wave–particle
duality" of a photon.

Regards
Michael

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Scott Kitterman]

On Tuesday 19 August 2008 15:11, Neil Wilson wrote:

> Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a
> gem based framework and is completely integrated with the gem package
> manager. In Intrepid I would expect users to continue to use gem to
> install Rails and for that to be feasible we need a Rubygems package
> that works as people expect it to work. I have implemented a patch
> that uses the alternatives system so that we can have gem install
> binaries in the $PATH without gem and apt running into each other and
> without violating Debian policy.  This will close a long standing bug
> (https://bugs.edge.launchpad.net/ubuntu/+bug/145267).
>
> I've been working closely with the Rubygems upstream team and the
> package is based on the latest source code from their repository which
> will be released as Rubygems 1.3.0 very shortly. Getting this into
> Intrepid will mean that it has the very latest Rubygems containing
> User based gem support, which is required so that Rails' automatic gem
> installation tasks work correctly.

Does it have any notion of versions yet?  

If one has two different gems that use the same binaries how does that work?

I think the answer (as Python has largely learned and Java is learning) is you 
have to have a system that will let a package use the installed system 
libraries and not try and work around the package management system?

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Reinhard Tartler]

"Jordan Mantha" <[EMAIL PROTECTED]> writes:

> Also i will suggest to the revu reviewers to ask the
>> packagers to add a patch system on their packages.
>>What did you think about it? Any comments?
>>
>
> I think our job as downstreams is to provide patches to Debian, not
> tell them how to maintain their packages.

Excatly.

Please note that adding a patch system to a package that previously
didn't adds additional noise in the debdiff. So please, don't.

(well, perhaps debdiff could be taught somehow to handle patch systems
more sensibly, which would alleviate the issue here)

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Neil Wilson]

With the Intrepid Feature Freeze deadline fast approaching (August
28th) I thought I'd put out another call for help reviewing the
Phusion Passenger package and alterations to the Rubygems package.
Without your help reviewing the code, this will not go into Intrepid
and Ubuntu will be short of effective Rails support for yet another
cycle.

Even if Ruby isn't your first love, can I ask for your help to break
the logjam. I have a feeling we're in a bit of a chicken and egg
scenario here: there is nobody with review privileges who knows much
about Ruby and Rails, so nothing with Ruby and Rails every gets looked
at, so there is nobody with review privileges who knows much about
Ruby and Rails.

Phusion Passenger is a module for Apache that supports both Ruby on
Rails and other Rack based Ruby frameworks. It also has experimental
support for Python WSGI applications. The packaging bug is here
(https://bugs.edge.launchpad.net/ubuntu/+bug/246719). I need reviews
and acks in REVU please to get this uploaded.

Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a
gem based framework and is completely integrated with the gem package
manager. In Intrepid I would expect users to continue to use gem to
install Rails and for that to be feasible we need a Rubygems package
that works as people expect it to work. I have implemented a patch
that uses the alternatives system so that we can have gem install
binaries in the $PATH without gem and apt running into each other and
without violating Debian policy.  This will close a long standing bug
(https://bugs.edge.launchpad.net/ubuntu/+bug/145267).

I've been working closely with the Rubygems upstream team and the
package is based on the latest source code from their repository which
will be released as Rubygems 1.3.0 very shortly. Getting this into
Intrepid will mean that it has the very latest Rubygems containing
User based gem support, which is required so that Rails' automatic gem
installation tasks work correctly.

You can find the latest build of the packages at the Ubuntu Ruby team
archives here: https://edge.launchpad.net/~ubuntu-ruby. Both packages
are on the REVU system as well.

If you are just a user of Ubuntu and Ruby and would like better Rails
and Gem support, please make yourself heard and perhaps even join the
Ubuntu ruby group. I want to know what you think and what you want
from Ubuntu Ruby, Rails and Gems.

-- 
Neil Wilson

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Reinhard Tartler]

Michael Bienia <[EMAIL PROTECTED]> writes:

>> > This leads me to the question: what the main point on becoming a MOTU?
>> > - is it the next reward for Ubuntu members who work hard on improving
>> >   Ubuntu (development)? They have good technicals skills and we trust
>> >   them enough to make them MOTUs (and allow them to upload directly)
>> > - or is it: they have good technicals skills and we trust them enough to
>> >   work unsupervised and allow them to upload directly (make them a
>> >   MOTU).

I'm not really sure that I understand the actual difference here.  We
generally have some certain expectations from propective Ubuntu
Developers (in no particular order, and certainly not exhaustive):

 . they are technically skilled to maintain packages
 . they are experienced enough to review and sponsor patches from other
prospective contributors
 . they are recognized in the existing MOTU community
 . they are familiar with ubuntu development policies and procedures
 . they agree to the ubuntu philophy (think code of conduct, etc.)

In some ways granting membership to a contributor that fulfills the
expectations I outlined above is a reward, true. AFAIUI, we currently
grant membership if the motu-council (and previously the technical
board) is convinced that an applicant fulfills the expectations.

For ubuntu-core-dev membership, the bar is a bit higher. We generally
expect core-devs to have even more experience with packaging, but what
that means in details is left rather fuzzy; and that on purpose so that
applicaptions can be considered and argued more flexibly. I haven't
noticed any problems with that approach since the start of the ubuntu
project, so I don't think we need fixing here.

In the light of UbuntuArchiveReorganisation and seed based upload
permission, priority might shift, and I reckon that the individual teams
(kubuntu, xubuntu, etc) will clarify their expectations for new
members. It might also mean that MOTU and motu-council in paricular
might review their expectations about new developer applications, if we
don't want the MOTU team to be recognized as "the team maintaining
packages nobody cares about" [1].

[1] because elseway, the package would have been seeded in some way.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Jordan Mantha]

On Tue, Aug 19, 2008 at 9:25 AM, Steve Langasek
<[EMAIL PROTECTED]> wrote:
> On Sat, Aug 16, 2008 at 11:31:27PM -0700, Jordan Mantha wrote:
>> On Sat, Aug 16, 2008 at 9:49 PM, Nicolas Valcarcel
>> <[EMAIL PROTECTED]> wrote:
>
>> >Currently there is no policy about how to make changes in the 
>> > packages,
>> > there are some good practices and a lot of developers try to use patch
>> > systems whenever they can and don't touch the source code outside
>> > debian/ directly, but that's still at the developer's discretion.
>> >For that reason i wanted to start a discussion on the topic, to 
>> > start
>> > working with debian on preparing the packages with a patch system, so we
>> > (and other derivatives) can make patches without the need of changing
>> > the packaging. Also i will suggest to the revu reviewers to ask the
>> > packagers to add a patch system on their packages.
>> >What did you think about it? Any comments?
>
>> > 1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195
>
>> I think our job as downstreams is to provide patches to Debian, not
>> tell them how to maintain their packages. IMO anyway, it's our
>> obligation to either 1) give ordinary diff patches 2) use whatever
>> patch system or lack thereof that upstream uses. There are so many
>> common ways to patch and maintain a package (debhelper, cdbs, quilt,
>> dpatch, svn, git, bzr ...) that I can't foresee a comprehensive,
>> archive-wide policy.
>
>> Additionally, IMO again, a primary goal of at least MOTU should be
>> minimizing the divergence from Debian. The more changes we make, and
>> the more useless they are (bumping standards version??) the more time
>> we spend maintaining the divergence and the less time we have for more
>> important tasks. Adding a patch system really *should not* be done in
>> Ubuntu. If we're maintaining that much divergence we need to talk to
>> Debian about how we can better minimize and maintain it.
>
> If you have more than one change to the upstream source of a Debian package,
> then you need some system to manage the changes to indicate which parts of
> the patch belong to which functional change -- i.e., a "patch management
> system".  This can be a set of VCS feature branches, if you prefer (in which
> case it's important to use the Vcs-* headers in debian/control in the Ubuntu
> upload), or it can be an in-package patch system; but it is important to
> have /some/ mechanism for labelling your changes so that you aren't left
> with a single massive diff.

My point was that if people are pushing patches upstream and talking
with Debian maintainers then I imagine Ubuntu adding a patch system
would be a quite rare occurrence. Certainly in Universe this should be
the case. Main seems to have more Ubuntu-side maintenance so I can see
it happening more there.

> If the Debian maintainer already has a patch system in place, it's far
> better to continue using that one (no matter how bad it is, sometimes);
> otherwise, adding a patch system *should* be done when needed.

For sure, I'm just saying that it's probably in our best interest to
not let divergence from Debian get so far that the "when needed" kicks
in. Most packages that have heavy patching usually already have a
patch system. For the not-so-often-patched packages it's better to
move changes upstream.

-Jordan

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Scott Kitterman]

On Wed, 20 Aug 2008 00:58:40 +0900 "Emmet Hikory" <[EMAIL PROTECTED]> wrote:
>Dustin Kirkland wrote:
>> According to the diagram shown here:
>>  * https://wiki.ubuntu.com/UbuntuDevelopers
>> there is a "dotted line" between a Prospective Developer and a "Core
>> Developer", and a note that this an exceptional case.  The more common
>> case is for MOTU to apply for Core Developer recognition.  In fact,
>> that page states that "Core Developers are often recruited among the
>> MOTUs".
>
>Indeed.  Most of those who become involved with Ubuntu development
>due so because they "want to help", and are typically pointed at those
>packages which are not receiving as much attention, which tend to be
>in universe.  This typically creates a workflow and work habits that
>are universe-focused.  Those developers who become immediately
>involved in the Kubuntu, Desktop, Server, Kernel, and Foundations
>teams are less common, and rightly referred to as exceptions.  Many
>MOTU, as their skills and confidence develop, may become in involved
>in one of these teams, and find that they need to become a Core
>Developer to continue their work effectively.  When these teams seek
>new members, they often seek them from existing developers who may
>have shown some interest in the area previously, adn who may be MOTU.
>
>> That page also goes on to describe the process by which one applies
>> for Core Developer membership, which involves going through the MOTU
>> Council and asking for them to present the individual and application
>> to the Tech Board for consideration as a Core Developer.
>>
>> That page certainly makes it seem that to either become a MOTU or a
>> Core Developer, one needs to seek and attain the approval of the MOTU
>> Council.
>
>The application process is almost identical for either
>application: the applicant simply states for which role they are
>applying, and those providing endorsements are expected to currently
>participate in the role for which the applicant has applied.  In the
>case of Core Developers, MOTU Council will make a recommendation for
>or against to the Technical Board, who will additionally interview the
>applicant during a scheduled meeting for final approval.  In the case
>of MOTU, MOTU Council will directly accept or reject the application.
>Generally, applicants are expected to demonstrate a higher degree of
>technical facility when applying for Core Developer, although many
>applicants for MOTU have also reached this level at the time of their
>application.
>

I guess I don't see the point in denying someone MOTU because mostly the 
packages they've touched are now in Main even though in many cases they 
were in Universe when he touched them.

If someone has some interest in Universe packages (as is the case here) I 
don't see any benifit in denying them upload rights because that is not 
mostly what they work on.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Emmet Hikory]

Dustin Kirkland wrote:
> According to the diagram shown here:
>  * https://wiki.ubuntu.com/UbuntuDevelopers
> there is a "dotted line" between a Prospective Developer and a "Core
> Developer", and a note that this an exceptional case.  The more common
> case is for MOTU to apply for Core Developer recognition.  In fact,
> that page states that "Core Developers are often recruited among the
> MOTUs".

Indeed.  Most of those who become involved with Ubuntu development
due so because they "want to help", and are typically pointed at those
packages which are not receiving as much attention, which tend to be
in universe.  This typically creates a workflow and work habits that
are universe-focused.  Those developers who become immediately
involved in the Kubuntu, Desktop, Server, Kernel, and Foundations
teams are less common, and rightly referred to as exceptions.  Many
MOTU, as their skills and confidence develop, may become in involved
in one of these teams, and find that they need to become a Core
Developer to continue their work effectively.  When these teams seek
new members, they often seek them from existing developers who may
have shown some interest in the area previously, adn who may be MOTU.

> That page also goes on to describe the process by which one applies
> for Core Developer membership, which involves going through the MOTU
> Council and asking for them to present the individual and application
> to the Tech Board for consideration as a Core Developer.
>
> That page certainly makes it seem that to either become a MOTU or a
> Core Developer, one needs to seek and attain the approval of the MOTU
> Council.

The application process is almost identical for either
application: the applicant simply states for which role they are
applying, and those providing endorsements are expected to currently
participate in the role for which the applicant has applied.  In the
case of Core Developers, MOTU Council will make a recommendation for
or against to the Technical Board, who will additionally interview the
applicant during a scheduled meeting for final approval.  In the case
of MOTU, MOTU Council will directly accept or reject the application.
Generally, applicants are expected to demonstrate a higher degree of
technical facility when applying for Core Developer, although many
applicants for MOTU have also reached this level at the time of their
application.

-- 
Emmet HIKORY

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Dustin Kirkland]

On Tue, Aug 19, 2008, either Michael Bienia or Reinhard Tartler wrote:
> Perhaps it was not so well communicated in the past else there wouldn't
> be the confusion leading to that mail. At that time I thought that one
> had to be a MOTU before one could apply for core-dev.

According to the diagram shown here:
 * https://wiki.ubuntu.com/UbuntuDevelopers
there is a "dotted line" between a Prospective Developer and a "Core
Developer", and a note that this an exceptional case.  The more common
case is for MOTU to apply for Core Developer recognition.  In fact,
that page states that "Core Developers are often recruited among the
MOTUs".

That page also goes on to describe the process by which one applies
for Core Developer membership, which involves going through the MOTU
Council and asking for them to present the individual and application
to the Tech Board for consideration as a Core Developer.

That page certainly makes it seem that to either become a MOTU or a
Core Developer, one needs to seek and attain the approval of the MOTU
Council.

:-Dustin

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Considering component-specific work when reviewing applications

[Michael Bienia]

On 2008-08-19 16:38:43 +0200, Reinhard Tartler wrote:
> Michael Bienia <[EMAIL PROTECTED]> writes:
> 
> > [ feel free to take it back to motu-council if you want ]
> >
> > On 2008-08-19 15:52:10 +0200, Reinhard Tartler wrote:
> >> Michael Bienia <[EMAIL PROTECTED]> writes:
> >> 
> >> > As MOTUship isn't required for core-dev since some time,
> >> 
> >> Err, this surprises me. Can you please give me a reference when did this
> >> policy change and why?
> >
> > It was first mentioned by Matt Zimmerman, that MOTU is no strict
> > requirement for core-dev (but strongly advised):
> > https://lists.ubuntu.com/archives/motu-council/2007-November/000562.html
> 
> That comment is true since the start of the ubuntu project. We always
> had cases (but rather seldom) were the TB decided that an applicant
> could be approved directly without being in MOTU. This is however not a
> change that happened 'since some time', so that's what confused me here.

Perhaps it was not so well communicated in the past else there wouldn't
be the confusion leading to that mail. At that time I thought that one
had to be a MOTU before one could apply for core-dev.

[ Context is an other mail from Matt Zimmerman: 
https://lists.ubuntu.com/archives/motu-council/2007-November/000567.html
]
> > Based on this perhaps I need to think over my previous statement again.
> >
> > This leads me to the question: what the main point on becoming a MOTU?
> > - is it the next reward for Ubuntu members who work hard on improving
> >   Ubuntu (development)? They have good technicals skills and we trust
> >   them enough to make them MOTUs (and allow them to upload directly)
> > - or is it: they have good technicals skills and we trust them enough to
> >   work unsupervised and allow them to upload directly (make them a
> >   MOTU).
> 
> I think this is a very intersting question that should be discussed
> publicy. If you agree, please do post that on ubuntu-motu@ (CC'ed to
> -council, perhaps), and I'll answer in public.

Done (reply-to set to ubuntu-motu).

Michael

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Changes to the Ubuntu Universe Sponsors Administrators team

[Emmet Hikory]

Luca Falavigna wrote:
> Emmet Hikory ha scritto:
>> Consequently, there is now an opening on the team, and volunteers
>> are needed to help with the work.
>
> I'd like to volunteer for the role.

I'm happy to welcome Luca to the Universe Sponsors Admin team.
Luca has been one of the primary sponsors for a while, and in the
absence of opposition has secured the open position.  To celebrate,
please grab a few items from the queue :)

-- 
Emmet HIKORY

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu