Re: Getting new packages into Ubuntu

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stefano Rivera wrote on 10/10/11 20:24:
> 
> Hi Sebastien (2011.10.10_20:34:48_+0200) ...
>>> * No obvious approaches to handling security issues or bug 
>>> reports yet.
>> 
>> How does android or app stores deal with those?


As well as linking to the developer's Web site, which Ubuntu Software
Center already does, they sometimes have another link specifically for
reporting problems. We'd like to add that too.


> ... When you download something from the software centre, the 
> origin isn't obvious. Currently, I think about the only obvious 
> feedback mechanism is the reviews in Software Center (are those 
> visible on the web anywhere?). By doing this, we are also aligning 
> Ubuntu with these apps, to some degree. People find the quality of 
> the apps in smartphones application stores to be a discriminator 
> between smartphone platforms. I think that'll easily carry over to 
> Ubuntu, and people will measure Ubuntu by the quality of the app 
> store.
> 
> We don't want as little responsibility as possible. We want to 
> create the best experience for our users and ourselves.


That isn't a one-dimensional landscape, though. More oversight also
means more time and effort to publish an application, which means
fewer applications, which means a worse experience. (Or,
alternatively, a good experience for fewer people.)

The past 18 years of Debian and Ubuntu have shown that the model of
"we package all your stuff, and people upgrade their OS to get it" is
not a peak on that landscape. Or at least, not one high enough to be
competitive.

>> We shouldn't aim at getting libraries in extras, the libraries 
>> should be part of the platform an in the archive itself then.
> 
> I'm talking about bundled libraries, not library packages.
> There'll be ARB apps that need libraries that aren't in Ubuntu.
> (And probably ARB apps that want different library versions to what
> we ship in Ubuntu).
> 
> ...


Ubuntu developers announce, months in advance, what kernel and
toolchain versions will be used in the next release. Minimizing the
library problem may involve doing something similar for libraries (or
at least library API versions). So if you want your application
published for that Ubuntu version, you can write to that version's APIs.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6UlZ4ACgkQ6PUxNfU6ecpCagCgmTGk1ZgIvSqBLUQkVLerPYLl
zUkAn1YQ2vltlKQyTu8cchWPGr19pMgs
=3mXM
-END PGP SIGNATURE-

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

Re: Getting new packages into Ubuntu

[Stefano Rivera]

Hi Micah (2011.10.10_21:52:58_+0200)
> I thought ARB was supposed to be lightweight apps, why would these
> require (or even be allowed) to include library dependencies?

It's not uncommon when packaging new apps to need to package a library
or two too. And most upstreams (that don't have distributions in mind)
seem to target specific versions of their dependency libraries, and just
bundle them with their app, Windows-style (and Java-style).

I prepared one app for ARB, and it required a bundled library. That's a
single data point, but from my experience elsewhere, not an outlier.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

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

Re: Getting new packages into Ubuntu

[Colin Watson]

On Mon, Oct 10, 2011 at 06:08:16PM +0200, Sebastien Bacher wrote:
> - there are lot of people out there who writer softwares and have no
> interest to learn enough about Ubuntu to become a MOTU, they just want
> to reach users, they should be welcome to join as well and in a way
> which is not to difficult for them
> - you were recently complaining as well about the number of packages
> that see one upload and stop being maintained that we have to fix then,
> do we want those in the main archive because they attract people or
> would they be better suited in extras?

I'm not saying that extras shouldn't exist; I think it should be a good
fit for certain kinds of packages and certain kinds of developers.
However, I do remain somewhat concerned that if and when it takes off
people will start consistently directing new developers away from Ubuntu
and towards extras when they might have been the sort of person who
would become a productive general Ubuntu developer.

I also think that we have a regrettable though understandable tendency
to focus on the products we work on as the most important ones, and
dismiss everything else as leaf applications that don't really matter
much.  There are a lot of packages in universe that we aren't interested
in for our primary products but which are mission-critical for certain
segments of our user base, and that are definitely worth having in the
primary archive where we can e.g. make sure that they build, are built
against current libraries, build other things against them, encourage
people to integrate, etc.  I don't think extras will be good for
everything and I want to make sure that we don't start throwing things
out of universe that really do belong in universe rather than in extras.

Extras is a useful innovation, but let's be thoughtful about how we make
use of it.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Getting new packages into Ubuntu

[Micah Gersten]

On 10/10/2011 02:24 PM, Stefano Rivera wrote:
> Hi Sebastien (2011.10.10_20:34:48_+0200)
>> Well you would perhaps have run into some issues where you need upgrades
>> or fixes to the "platform" side and looked at the "main" archive to get
>> those solved? Or you would have just contributed to extras and reach
>> users which is a valid contributions as well...
> In fact I did (python-configobj), and now maintain that library in
> Debian. But I'm expecting that the ARB solution to that problem would be
> to bundle the newer library version. Otherwise, would we be expecting
> ARB to sort out the dependencies as SRUs?
>
> SR
>
I thought ARB was supposed to be lightweight apps, why would these
require (or even be allowed) to include library dependencies?

Micah

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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 03:26:18 PM Barry Warsaw wrote:
> On Oct 10, 2011, at 02:50 PM, Scott Kitterman wrote:
> >First, I think that things are getting pushed into the distro before they
> >are really ready.  Also there are upstreams that push to get last minute
> >features in (e.g. Unity) and so there are consequences when there are
> >unexpected side effects.  One way to reduce the amount of post-release
> >desire for churn due to missing things is to get things into the release
> >on time and then people have a chance to adapt.
> >
> >For the more general case of leaf packages that would benefit from
> >updating, I think that get it into the next release and then backport it
> >solves most cases.  It can even be used for libraries on a reasonable
> >basis if adeequate testing is done.
> 
> Of course, this is supposed to be one of the primary benefits of timed
> releases.  If a feature isn't ready at the time of the release, it *should*
> be low risk and S.O.P. to just delay it until the next clock tick.

Except we don't actually do that.  We had new feature uploads past final freeze 
this cycle.  As long as certain upstreams are free to ignore the distro 
schedule, it's going to be problematic.

Scott K

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

Re: Getting new packages into Ubuntu

[Barry Warsaw]

On Oct 10, 2011, at 02:50 PM, Scott Kitterman wrote:

>First, I think that things are getting pushed into the distro before they are
>really ready.  Also there are upstreams that push to get last minute features
>in (e.g. Unity) and so there are consequences when there are unexpected side
>effects.  One way to reduce the amount of post-release desire for churn due
>to missing things is to get things into the release on time and then people
>have a chance to adapt.
>
>For the more general case of leaf packages that would benefit from updating,
>I think that get it into the next release and then backport it solves most
>cases.  It can even be used for libraries on a reasonable basis if adeequate
>testing is done.

Of course, this is supposed to be one of the primary benefits of timed
releases.  If a feature isn't ready at the time of the release, it *should* be
low risk and S.O.P. to just delay it until the next clock tick.

-Barry

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

Re: Getting new packages into Ubuntu

[Stefano Rivera]

Hi Sebastien (2011.10.10_20:34:48_+0200)
> What if we made packaging easy enough that upstream code get their
> software themself in extras?

I think that's a pretty vital requirement for ARB to succeed long term.
And sandboxing. Otherwise the review load is monstrous.

And yes, ARB has the potential to give a really low
submission-to-publication turnaround time, which is a great motivator.

> > * Every package needs to be explicitly uploaded to every release.
> We might want to target mainly lts versions then for arb?

I guess we'll know, once ARB gets up to speed...

> > * No obvious approaches to handling security issues or bug reports yet.
> How does android or app stores deal with those?

I have no idea :) But they haven't necessarily found all the right
answers, yet, either.

> Do we need to deal with those or can we just treat those as any
> software you download from the internet and let users deal with
> software writes?

When you download something from the software centre, the origin isn't
obvious. Currently, I think about the only obvious feedback mechanism is
the reviews in Software Center (are those visible on the web anywhere?).
By doing this, we are also aligning Ubuntu with these apps, to some
degree. People find the quality of the apps in smartphones application
stores to be a discriminator between smartphone platforms. I think
that'll easily carry over to Ubuntu, and people will measure Ubuntu by
the quality of the app store.

We don't want as little responsibility as possible. We want to create
the best experience for our users and ourselves.

> We shouldn't aim at getting libraries in extras, the libraries should be
> part of the platform an in the archive itself then.

I'm talking about bundled libraries, not library packages. There'll be
ARB apps that need libraries that aren't in Ubuntu. (And probably ARB
apps that want different library versions to what we ship in Ubuntu).

> Well, do you think that letting the universe unfrozen under feature
> freeze rules would improve its stability or lower it? I think it would
> improve it since we could keep fixing bugs.

The only FFes we've turned down have been NEW applications. There
haven't been many requests. And yes, I think universe needs time to
stabilise like everything else.

> Well you would perhaps have run into some issues where you need upgrades
> or fixes to the "platform" side and looked at the "main" archive to get
> those solved? Or you would have just contributed to extras and reach
> users which is a valid contributions as well...

In fact I did (python-configobj), and now maintain that library in
Debian. But I'm expecting that the ARB solution to that problem would be
to bundle the newer library version. Otherwise, would we be expecting
ARB to sort out the dependencies as SRUs?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 09:00:51 PM Sebastien Bacher wrote:
> Le lundi 10 octobre 2011 à 14:53 -0400, Scott Kitterman a écrit :
> > How does feature freeze prevent fixing bugs?
> 
> It doesn't which was my point ;-) I was suggesting keep universe under
> the feature freeze rule for ever rather than hard freezing it.

Ah.  I misunderstood.  Thanks for the clarification.

We only hard freeze unseeded Universe about three or four days before release, 
so I don't think there's a lot of room for gain there.  The fact that these 
packages need a manual push through the queue once the queue is frozen for 
Main and seeded packages is an artifact of Launchpad's limitation and not 
release policy.

Scott K

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 14:53 -0400, Scott Kitterman a écrit :
> How does feature freeze prevent fixing bugs?

It doesn't which was my point ;-) I was suggesting keep universe under
the feature freeze rule for ever rather than hard freezing it.

Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 02:17:27 PM Barry Warsaw wrote:
> On Oct 10, 2011, at 02:06 PM, Jeremy Bicha wrote:
> >Instead of a new repository (extras or PPAs or whatever), why don't we use
> >backports more to get new packages into the stable releases?  Firefox and
> >Chromium, though special, have at least opened the door more to stable
> >updates that aren't just bug fixes.
> 
> Further, if we had "official PPAs" we could perhaps do some automated
> promotion from an official PPA into backports, so users wouldn't have to
> add-apt-repository for dozens of packages.
> 
> Many projects already have de-facto official PPAs, and these are great for
> getting access to newer versions of packages in your current Ubuntu version,
> or even packages which aren't available at all (e.g. pypy).  Unfortunately,
> there's no way to mark PPAs as "official" so users may not be able to rely
> on the reputation of the PPA uploaders.
> 
> A promotion from PPA would still require a rebuild to ensure the consistency
> of the archive being promoted into.  Maybe backports is the right archive
> for these promotions, or maybe some other channel would be best, but it
> would be nice if it were easy for users to enable it.

I don't know how a well maintained 'official' PPA would be less work than a 
update/backport approach for Ubuntu developers?  Such PPAs would still have to 
not conflict if the actual distribtution and not introduce library updates the 
affected other packages.  I think the things one would need to consider are 
about the same.

Scott K

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

Re: Getting new packages into Ubuntu

[Alex Chiang]

* Scott Kitterman :
> On Monday, October 10, 2011 05:03:09 PM Sebastien Bacher wrote:
> > Le lundi 19 septembre 2011 à 22:03, Benjamin Drung a écrit :
> > > Why not discourage REVU completely?
> > 
> > Reducing the number of sites in use and consolidating the
> > workflows seems like a good idea indeed ;-)
> 
> Where else is there a site that you can upload successive
> versions of packages with the same version number and see diffs
> between the uploads?

mentors.debian.net ?

It's what I recently used when I wanted to get a package into
Ubuntu... I pushed it into Debian first.

/ac

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

Re: Getting new packages into Ubuntu

[Alex Chiang]

* Scott Kitterman :
> On Monday, October 10, 2011 08:49:37 AM Alex Chiang wrote:
> > * Scott Kitterman :
> > > Where else is there a site that you can upload successive
> > > versions of packages with the same version number and see
> > > diffs between the uploads?
> > 
> > mentors.debian.net ?
> > 
> > It's what I recently used when I wanted to get a package into
> > Ubuntu... I pushed it into Debian first.
> 
> That's certainly a great (and generally preferred) way to do
> it.  I don't think it supports this particular functionality,
> however.

Hm, I think you're right.

You can upload the same package multiple times with the same
version number, but I don't see a way to easily find the diff.

Here's the first package I saw on the page...
http://mentors.debian.net/package/snes9x

Perhaps mentors.d.n could be taught to keep a few older versions
and then do the diffs?

/ac

ps, my mails are getting held up in moderation

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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 08:34:48 PM Sebastien Bacher wrote:
> Well, do you think that letting the universe unfrozen under feature
> freeze rules would improve its stability or lower it? I think it would
> improve it since we could keep fixing bugs.

How does feature freeze prevent fixing bugs?

Scott K

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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 07:52:44 PM Sebastien Bacher wrote:
> Le lundi 10 octobre 2011 à 13:15 -0400, Scott Kitterman a écrit :
> > I understand what you're saying.  It's not a distro I would use.
> 
> Ok, fair enough, let's agree that we disagree then. Just one question
> then, do you consider a feature (i.e a good thing) that upstreams have
> to get "locked" in our 6 months cycle or do you think that's something
> we should aim at fixing in some way?
> 
> Let's take a simple example, we got a new login manager (lightdm) this
> cycle, from reading blogs some users who miss having a graphical tool to
> tweak the config of their login screen started hacking on an utility
> called "simple-lightdm-manager", that started too late to get in Oneiric
> though and the quality might not be archive ready. How do you recommend
> we solve the issue that some users might be interested to get that sort
> of utility and use them on Oneiric? If upstream is adding features as
> time permit and is adding an option to pick the greeter to use in 2
> weeks which should Ubuntu users need to wait 6 months and the lts to get
> their hands on it?

First, I think that things are getting pushed into the distro before they are 
really ready.  Also there are upstreams that push to get last minute features 
in (e.g. Unity) and so there are consequences when there are unexpected side 
effects.  One way to reduce the amount of post-release desire for churn due to 
missing things is to get things into the release on time and then people have 
a chance to adapt.

For the more general case of leaf packages that would benefit from updating, I 
think that get it into the next release and then backport it solves most 
cases.  It can even be used for libraries on a reasonable basis if adeequate 
testing is done.

I don't see how there's any need to be locked in.

Scott K

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 20:05 +0200, Stefano Rivera a écrit :

> I'm still sitting on the fence about ARB in general. I think lowering
> the barrier to entry for new apps is probably a good idea. It does come
> with downsides:
> * We need to divert manpower to packaging these apps. On the other hand,
>   that's volunteer time, and volunteers can work on whatever they want
>   to.

What is "packager" is not the solution? What is we made packaging easy
enough that upstream code get their software themself in extras? (you
need higher trust for the main archive but extras lower the barrier wit
no maintainer scripts use for example)

> * Every package needs to be explicitly uploaded to every release.
>   I imagine that it means that we'll start every release with a
>   relatively empty ARB store, and have a rush to get new apps in.
>   Some will then spend a month or two stabilising. Ubuntu's 6 month
>   release cycle may be too short for this to be an efficient process.

We might want to target mainly lts versions then for arb?

> * No obvious approaches to handling security issues or bug reports yet.
>   I got a single report for my ARB app, by a user who found the source
>   and hunted me down. (And I haven't dealt with it yet, eep)

How does android or app stores deal with those? Do we need to deal with
those or can we just treat those as any software you download from the
internet and let users deal with software writes?

> * It doesn't deal very well with libraries that aren't in Ubuntu. (And
>   with the vague proposal of having a tiny Ubuntu core, main, without
>   universe, this becomes a much larger problem). They need to be bundled
>   with every app. This poses security problems, even if it does make the
>   app author's lives easier.

We shouldn't aim at getting libraries in extras, the libraries should be
part of the platform an in the archive itself then.

> > One other way would be perhaps to stop freezing universe at release and
> > to let softwares elvolve in a least strict way...
> 
> I'm sure there'd be people who'd appreciate that (it sounds rather
> ports-ish), but I'm already concerned about the stability of Universe as
> it is (MOTU is rather understaffed right now).

Well, do you think that letting the universe unfrozen under feature
freeze rules would improve its stability or lower it? I think it would
improve it since we could keep fixing bugs.


> Yes, I also got involved in Ubuntu because I wanted to get a
> (particularly minor) app, and all its dependencies in. I had also been a
> Debian user for a decade or so, and had always intended to get more
> involved in the development side of the distributions, so I might have
> been more naturally drawn in than others. But I'm pretty sure that if
> ARB had been available then, I would have used it, rather than sticking
> my nose into #ubuntu-motu and asking where I could help out.

Well you would perhaps have run into some issues where you need upgrades
or fixes to the "platform" side and looked at the "main" archive to get
those solved? Or you would have just contributed to extras and reach
users which is a valid contributions as well...

Cheers,
Sebastien Bacher



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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 14:06 -0400, Jeremy Bicha a écrit :
> 
> Instead of a new repository (extras or PPAs or whatever), why don't we
> use backports more to get new packages into the stable releases? 

Because backports requires to get your package in the archive first then
to get it backported, it's not easier than getting it in the archive,
it's harder, you first need to find you way to the archive, then to get
it backported. It also doesn't solve the issue of non maintained cruft
which get added to universe...

You also might want to track different series or versions in the current
unstable Ubuntu distro and the stable one.

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Barry Warsaw]

On Oct 10, 2011, at 02:06 PM, Jeremy Bicha wrote:

>Instead of a new repository (extras or PPAs or whatever), why don't we use
>backports more to get new packages into the stable releases?  Firefox and
>Chromium, though special, have at least opened the door more to stable
>updates that aren't just bug fixes.

Further, if we had "official PPAs" we could perhaps do some automated
promotion from an official PPA into backports, so users wouldn't have to
add-apt-repository for dozens of packages.

Many projects already have de-facto official PPAs, and these are great for
getting access to newer versions of packages in your current Ubuntu version,
or even packages which aren't available at all (e.g. pypy).  Unfortunately,
there's no way to mark PPAs as "official" so users may not be able to rely on
the reputation of the PPA uploaders.

A promotion from PPA would still require a rebuild to ensure the consistency
of the archive being promoted into.  Maybe backports is the right archive for
these promotions, or maybe some other channel would be best, but it would be
nice if it were easy for users to enable it.

-Barry

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

Re: Getting new packages into Ubuntu

[Jeremy Bicha]

On 10 October 2011 13:52, Sebastien Bacher  wrote:
> Le lundi 10 octobre 2011 à 13:15 -0400, Scott Kitterman a écrit :
>> I understand what you're saying.  It's not a distro I would use.
>
> Ok, fair enough, let's agree that we disagree then. Just one question
> then, do you consider a feature (i.e a good thing) that upstreams have
> to get "locked" in our 6 months cycle or do you think that's something
> we should aim at fixing in some way?
>
> Let's take a simple example, we got a new login manager (lightdm) this
> cycle, from reading blogs some users who miss having a graphical tool to
> tweak the config of their login screen started hacking on an utility
> called "simple-lightdm-manager", that started too late to get in Oneiric
> though and the quality might not be archive ready. How do you recommend
> we solve the issue that some users might be interested to get that sort
> of utility and use them on Oneiric? If upstream is adding features as
> time permit and is adding an option to pick the greeter to use in 2
> weeks which should Ubuntu users need to wait 6 months and the lts to get
> their hands on it?

Instead of a new repository (extras or PPAs or whatever), why don't we
use backports more to get new packages into the stable releases?
Firefox and Chromium, though special, have at least opened the door
more to stable updates that aren't just bug fixes.

Personally, I've never been fully convinced of the value of the extras
repositorywhich hasn't really resulted in a flood of great apps
yet. Perhaps that's because of all the restrictions and the fact that
there are several other ways to get apps into Ubuntu.

Jeremy Bicha

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

Re: Getting new packages into Ubuntu

[Stefano Rivera]

Hi Sebastien (2011.10.10_18:08:16_+0200)
> - there are lot of people out there who writer softwares and have no
> interest to learn enough about Ubuntu to become a MOTU, they just want
> to reach users, they should be welcome to join as well and in a way
> which is not to difficult for them

I'm still sitting on the fence about ARB in general. I think lowering
the barrier to entry for new apps is probably a good idea. It does come
with downsides:
* We need to divert manpower to packaging these apps. On the other hand,
  that's volunteer time, and volunteers can work on whatever they want
  to.
* Every package needs to be explicitly uploaded to every release.
  I imagine that it means that we'll start every release with a
  relatively empty ARB store, and have a rush to get new apps in.
  Some will then spend a month or two stabilising. Ubuntu's 6 month
  release cycle may be too short for this to be an efficient process.
* No obvious approaches to handling security issues or bug reports yet.
  I got a single report for my ARB app, by a user who found the source
  and hunted me down. (And I haven't dealt with it yet, eep)
* It doesn't deal very well with libraries that aren't in Ubuntu. (And
  with the vague proposal of having a tiny Ubuntu core, main, without
  universe, this becomes a much larger problem). They need to be bundled
  with every app. This poses security problems, even if it does make the
  app author's lives easier.

> - you were recently complaining as well about the number of packages
> that see one upload and stop being maintained that we have to fix then,
> do we want those in the main archive because they attract people or
> would they be better suited in extras?

Yes, this would help with that. I seem to remember an earlier proposal,
where, if an app was still popular after a release or two, it would be
strongly encouraged to be included in Universe / Debian.

> - locking upstream softwares to our release cycle just don't fit, it's a
> best un-natural and create extra work, it often means that users get
> outdated softwares or versions that upstreams want to replace

That is another reasonable advantage.

> One other way would be perhaps to stop freezing universe at release and
> to let softwares elvolve in a least strict way...

I'm sure there'd be people who'd appreciate that (it sounds rather
ports-ish), but I'm already concerned about the stability of Universe as
it is (MOTU is rather understaffed right now).


Yes, I also got involved in Ubuntu because I wanted to get a
(particularly minor) app, and all its dependencies in. I had also been a
Debian user for a decade or so, and had always intended to get more
involved in the development side of the distributions, so I might have
been more naturally drawn in than others. But I'm pretty sure that if
ARB had been available then, I would have used it, rather than sticking
my nose into #ubuntu-motu and asking where I could help out.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 13:15 -0400, Scott Kitterman a écrit :
> I understand what you're saying.  It's not a distro I would use.

Ok, fair enough, let's agree that we disagree then. Just one question
then, do you consider a feature (i.e a good thing) that upstreams have
to get "locked" in our 6 months cycle or do you think that's something
we should aim at fixing in some way?

Let's take a simple example, we got a new login manager (lightdm) this
cycle, from reading blogs some users who miss having a graphical tool to
tweak the config of their login screen started hacking on an utility
called "simple-lightdm-manager", that started too late to get in Oneiric
though and the quality might not be archive ready. How do you recommend
we solve the issue that some users might be interested to get that sort
of utility and use them on Oneiric? If upstream is adding features as
time permit and is adding an option to pick the greeter to use in 2
weeks which should Ubuntu users need to wait 6 months and the lts to get
their hands on it?

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 06:40:33 PM Sebastien Bacher wrote:
> Le lundi 10 octobre 2011 à 12:34 -0400, Scott Kitterman a écrit :
> > What rationale would there be for doing that for just Universe?  There
> > are
> > lots of leaf applications in Main and lots of libraries in Universe.
> 
> I think we should consider differently the system and the softwares so
> the using main and universe there might be wrong yes...
> 
> Using Ubuntu with Unity (or GNOME) as an example the "system" would be
> the plumber, plymouth, lightdm, the desktop shell and the features
> integrated with the desktop (image and documents viewers, file manager,
> etc). That part should be under a strict process, respect freezes, etc.
> 
> Then we have all the applications stack, basically things that microsoft
> users would go to install from the internet or that you would get from
> the appstores, those have no reason to have their freezes, schedules,
> etc tied to the OS itself or to the shell, they should be easier to
> update and be able to follow the rhythms upstream want to use for their
> softwares...
> 
> Does it make sense?

I understand what you're saying.  It's not a distro I would use.

Scott K

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

Re: Getting new packages into Ubuntu

[Barry Warsaw]

On Oct 10, 2011, at 12:33 PM, Scott Kitterman wrote:

>Generally for new packages I find it easier to see changes in both together
>as, more than once, I've dealt with an upstream developer who was trying to
>roll a correct upstream tarball for a proper release as well as get the
>packaging right in parallel.

I'd say that even for existing packages, I find it much nicer to deal with
full source than just debian/.  I do the former mostly with Ubuntu packages
and the latter mostly with Debian packages, and I personally find the UDD way
the nicest of the options.

>I don't think our current VCS situation is fast enough or easy enough to use 
>to be a replacement for REVU.  While I use /debian VCS branches in Kubuntu (a 
>lot), I don't find they work very well for new packages.  YMMV, of course.

Agreed that for some packages and/or personal development environments,
Ubuntu's packaging branches (i.e. UDD) isn't yet convenient, fast, or easy
enough to use.  Improving those issues is (I believe) very high up on the
udd/bzr team's agenda.  I highly encourage interested folks[1] to engage[2]
with that team and help make it better.  Especially with coming Launchpad
integration features such as build-from-branch-into-ppa and -into-archive, I
think this will make for a very compelling and much easier workflow for
developing Ubuntu.

I should note too that I personally use source branches on probably 95% of
packages I touch, which may not be representative of the whole archive, but
still.  The ones I have to hack on old skool are generally because of package
importer issues, which are becoming much more rare, again thanks to the great
work of the udd/bzr team.  It always feels much more uncomfortable to do
things the apt-get source way though.  YMMV.

Cheers,
-Barry

[1] I know ScottK knows all this already :)
[2] https://wiki.ubuntu.com/DistributedDevelopment

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 12:34 -0400, Scott Kitterman a écrit :
> What rationale would there be for doing that for just Universe?  There
> are 
> lots of leaf applications in Main and lots of libraries in Universe. 

I think we should consider differently the system and the softwares so
the using main and universe there might be wrong yes...

Using Ubuntu with Unity (or GNOME) as an example the "system" would be
the plumber, plymouth, lightdm, the desktop shell and the features
integrated with the desktop (image and documents viewers, file manager,
etc). That part should be under a strict process, respect freezes, etc. 

Then we have all the applications stack, basically things that microsoft
users would go to install from the internet or that you would get from
the appstores, those have no reason to have their freezes, schedules,
etc tied to the OS itself or to the shell, they should be easier to
update and be able to follow the rhythms upstream want to use for their
softwares...

Does it make sense?

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 06:08:16 PM Sebastien Bacher wrote:
> Le lundi 10 octobre 2011 à 16:41 +0100, Colin Watson a écrit :
> > It's pretty much how I got involved in Debian, way back when.
> 
> Great, it's also how I started in Debian back then ;-)
> 
> Debian and Ubuntu are great communities and will keep attracting people
> who have interest in doing that sort of work but...
> 
> - there are lot of people out there who writer softwares and have no
> interest to learn enough about Ubuntu to become a MOTU, they just want
> to reach users, they should be welcome to join as well and in a way
> which is not to difficult for them
> - you were recently complaining as well about the number of packages
> that see one upload and stop being maintained that we have to fix then,
> do we want those in the main archive because they attract people or
> would they be better suited in extras?
> - locking upstream softwares to our release cycle just don't fit, it's a
> best un-natural and create extra work, it often means that users get
> outdated softwares or versions that upstreams want to replace
> 
> One other way would be perhaps to stop freezing universe at release and
> to let softwares elvolve in a least strict way...

What rationale would there be for doing that for just Universe?  There are 
lots of leaf applications in Main and lots of libraries in Universe.

Scott K

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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 06:13:13 PM Sebastien Bacher wrote:
> Le lundi 10 octobre 2011 à 11:59 -0400, Scott Kitterman a écrit :
> > For /debian or the full source?
> 
> We tend to have only the debian directory in the vcs, it's easier to
> work with and combined with the upstream tarballs you get what you need

Generally for new packages I find it easier to see changes in both together as, 
more than once, I've dealt with an upstream developer who was trying to roll a 
correct upstream tarball for a proper release as well as get the packaging 
right in parallel. 

I don't think our current VCS situation is fast enough or easy enough to use 
to be a replacement for REVU.  While I use /debian VCS branches in Kubuntu (a 
lot), I don't find they work very well for new packages.  YMMV, of course.

Scott K

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 11:59 -0400, Scott Kitterman a écrit :
> For /debian or the full source?

We tend to have only the debian directory in the vcs, it's easier to
work with and combined with the upstream tarballs you get what you need

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

Sebastien Bacher  wrote:

>Le lundi 10 octobre 2011 à 11:44 -0400, Scott Kitterman a écrit :
>> 
>> Where else is there a site that you can upload successive versions of
>> packages 
>> with the same version number and see diffs between the uploads? 
>
>Well, for desktop packages we do the packaging in a vcs and use the vcs
>history and diffs...

For /debian or the full source?

Scott K


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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 16:41 +0100, Colin Watson a écrit :
> It's pretty much how I got involved in Debian, way back when.

Great, it's also how I started in Debian back then ;-)

Debian and Ubuntu are great communities and will keep attracting people
who have interest in doing that sort of work but...

- there are lot of people out there who writer softwares and have no
interest to learn enough about Ubuntu to become a MOTU, they just want
to reach users, they should be welcome to join as well and in a way
which is not to difficult for them
- you were recently complaining as well about the number of packages
that see one upload and stop being maintained that we have to fix then,
do we want those in the main archive because they attract people or
would they be better suited in extras?
- locking upstream softwares to our release cycle just don't fit, it's a
best un-natural and create extra work, it often means that users get
outdated softwares or versions that upstreams want to replace

One other way would be perhaps to stop freezing universe at release and
to let softwares elvolve in a least strict way...

--
Sebastien Bacher




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

Re: Getting new packages into Ubuntu

[Iain Lane]

Hey,

On Mon, Oct 10, 2011 at 11:53:38AM -0400, Scott Kitterman wrote:
> On Monday, October 10, 2011 08:49:37 AM Alex Chiang wrote:
> > * Scott Kitterman :
> > > On Monday, October 10, 2011 05:03:09 PM Sebastien Bacher wrote:
> > > > Le lundi 19 septembre 2011 à 22:03, Benjamin Drung a écrit :
> > > > > Why not discourage REVU completely?
> > > > 
> > > > Reducing the number of sites in use and consolidating the
> > > > workflows seems like a good idea indeed ;-)
> > > 
> > > Where else is there a site that you can upload successive
> > > versions of packages with the same version number and see diffs
> > > between the uploads?
> > 
> > mentors.debian.net ?
> > 
> > It's what I recently used when I wanted to get a package into
> > Ubuntu... I pushed it into Debian first.
> 
> That's certainly a great (and generally preferred) way to do it.  I don't 
> think it supports this particular functionality, however.

I just filed this

  
https://alioth.debian.org/tracker/index.php?func=detail&aid=313388&group_id=100127&atid=413115

and FWIW there is also this bug which is relevant to deprecating REVU

  
https://alioth.debian.org/tracker/index.php?func=detail&aid=313345&group_id=100127&atid=413115

If there are any other features that debexpo should take from REVU then
please file requests for them.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
PhD student   [ i...@cs.nott.ac.uk ]


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 11:44 -0400, Scott Kitterman a écrit :
> 
> Where else is there a site that you can upload successive versions of
> packages 
> with the same version number and see diffs between the uploads? 

Well, for desktop packages we do the packaging in a vcs and use the vcs
history and diffs...

Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 05:50:29 PM Benjamin Drung wrote:
> Am Montag, den 10.10.2011, 11:44 -0400 schrieb Scott Kitterman:
> > On Monday, October 10, 2011 05:03:09 PM Sebastien Bacher wrote:
> > > Le lundi 19 septembre 2011 à 22:03 +0200, Benjamin Drung a écrit :
> > > > Why not discourage REVU completely?
> > > 
> > > Reducing the number of sites in use and consolidating the workflows
> > > seems like a good idea indeed ;-)
> > 
> > Where else is there a site that you can upload successive versions of
> > packages with the same version number and see diffs between the
> > uploads?
> 
> Debian mentors could gain this feature.

Yes.  It could, but before we throw away working tools with unique features, 
let's have that capability somewhere else.  I find when I'm working with 
someone on a new package for Ubuntu the is absoutely killer for making it 
easier.

Scott K

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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 08:49:37 AM Alex Chiang wrote:
> * Scott Kitterman :
> > On Monday, October 10, 2011 05:03:09 PM Sebastien Bacher wrote:
> > > Le lundi 19 septembre 2011 à 22:03, Benjamin Drung a écrit :
> > > > Why not discourage REVU completely?
> > > 
> > > Reducing the number of sites in use and consolidating the
> > > workflows seems like a good idea indeed ;-)
> > 
> > Where else is there a site that you can upload successive
> > versions of packages with the same version number and see diffs
> > between the uploads?
> 
> mentors.debian.net ?
> 
> It's what I recently used when I wanted to get a package into
> Ubuntu... I pushed it into Debian first.

That's certainly a great (and generally preferred) way to do it.  I don't 
think it supports this particular functionality, however.

Scott K

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

Re: Getting new packages into Ubuntu

[Benjamin Drung]

Am Montag, den 10.10.2011, 11:44 -0400 schrieb Scott Kitterman:
> On Monday, October 10, 2011 05:03:09 PM Sebastien Bacher wrote:
> > Le lundi 19 septembre 2011 à 22:03 +0200, Benjamin Drung a écrit :
> > > Why not discourage REVU completely?
> > 
> > Reducing the number of sites in use and consolidating the workflows
> > seems like a good idea indeed ;-)
> 
> Where else is there a site that you can upload successive versions of 
> packages 
> with the same version number and see diffs between the uploads?

Debian mentors could gain this feature.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 04:42:44 PM Sebastien Bacher wrote:
> Le lundi 10 octobre 2011 à 10:23 -0400, Scott Kitterman a écrit :
> > If we try to reduce the work to the available developers by reducing
> > the scope
> > of the archive, then we are also reducing the pool of potentially
> > interested
> > developers as well.
> 
> There is still enough in the system components stack (or main) to be
> interesting, do you think a stack of unmaintained "small softwares" in
> universe is what makes people want to join the project? They could join
> the same way to help getting those in extras with the benefits that:
> - they wouldn't need to get access to the main archive, so their job
> would be easier
> - it wouldn't add new things to universe that will stay there if whoever
> has been added those lost interest and create extra work
> - it wouldn't force upstream developers to fit in an artificial 6 months
> cycle which might not work for their project
> 
> It does make sense to freeze and ship a consistent archive for the
> system components (base system, plumbers, desktop shells, default
> applications), it doesn't make sense to try to make small softwares
> (ubuntu-tweaks, simple-lightdm-manager, etc) respect our freezes, cycle,
> rely on acl to upload to the main archive, etc

I disagree.  FWIW, if this kind of system had been in place in 2007, I 
probably wouldn't be an Ubuntu developer today.

I think people join when they can work on something that interests them.  By 
shrinking the scope of what we consider for the archive, you are shrinking the 
scope of potentially interested people.  

OTOH, I don't mind being aggressive about cruft removal where stuff is not 
looked after in Debian or Ubuntu.  If you filter leaf packages at the front 
end, you filter both the packages and potential developers.  If you remove them 
when they cause problems, then you leave yourself open to new contributors.

A lot of this also revolves around the question of what Ubuntu is.  Is it 
meant to be a distribution that supports user's needs or just a core that 
randome third parties offer functionality on top of.  Historically it's aimed 
to be the former and I like it that way.

Scott K

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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 05:03:09 PM Sebastien Bacher wrote:
> Le lundi 19 septembre 2011 à 22:03 +0200, Benjamin Drung a écrit :
> > Why not discourage REVU completely?
> 
> Reducing the number of sites in use and consolidating the workflows
> seems like a good idea indeed ;-)

Where else is there a site that you can upload successive versions of packages 
with the same version number and see diffs between the uploads?

Scott K

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

Re: Getting new packages into Ubuntu

[Colin Watson]

On Mon, Oct 10, 2011 at 04:42:44PM +0200, Sebastien Bacher wrote:
> There is still enough in the system components stack (or main) to be
> interesting, do you think a stack of unmaintained "small softwares" in
> universe is what makes people want to join the project?

It's pretty much how I got involved in Debian, way back when.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 16:09 +0100, Allison Randal a écrit :

> 
> We essentially have three classes of packages in Ubuntu:
> 
> - Lightweight applications, which I would encourage to apply through
> developer.ubuntu.com (i.e. Extras/ARB), and we can help the developer
> figure out if it makes sense to release through extras, submit upstream
> to Debian (possibly combined with an Ubuntu backport, depending on where
> we are in the cycle), or submit to main/universe.
> 
> - General purpose system components, large applications, and everything
> else that isn't specific to Ubuntu. These should submit upstream to Debian.

Right, I totally agree with you on those.

> REVU isn't
> very actively used/developed at the moment.

Speaking for desktop where we get our share of new system components
every cycle they tend to be packaged by existant team members rather
than new comers, we also like better to use launchpad that REVU because
it fits better in our worflow (we can milestone, tag, subscribe people,
use our normal scripts and filter for emails, etc)

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Allison Randal]

On 10/10/2011 03:42 PM, Sebastien Bacher wrote:
> Le lundi 10 octobre 2011 à 10:23 -0400, Scott Kitterman a écrit :
>>
>> If we try to reduce the work to the available developers by reducing
>> the scope 
>> of the archive, then we are also reducing the pool of potentially
>> interested 
>> developers as well. 
> 
> It does make sense to freeze and ship a consistent archive for the
> system components (base system, plumbers, desktop shells, default
> applications), it doesn't make sense to try to make small softwares
> (ubuntu-tweaks, simple-lightdm-manager, etc) respect our freezes, cycle,
> rely on acl to upload to the main archive, etc

We essentially have three classes of packages in Ubuntu:

- Lightweight applications, which I would encourage to apply through
developer.ubuntu.com (i.e. Extras/ARB), and we can help the developer
figure out if it makes sense to release through extras, submit upstream
to Debian (possibly combined with an Ubuntu backport, depending on where
we are in the cycle), or submit to main/universe.

- General purpose system components, large applications, and everything
else that isn't specific to Ubuntu. These should submit upstream to Debian.

- System components that are specific to Ubuntu. There aren't many of
these, but they do exist. They only really make sense when tied to a
particular release, and need the benefit of integration testing with
that release, so should participate in the usual Ubuntu development
cycle. It's not entirely clear what channel these should use. If it's
not a large set of packages, perhaps the current practice of working
through the human network of Ubuntu developers is enough. REVU isn't
very actively used/developed at the moment.

Allison

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 19 septembre 2011 à 22:03 +0200, Benjamin Drung a écrit :
> Why not discourage REVU completely?

Reducing the number of sites in use and consolidating the workflows
seems like a good idea indeed ;-)

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 10 octobre 2011 à 10:23 -0400, Scott Kitterman a écrit :
> 
> If we try to reduce the work to the available developers by reducing
> the scope 
> of the archive, then we are also reducing the pool of potentially
> interested 
> developers as well. 

There is still enough in the system components stack (or main) to be
interesting, do you think a stack of unmaintained "small softwares" in
universe is what makes people want to join the project? They could join
the same way to help getting those in extras with the benefits that:
- they wouldn't need to get access to the main archive, so their job
would be easier
- it wouldn't add new things to universe that will stay there if whoever
has been added those lost interest and create extra work
- it wouldn't force upstream developers to fit in an artificial 6 months
cycle which might not work for their project

It does make sense to freeze and ship a consistent archive for the
system components (base system, plumbers, desktop shells, default
applications), it doesn't make sense to try to make small softwares
(ubuntu-tweaks, simple-lightdm-manager, etc) respect our freezes, cycle,
rely on acl to upload to the main archive, etc

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Scott Kitterman]

On Monday, October 10, 2011 12:03:44 PM Sebastien Bacher wrote:
> Le mardi 20 septembre 2011 à 16:10 +0200, Matthias Klose a écrit :
> > not sure I do understand you. What reason did they give to have it in
> > the
> > distribution in the first place?
> 
> Upstream don't care much about "being in the distribution" I think, what
> they care about is to reach users and have their code easy to install.
> 
> It's maybe time that we start pushing upstream to get their softwares in
> extras.ubuntu.com and not in the distribution? The processes we use make
> sense for the system components, not so much for random applications,
> it's neither good for upstreams (too hard to get things in the archive
> because we have higher quality standards that they might have), nor for
> us (we often get to maintain things that are left unmaintained there).
> What happens messaging that the archive is for the system components and
> that third party applications should not aim to get there?

I think that would be a remarkable change in what we think a distribution is.  
Not a good one either I don't think.

If we try to reduce the work to the available developers by reducing the scope 
of the archive, then we are also reducing the pool of potentially interested 
developers as well.  I'd rather grow into solving the problem than try to cut 
our way out of it.

Scott K

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le mardi 20 septembre 2011 à 16:10 +0200, Matthias Klose a écrit :
> not sure I do understand you. What reason did they give to have it in
> the
> distribution in the first place? 

Upstream don't care much about "being in the distribution" I think, what
they care about is to reach users and have their code easy to install.

It's maybe time that we start pushing upstream to get their softwares in
extras.ubuntu.com and not in the distribution? The processes we use make
sense for the system components, not so much for random applications,
it's neither good for upstreams (too hard to get things in the archive
because we have higher quality standards that they might have), nor for
us (we often get to maintain things that are left unmaintained there).
What happens messaging that the archive is for the system components and
that third party applications should not aim to get there?

--
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Daniel Holbach]

Salut Sébastien,

Am 10.10.2011 11:32, schrieb Sebastien Bacher:
> Thinking a bit about that, is there any reason we don't recommend in
> that list to use the appreview board and get things in
> extras.ubuntu.com? Getting things in the main archive and following the
> Ubuntu cycles means extra work and less flexibility, most software
> writes nowadays probably want the ppa or extras flexibility to
> distribute their softwares

no objections from me. If we offer different processes to get new
packages into Ubuntu, two things matter to me:

 - the process should be working well and the docs clear and tools
   easy to use
 - we should make sure that we explain the advantages and expectations
   of the processes clearly

Have a great day,
 Daniel

-- 
Get involved in Ubuntu development! developer.ubuntu.com/packaging
Stay up to date: follow @ubuntudev on identi.ca/twitter.com/facebook.com

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

Re: Getting new packages into Ubuntu

[Sebastien Bacher]

Le lundi 19 septembre 2011 à 12:28 +0200, Daniel Holbach a écrit :
> Thanks for your thoughts in advance.

Hey Daniel, 

Thinking a bit about that, is there any reason we don't recommend in
that list to use the appreview board and get things in
extras.ubuntu.com? Getting things in the main archive and following the
Ubuntu cycles means extra work and less flexibility, most software
writes nowadays probably want the ppa or extras flexibility to
distribute their softwares

Cheers,
Sebastien Bacher


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

Re: Getting new packages into Ubuntu

[Daniel Holbach]

Hello,

Am 20.09.2011 10:17, schrieb Stefano Zacchiroli:
> I suggest that you work with the people who have been animating over the
> past few years the debian-mentors community to ensure that mentoring
> activities are sustainable, no matter the load or the number of
> derivatives distro that want to participate into it. Many great
> proposals have been advanced, and partly already implemented, in recent
> years. They have been discussed at length in at least a couple of
> DebConf11 events:
> 
> - http://penta.debconf.org/dc11_schedule/events/777.en.html
> - http://penta.debconf.org/dc11_schedule/events/781.en.html

does anyone have a good summary or overview of what was discussed or
decided? I'd love for us to do and promote the right thing, so if we
need to fix our tools and documentation to make this happen it sounds
like a very worthwhile effort.

Have a great day,
 Daniel

-- 
Get involved in Ubuntu development! developer.ubuntu.com/packaging
Stay up to date: follow @ubuntudev on identi.ca/twitter.com/facebook.com

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

Re: Getting new packages into Ubuntu

[Colin Watson]

On Mon, Sep 19, 2011 at 10:07:02PM +0100, Colin Watson wrote:
> On Mon, Sep 19, 2011 at 04:51:37PM -0400, Marc Deslauriers wrote:
> > I'm slightly curious. If someone managed to get a package in Ubuntu, but
> > then stopped maintaining it, why would encouraging him to get it into
> > Debian make him more likely to maintain it?
> 
> My observation is that Debian is more proactive about removing packages
> that are no longer maintained than we are, and we semi-automatically
> follow removals from Debian.

It occurs to me that the essential conflict here is between approaches
that maximise the health of Ubuntu as a distribution, and approaches
that maximise the productivity of individual newcomer developers.  The
goals overlap, but not perhaps as much as we might like.  No, I don't
know how to resolve this ...

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Getting new packages into Ubuntu

[Colin Watson]

On Tue, Sep 20, 2011 at 12:59:07PM +0100, Jonathan Lange wrote:
> On Mon, Sep 19, 2011 at 8:55 PM, Colin Watson  wrote:
> > On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
> >> If we're going to focus on making this easier, can we focus on the
> >> first two options? Historically speaking, packages that live solely in
> >> Ubuntu and aren't part of any release's user experience tend to end up
> >> largely orphaned by a MOTU team that's overworked and understaffed.
> >
> > Amen.  Even just from fixing builds over the last few weeks, I'm getting
> > tired of fixing stuff that was stuffed into Ubuntu a few releases ago
> > and then ignored!
> 
> Do those who stuffed it in get alerted of breaks?

There were bug reports; they were supposed to subscribe to bug reports
on the package (although of course they might have forgotten; but one
might expect subscribing to bug reports to be appropriate due diligence
when asking Ubuntu to distribute your package).

> What reason would they have to care?

What reason does any developer have to care about bug reports?

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Getting new packages into Ubuntu

[Mackenzie Morgan]

On Tue, Sep 20, 2011 at 10:10 AM, Matthias Klose  wrote:
> On 09/20/2011 01:59 PM, Jonathan Lange wrote:
>> Do those who stuffed it in get alerted of breaks?
>
> yes, see my emails to -announce about build failures.  Then have a look at
> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html
> and hover over the version numbers to see the ones who to blame ;) No, there 
> is
> no automatic notification (same for merges).

Debian automatically notifies by email everyone in Maintainer: and
Uploader: fields if it breaks up there. Could go with an auto-email to
the TIL.

>> What reason would they have to care?
>
> not sure I do understand you. What reason did they give to have it in the
> distribution in the first place?

A mistaken belief that packaging new stuff was a necessary pre-cursor
to getting upload rights. Persia disavowed me of that belief before my
MOTU application.

-- 
Mackenzie Morgan

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

Re: Getting new packages into Ubuntu

[Matthias Klose]

On 09/20/2011 01:59 PM, Jonathan Lange wrote:
> On Mon, Sep 19, 2011 at 8:55 PM, Colin Watson  wrote:
>> On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
>>> If we're going to focus on making this easier, can we focus on the
>>> first two options? Historically speaking, packages that live solely in
>>> Ubuntu and aren't part of any release's user experience tend to end up
>>> largely orphaned by a MOTU team that's overworked and understaffed.
>>
>> Amen.  Even just from fixing builds over the last few weeks, I'm getting
>> tired of fixing stuff that was stuffed into Ubuntu a few releases ago
>> and then ignored!
> 
> Do those who stuffed it in get alerted of breaks?

yes, see my emails to -announce about build failures.  Then have a look at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html
and hover over the version numbers to see the ones who to blame ;) No, there is
no automatic notification (same for merges).

> What reason would they have to care?

not sure I do understand you. What reason did they give to have it in the
distribution in the first place?

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

Re: Getting new packages into Ubuntu

[Jonathan Lange]

On Mon, Sep 19, 2011 at 8:55 PM, Colin Watson  wrote:
> On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
>> If we're going to focus on making this easier, can we focus on the
>> first two options? Historically speaking, packages that live solely in
>> Ubuntu and aren't part of any release's user experience tend to end up
>> largely orphaned by a MOTU team that's overworked and understaffed.
>
> Amen.  Even just from fixing builds over the last few weeks, I'm getting
> tired of fixing stuff that was stuffed into Ubuntu a few releases ago
> and then ignored!

Do those who stuffed it in get alerted of breaks? What reason would
they have to care?

jml

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

Re: Getting new packages into Ubuntu

[Barry Warsaw]

On Sep 19, 2011, at 02:07 PM, Alex Chiang wrote:

>I did manage to get good feedback about my python module from
>both debian-mentors mailing list and #debian-python. It's partly
>a matter of finding time to address comments; partly that
>Packaging Is Hard, even for someone who kinda knows what they're
>doing.

Just a small point: for Python specific packages, the debian-python mailing
list is probably better than the general mentors list.  Other teams may also
have more specific lists that can help you too, so you should look up
whatever's relevant for your interests.

On a more general note, while I agree that it's preferable to get packages
into Ubuntu by way of Debian, it's important to recognize that the two distros
have very different workflows, schedules, tools, and cultures.  Both work very
well when you're mainly concentrating on one distro or the other, but there
are still a lot of rough spots when crossing over between the two.  It's true
that Ubuntu benefits greatly from the work done in Debian, and I think it
would be valuable to find ways for Debian to benefit more from the work done
in Ubuntu.  Somehow it just seems there should be better ways to share bugs,
branches, reputation, reviews, and experience.

Cheers,
-Barry

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

Re: Getting new packages into Ubuntu

[Daniel Holbach]

Hello,

Am 19.09.2011 22:07, schrieb Alex Chiang:
> I did manage to get good feedback about my python module from
> both debian-mentors mailing list and #debian-python. It's partly
> a matter of finding time to address comments; partly that
> Packaging Is Hard, even for someone who kinda knows what they're
> doing.

I agree that it's good to know who to get in touch with about a certain
package if the team or the person is in the same area of expertise. We
list a number of Debian teams at

https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages


> I don't know what we could do in Ubuntu to make the Debian
> mentorship process better, other than helping review packages on
> d-m, and potentially uploading packages if you are a DD (or have
> other upload rights).

There has been a lot of agreement in this thread about getting packages
into Debian first, which is reasonable. (If there's an immediate demand
for having the package in Ubuntu, we can still just sponsor it into
Ubuntu, for example if there are to work-around differing freeze dates.)

If we see this as a solution to the problem, what would need to be done
to push harder for this?

Have a great day,
 Daniel

-- 
Get involved in Ubuntu development! developer.ubuntu.com/packaging
Stay up to date: follow @ubuntudev on identi.ca/twitter.com/facebook.com

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

Re: Getting new packages into Ubuntu

[Stefano Zacchiroli]

On Mon, Sep 19, 2011 at 01:27:42PM -0700, Allison Randal wrote:
> But, I think the deeper question is whether developers here in Ubuntu,
> who would have been looking at the REVU queues, would be willing to
> spend that time reviewing the same package proposals for Debian. You
> don't have to be a DD or DM to do package reviews in the new
> mentors.debian.net. It's beneficial to direct new packages upstream, but
> we also need to recognize the workload we're adding to the Debian
> volunteers if we send all new package reviews to Debian.

Let me comment that it's great to see people here discuss the practice
of getting packages into Debian first, as a mean to have then in Ubuntu.
Doing so is indeed the best way to contribute Free Software not only to
Debian and Ubuntu, but also to other hundreds of derived distributions
out there that benefit from contributions that reach Debian.

I also want to AOL the concern mentioned in this thread that packaging
is not a one shot activity, rather it is a medium-term commitment in
maintaining a package in good shape for the needs of a, or several,
distros. AFAICT this is the case both in Ubuntu and Debian, with
differences only in how each distro deals with the problem of
disappearing maintainers / maintenance team members. This point should
be made very clear to any wannabe packager, no matter the distro.

Up to now mentoring efforts were put both on the Debian side (via
debian-mentors and mentors.d.n) and on the Ubuntu side (via REVU, I
believe). The same goes for quality assurance efforts to get rid of
neglected packages over time.  Shifting reviews and QA to Debian is the
right thing to do (for the reasons mentioned above), but should be
sustainable. This is even more so because, as I understand, on the
Ubuntu side you were already lacking some mentoring power. Merely
summing that "negative delta" to the current debian-mentors load risks
to be detrimental to all involved distros, if done lightly.

I suggest that you work with the people who have been animating over the
past few years the debian-mentors community to ensure that mentoring
activities are sustainable, no matter the load or the number of
derivatives distro that want to participate into it. Many great
proposals have been advanced, and partly already implemented, in recent
years. They have been discussed at length in at least a couple of
DebConf11 events:

- http://penta.debconf.org/dc11_schedule/events/777.en.html
- http://penta.debconf.org/dc11_schedule/events/781.en.html

I'll be happy to put an of you in touch with Debian individuals active
on that front. They have way more experience than me on debian-mentors.
I'm sure they can provide more concrete suggestions than what I'm doing
with this mail.

I'd be great to have a single mentoring community for Debian-based
distros and it has chances to scale better than several such
communities.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Getting new packages into Ubuntu

[Colin Watson]

On Mon, Sep 19, 2011 at 04:51:37PM -0400, Marc Deslauriers wrote:
> On Mon, 2011-09-19 at 20:55 +0100, Colin Watson wrote:
> > On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
> > > If we're going to focus on making this easier, can we focus on the
> > > first two options? Historically speaking, packages that live solely in
> > > Ubuntu and aren't part of any release's user experience tend to end up
> > > largely orphaned by a MOTU team that's overworked and understaffed.
> > 
> > Amen.  Even just from fixing builds over the last few weeks, I'm getting
> > tired of fixing stuff that was stuffed into Ubuntu a few releases ago
> > and then ignored!
> 
> I'm slightly curious. If someone managed to get a package in Ubuntu, but
> then stopped maintaining it, why would encouraging him to get it into
> Debian make him more likely to maintain it?

My observation is that Debian is more proactive about removing packages
that are no longer maintained than we are, and we semi-automatically
follow removals from Debian.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Getting new packages into Ubuntu

[Marc Deslauriers]

On Mon, 2011-09-19 at 20:55 +0100, Colin Watson wrote:
> On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
> > If we're going to focus on making this easier, can we focus on the
> > first two options? Historically speaking, packages that live solely in
> > Ubuntu and aren't part of any release's user experience tend to end up
> > largely orphaned by a MOTU team that's overworked and understaffed.
> 
> Amen.  Even just from fixing builds over the last few weeks, I'm getting
> tired of fixing stuff that was stuffed into Ubuntu a few releases ago
> and then ignored!

I'm slightly curious. If someone managed to get a package in Ubuntu, but
then stopped maintaining it, why would encouraging him to get it into
Debian make him more likely to maintain it?

If I'm a developer who wants my package in Ubuntu, why would I want to
maintain it for Debian, a distro I don't even use?

It seems to me asking developers to get their software into Debian first
is likely to discourage them further.

Marc.



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

Re: Getting new packages into Ubuntu

[Alex Chiang]

* Evan Broder :
> On Mon, Sep 19, 2011 at 10:35 AM, Bryce Harrington  
> wrote:
> > On Mon, Sep 19, 2011 at 12:28:03PM +0200, Daniel Holbach wrote:
> >>
> >> The feedback I've got lately about getting new packages into Ubuntu is
> >> that it's still quite complicated and you need unreal amounts of
> >> patience to get your package in.

Yes.

> >> There's a number of different approaches you can take currently:
> >>
> >>  - get it into Debian, sync from there
> >>
> >> Is there anything we can do to speed up the process and make it more
> >> obvious how to proceed?

I'm trying to be a good citizen and get a new package in via
Debian, and it has taken me quite a while. To be fair, part of
the problem is that I haven't had the time away from $DAYJOB to
apply as much effort as I'd like.

I did manage to get good feedback about my python module from
both debian-mentors mailing list and #debian-python. It's partly
a matter of finding time to address comments; partly that
Packaging Is Hard, even for someone who kinda knows what they're
doing.

For instance, I've been modifying existing packages in Ubuntu for
a while now, and am comfortable with most patch systems and am
somewhat familiar with policy.

But packaging something brand new involves jumping over higher
(occasionally unexpected) hurdles than simply getting a debdiff
sponsored.

This is because the sponsor not only needs to review the entire
packaging (not just a diff), but also the source code to make
sure you're not uploading a new trojan to millions of machines
where you'll have root.

These are facts I've learned throughout my process, and when
explained this way, make perfect sense.

I'm not sure how this can be sped up.
 
> Can we work with Debian to make their mentorship process better
> (I know they've already been doing a bunch of work with things
> like mentors.debian.net, though I don't know how well it's
> working), and then make sure we have good documentation on the
> process?

Yeah, so I just blundered into mentors.debian.net and debexpo as
part of my google search on "how to get a package into debian".

On a mechanical level, the dput process is great; the same as I
use for Ubuntu.

The harder problem is then finding a reviewer and sponsor. The
docs suggest emailing debian-mentors, but could be improved by
mentioning that you should cc a relevant team.

Now that I've been on d-m for a few weeks, I see some people get
quite rapid reviews and rapid sponsorship. I also see other
people who are sending out their 3rd and 4th RFS without any
visible help.

For myself, I got good review comments from someone very
knowledgeable which I appreciated, but when I asked about
sponsorship, he said he wasn't able (or willing, unsure, really).
No one else stepped up to review or sponsor my package.

I have resorted to asking a DD that I know in Real Life(tm) to
sponsoring my package; he agreed to the actual sponsorship, and
now the ball is in my court to address his further review
comments.

The worst part of the process is that sending a blind mail to
debian-mentors is an action to which it is indeterminate whether
you receive a response or not.

I don't know what we could do in Ubuntu to make the Debian
mentorship process better, other than helping review packages on
d-m, and potentially uploading packages if you are a DD (or have
other upload rights).

/ac

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

Re: Getting new packages into Ubuntu

[Allison Randal]

On 09/19/2011 01:03 PM, Benjamin Drung wrote:
> 
> Why not discourage REVU completely?

I was looking through the lists of packages currently in REVU last week,
some sitting with no action for a long time. So far, I haven't seen any
packages that wouldn't have been better submitted to Debian. Now, there
is an information bias here, because the package proposals that were a
perfect match for direct addition to Ubuntu may have already been
successfully reviewed, approved, added to the archive and the proposals
closed out. The next useful data point, for any successful direct
additions from REVU, is whether we managed to propose them upstream to
Debian after inclusion in Ubuntu.

But, I think the deeper question is whether developers here in Ubuntu,
who would have been looking at the REVU queues, would be willing to
spend that time reviewing the same package proposals for Debian. You
don't have to be a DD or DM to do package reviews in the new
mentors.debian.net. It's beneficial to direct new packages upstream, but
we also need to recognize the workload we're adding to the Debian
volunteers if we send all new package reviews to Debian.

On my todo list for this week is talking with Asheesh and Stefano to get
a sense of how successful the new mentors.debian.net is so far.

Allison

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

Re: Getting new packages into Ubuntu

[Benjamin Drung]

Am Montag, den 19.09.2011, 20:55 +0100 schrieb Colin Watson:
> On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
> > If we're going to focus on making this easier, can we focus on the
> > first two options? Historically speaking, packages that live solely in
> > Ubuntu and aren't part of any release's user experience tend to end up
> > largely orphaned by a MOTU team that's overworked and understaffed.
> 
> Amen.  Even just from fixing builds over the last few weeks, I'm getting
> tired of fixing stuff that was stuffed into Ubuntu a few releases ago
> and then ignored!

Why not discourage REVU completely?

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: Getting new packages into Ubuntu

[Colin Watson]

On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
> If we're going to focus on making this easier, can we focus on the
> first two options? Historically speaking, packages that live solely in
> Ubuntu and aren't part of any release's user experience tend to end up
> largely orphaned by a MOTU team that's overworked and understaffed.

Amen.  Even just from fixing builds over the last few weeks, I'm getting
tired of fixing stuff that was stuffed into Ubuntu a few releases ago
and then ignored!

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Re: Getting new packages into Ubuntu

[Evan Broder]

On Mon, Sep 19, 2011 at 10:35 AM, Bryce Harrington  wrote:
> On Mon, Sep 19, 2011 at 12:28:03PM +0200, Daniel Holbach wrote:
>> Hello everybody,
>>
>> with the help of the nice people on the Debian derivatives mailing list,
>> we updated
>>
>>       https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
>>
>> Particularly the section about getting a package into Debian.
>>
>> The feedback I've got lately about getting new packages into Ubuntu is
>> that it's still quite complicated and you need unreal amounts of
>> patience to get your package in.
>>
>> There's a number of different approaches you can take currently:
>>
>>  - get it into Debian, sync from there
>>  - make use of the App Review Board process
>>  - make use of REVU
>>  - short-circuit by getting in touch with a team who sees an
>>    immediate need to get it in
>>
>> Is there anything we can do to speed up the process and make it more
>> obvious how to proceed?
>>
>> Thanks for your thoughts in advance.
>
> Isolate specifically what must be done by human reviewers, and make that
> really fun and easy.  Then automate everything else.
>
> Bryce

If we're going to focus on making this easier, can we focus on the
first two options? Historically speaking, packages that live solely in
Ubuntu and aren't part of any release's user experience tend to end up
largely orphaned by a MOTU team that's overworked and understaffed.

Can we work with Debian to make their mentorship process better (I
know they've already been doing a bunch of work with things like
mentors.debian.net, though I don't know how well it's working), and
then make sure we have good documentation on the process?

- Evan

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

Re: Getting new packages into Ubuntu

[Bryce Harrington]

On Mon, Sep 19, 2011 at 12:28:03PM +0200, Daniel Holbach wrote:
> Hello everybody,
> 
> with the help of the nice people on the Debian derivatives mailing list,
> we updated
> 
>   https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
> 
> Particularly the section about getting a package into Debian.
> 
> The feedback I've got lately about getting new packages into Ubuntu is
> that it's still quite complicated and you need unreal amounts of
> patience to get your package in.
> 
> There's a number of different approaches you can take currently:
> 
>  - get it into Debian, sync from there
>  - make use of the App Review Board process
>  - make use of REVU
>  - short-circuit by getting in touch with a team who sees an
>immediate need to get it in
>
> Is there anything we can do to speed up the process and make it more
> obvious how to proceed?
>
> Thanks for your thoughts in advance.

Isolate specifically what must be done by human reviewers, and make that
really fun and easy.  Then automate everything else.

Bryce


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