Re: Enabling Connectivity Checking in NetworkManager

[Chase Douglas]

On 07/11/2012 12:17 PM, Thomas Bechtold wrote:

On Wed, 2012-07-11 at 06:08 +0200, Martin Pitt wrote:

Mathieu Trudel-Lapierre [2012-07-10 14:41 -0400]:
It could stop polling until the connection state changes
then.


if you don't poll, you never know if the connection state changed.


My devious self is wondering if each computer can have an active TCP 
connection to a specific address, like connected.ubuntu.com, with TCP 
keepalives at a high interval (maybe 10 seconds). You don't have the 
overhead of constantly opening and closing connections, but you do have 
the overhead of actually keeping millions of connections open on the server.


This addresses none of the privacy concerns, of course, but it does give 
near immediate notification when the network has died, no matter how you 
get your connection.


-- Chase

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

Re: GCC 4.7, STL and binary compatibility of objects built with different language standards

[Chase Douglas]

On 06/12/2012 10:30 AM, Matthias Klose wrote:
> On 12.06.2012 19:18, Matthias Klose wrote:
>> On 12.06.2012 18:50, Chase Douglas wrote:
>>> My understanding is that this is only a problem if one library compiled
>>> with one standard passes objects to another library compiled with
>>> another standard. The following examples illustrate the difference:
>>>
>>> * Nux (c++11) and libsigc++ (c++98) are compiled with different
>>> standards. They pass std::lists between them. This is a problem.
>>>
>>> * utouch-grail (c++11) and utouch-qml (c++98) are compiled with
>>> different standards. However, the API between the two is pure C. This is
>>> not a problem.
>>>
>>> Please correct me if I am wrong.
>>
>> please read the referenced GCC report.
> 
> from http://gcc.gnu.org/PR53646 (but see the issue itself for the complete
> description):
> 
> """The testcase consists of two libraries (lib1 lib2), compiled with cxx11
> and cxx98 respectively.  Both libs don't depend or interact with each other.
> The app stands for a random application making use of random libraries,
> calling simple functions in them, which themself don't exhibit any ABI
> problem.  I.e. the testcase tries to show a typical situation for
> application developers using several different 3rd party libraries not under
> control of that developer.
> 
> The problem happens because both libs contains a (weak) definition of
> the equal_range function.  As the libs don't control their exports this
> symbol also is exported.  Hence the calls will be resolved to whatever
> version comes first in dynamic linker search order (that's the reason
> for the two apps built, once with "-l1 -l2", once with "-l2 -l1").
> 
> So, whichever library is first in search order, the other library will
> resolve its own equal_range call (stemming from the inlined erase) to that
> first library, and thereby crash because that version was compiled with
> different c++ ABI."""

If I understand the comment correctly, this can be distilled to:

App calls func(), which is defined by both lib1 and lib2. lib1 and lib2
have different ABIs. App crashes when linked in the wrong order because
the called func() may have a different ABI than the app expects.

If I'm right, there's nothing here that is new due to the use of
different C++ standards. It's a simple ABI mismatch. Am I missing something?

-- Chase

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

Re: GCC 4.7, STL and binary compatibility of objects built with different language standards

[Chase Douglas]

On 06/12/2012 09:22 AM, Matthias Klose wrote:
> On 08.06.2012 17:10, Chris Coulson wrote:
>> I've just finished debugging a Unity crash which occurs when we try a
>> test rebuild of Unity and Nux with GCC4.7 in quantal. Although the
>> original issue was caused by mixing 2 C++ ABI's (because libsigc hasn't
>> been rebuilt yet in quantal), it was no better even after rebuilding
>> libsigc with the quantal toolchain.
> 
> correct, afaics there is no ABI incompatibility between 4.6 and 4.7, but 
> between
> c++98 and c++0x/c++11.
> 
> c++98 and c++0x/c++11 code should not be mixed in one binary, and best avoided
> in a distribution.

My understanding is that this is only a problem if one library compiled
with one standard passes objects to another library compiled with
another standard. The following examples illustrate the difference:

* Nux (c++11) and libsigc++ (c++98) are compiled with different
standards. They pass std::lists between them. This is a problem.

* utouch-grail (c++11) and utouch-qml (c++98) are compiled with
different standards. However, the API between the two is pure C. This is
not a problem.

Please correct me if I am wrong.

In the uTouch team, we've been using c++11 features for core
functionality of our code. Most of utouch-frame and utouch-grail would
have to be rewritten if we needed to strip out c++11 support.
Thankfully, we aren't using nor exposing a C++ API other than the stl :).

-- Chase

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

Re: GCC 4.7, STL and binary compatibility of objects built with different language standards

[Chase Douglas]

On 06/08/2012 08:10 AM, Chris Coulson wrote:
> Hi,
> 
> I've just finished debugging a Unity crash which occurs when we try a
> test rebuild of Unity and Nux with GCC4.7 in quantal. Although the
> original issue was caused by mixing 2 C++ ABI's (because libsigc hasn't
> been rebuilt yet in quantal), it was no better even after rebuilding
> libsigc with the quantal toolchain.
> 
> What is happening is, in GCC4.7, std::_List_base::_List_impl has a data
> member which only exists for compilation units that are built with
> -std=c++0x (_M_size). This means that the STL ABI is dependent on the
> language standard. This obviously causes issues when a process loads
> libraries that are built with different language standards and which
> pass std::list's across public API's
> 
> In the Unity case, both Unity and Nux are built with -std=c++0x, but
> they use libsigc which is not built with it and which exposes STL
> objects in its public API. Rebuilding libsigc locally with -std=c++0x is
> sufficient to make Unity work properly. However, uploading this will
> probably break anything else in the archive using libsigc which isn't
> built with -std=c++0x, so I'm not sure of the best way to proceed.
> 
> In addition to welcoming other people's opinions, I also want to make
> sure that other people are careful here don't fall in to the same trap :)

I would have assumed that language standard choices should be
intermixable across libraries. Is it possible this is merely a bug in GCC?

-- Chase

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

Creating isos from PPAs

[Chase Douglas]

Hi all,

I would like to have a developer tool that allows for someone to spin an
ubuntu iso with a set of ppas enabled. Then someone else, say someone
from the design team, could run the iso under test drive or even on
metal to see the changes. I imagine this is possible, but I don't know
where to look. Any pointers would be appreciated.

Thanks!

-- Chase

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

Re: 12.04 LTS: 64-bit desktop by default?

[Chase Douglas]

On 04/15/2012 11:03 PM, Steve Langasek wrote:
> Hi folks,
> 
> Back at last UDS in November, we discussed whether it was time to switch to
> presenting 64-bit images as the default image for desktop, like they already
> are for server, now that all new desktop hardware is 64-bit and multiarch is
> a reality.
> 
> There was a rough consensus at UDS that the blockers were solved, but that
> the question should be taken to ubuntu-devel to gather more input.  That
> input-gathering is happening much later than intended, but here we are now.
> 
> The blueprint at
> 
> includes links to some data gathered by the inimitable Colin King, showing
> that in terms of performance, there are both pros and cons for switching to
> amd64: memory consumption goes up, and therefore power consumption goes up
> if the system is making more use of swap, but on the other side, most
> CPU-bound operations will be faster on amd64.  So there is no clear
> performance argument for preferring one over the other.

Many netbooks only support up to 2G of memory, let alone the fact that
they often ship with 1G. I currently have a netbook with 2G, and I am
well over 1G of memory used with only one tab open in chromium and no
other apps open. When I start to swap it can get near painfully slow.
Moving to amd64 would only exacerbate the issue, forcing more swapping
on an already slow machine.

I'm not sure that we should hold up progress for netbooks, but it is an
issue we need to be aware of.

-- Chase

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

Re: ClickPads and Click Actions

[Chase Douglas]

On 03/02/2012 10:14 AM, Bryce Harrington wrote:

On Wed, Feb 29, 2012 at 08:55:58PM -0800, Chase Douglas wrote:

I'm beginning to think that this is all so complicated even when we
try to be verbose and convey things as accurately as possible that
nothing short of "it just works perfectly and exactly how I wanted"
will be good enough. Although I think we are very close to this
being possible, we're just too far past feature freeze for it to
land.

After the freeze is lifted, I'll upload a new X synaptics module
with ClickPad support but disabled by default for all devices. We
can document the feature on wiki.ubuntu.com and tell people how to
enable it. Next cycle I'll finish it by ensuring click actions are
supported too. Then we can turn it on without hesitation :).


Alright, sounds like a good plan.  Then LTS users will get it on
12.04.2 or via an SRU if that makes sense.


I'm about to upload. The only change is that I'm leaving clickpad 
support enabled for clickpads with a separate physical right button. 
These devices do not have click actions enabled by default anyways, so 
there's no regression in behavior.


I'm only aware of two machines with such clickpads: Dell Mini 1011 and 
1012 netbooks.


-- Chase

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

Re: ClickPads and Click Actions

[Chase Douglas]

On 02/29/2012 05:22 PM, Bryce Harrington wrote:

On Wed, Feb 29, 2012 at 01:11:30PM -0800, Chase Douglas wrote:

Hi all,

I'm sending this to both ubuntu-devel and ubuntu-desktop to try to
get a larger pool of feedback.


Here's some random thoughts.  I don't have a fully formed opinion on the
topic, but maybe these general observations can help the discussion.


* There are several different loose categories of devices we're talking
   about:

   + Integrated Apple pads in laptops

   + Apple magic touch mice, plugged in via USB(?)


No mice. This only applies to trackpads.


   + Integrated pads in netbooks (like Dell Mini V)

   + Others?


These are actually becoming more usual for all laptops. I think most 
Synaptics brand trackpads are now ClickPads.




* People have widely divergent views on how their pads should behave.

   + Changes to input behavior that can be perceived as a regression by
 any group of users tend to spawn bug reports and/or complaints.

   + We can't please everyone.

   + We want to minimize the number of people who have to configure
 things, that didn't have to configure things previously.


* Historically, we've not been prolific with X input SRUs.

+ Partly because many input "bugs" are just differences of opinion
  about what options should be the default.

+ Partly because input bugs often involve patches that are complex or
  invasive.

+ Partly because testing the changes requires a variety of input
  hardware that many of us don't have on hand.  (Testing can also be
  rather subjective.)

+ Partly because video issues keep us fully occupied and we just
  don't get to input stuff that often.


* There is a sense that people transitioning from Apple will have
   different expectations than existing users (or windows migrants).

+ Do we have a sense for how many Apple migrants there are?
  (I know they can be vocal, but are we expecting Apple
  converts to Precise?)

+ While the hardware is quite pervasively common, Apple is not an OEM
  customer for Canonical (well, AFAIK), so that may modulate the
  priority here.

+ The defaults here for Apple hardware Could be different than
  other pads.


* Many users won't know about gestures or how to use them.

+ Some have strong muscle memory in their fingers.

+ Some users just aren't that coordinated.

+ Some just hate change in general.


* My general rule of thumb for features in LTS:

+ When unsure of a new feature, include it but leave it turned off by
  default.

+ Provide directions for enabling it in a wiki.  That way we can
  still get testing feedback and users who *really* want it will have
  a way to enable it.  (And 3rd parties can add it to Tweak tools and
  so on.)

+ If it can't be defaulted to off, then put it in a separate package
  or PPA, that people who want it can opt-in to.


This can be defaulted off, so having a wiki page with documentation on 
how to enable it is possible.



The options are:
  >  * Disable clickpad support by default
  "Traditional + ClickActions"

  >  * Enable clickpad support, but disable right button area by default
  "ClickPad"

  >  * Enable clickpad support and right button area by default
  "ClickPad + RightArea"


It's hard to construct a solid opinion on the options... so many
factors.

If we definitely want to attract Apple converts to Precise (or make it
easier for people who swap between OSX and Ubuntu), then it follows we'd
at least want to make ClickPad enabled by default for Apple hardware.
Do we have strategic guidance from Design or management on what we
should be prioritizing here?


I doubt it. AFAIK, I'm the only person in the world really working on it :).


However, what I've heard from many Apple laptop owners is that there's
so many little quirks and misbehaviors, that ClickPad-vs-Traditional
might be just one in a long list of support issues.  If we fix that, but
as a result break something else, we may not really be gaining that much
in total.  But I don't know.


That may be. Anecdotally, Seth Forshee from the kernel team said missing 
clickpad support was the only remaining niggle for him on the latest 
Macbook Airs. Things maybe better than previously :).



Leaving Apple hardware aside, for non-Apple hardware where we don't have
expectations for ClickPad functionality, it seems like it would be safest
to leave that as Traditional + ClickActions.  This assumes we can ship
one option for Apple stuff, one for everything else.  If we can't, then
that seems to suggest we should stick with Traditional by default, and
wiki up directions for Apple users.


AFAIK, all clickpads that are not Apple (i.e. are Synaptics brand) have 
right button area markings. I think it makes the most sense for the

Re: ClickPads and Click Actions

[Chase Douglas]

On 02/29/2012 03:32 PM, Scott Kitterman wrote:

On Wednesday, February 29, 2012 01:11:30 PM Chase Douglas wrote:

Hi all,

I'm sending this to both ubuntu-devel and ubuntu-desktop to try to get a
larger pool of feedback.

I recently added "ClickPad" support in Precise. This is automatically
picked up by most Synaptics and all Apple Macbook trackpads. It will
soon be picked up by more Synaptics trackpads and the Apple Magic
Trackpad. ClickPad support entails the ability to press the trackpad
with one finger and perform a drag by moving a second finger.

The problem we face is that currently "ClickPad" support conflicts with
"click actions". Click actions is the term for supporting right button
behavior by clicking on the trackpad with two fingers. This has been
supported for years, and has helped people perform right clicks on
clickpad devices before the clickpad support landed in Precise.
Unfortunately, we can't have clickpad support and click action support
at the same time yet (ran out of time for Precise).

One feature that hasn't been turned on by default yet is a right button
area. On Synaptics trackpads, the lower right area of the trackpad is
marked as a right button. If you enable the right button area and then
press with one finger in the area, a right button click will be emitted.

We can enable the right button area by default for all clickpads. The
problem is that Apple trackpads do not have a marking for a right button
area, and OS X doesn't provide such a feature. People coming from OS X
will have to figure out that we a) don't have click action support, and
b) if you click in the lower right area you will perform a right button
click. However, people coming from OS X also expect to be able to click
and drag with two fingers...

Our options are:

* Disable clickpad support by default
* Enable clickpad support, but disable right button area by default
* Enable clickpad support and right button area by default

We can have a different default for Apple trackpads and everything else.

The next Precise kernel will enable clickpad support for all known
trackpads by default, but right button area remains disabled. Until
then, you can manually enable support by finding your trackpad device id
using 'xinput', then running the following scripts:

http://people.canonical.com/~cndougla/enable-clickpad.sh
http://people.canonical.com/~cndougla/enable-rightbutton.sh

If you have tried all the options and have an opinion on which option we
should take, please send your thoughts.


What happens with the right button area on systems that have physical buttons?


There are no changes for devices that have separate physical buttons.


Generically, it seems to me that the time for changing long standing defaults
is LTS+1, not LTS.


When the default behavior is so bad that people use external mice rather 
than deal with the trackpad, it's worth it to try to fix things. I see 
clickpad support as a bug fix. The question is at what point does fixing 
the bug take precedence over potential default behavior changes.


I will note you as a vote for "Disable clickpad support by default", 
since that aligns closest with your thoughts here. Let me know if that's 
not accurate.


-- Chase

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

Re: ClickPads and Click Actions

[Chase Douglas]

On 02/29/2012 04:07 PM, Nicholas Skaggs wrote:

Chase, I already had 2 finger tapping for right click in oneiric... This
would be a regression, unless I'm mistaken. The multitouch click and
drag is huge on the these devices, so I would have to say that's the
more important one. Are you saying you can do that along with allowing
right click by pressing the right side of the pad? If I didn't want to
split my clickpad, how else could I right click under your scenario?


First, I need to clear one issue up: tapping vs pressing. On a clickpad, 
the user can tap by momentarily touching the touch surface without 
depressing the touchpad itself. A press is performed when the user 
physically presses on the touchpad so that it moves downward and causes 
a physical button press to be emitted.


Under all options, two touch tap to emit a right click will work as it 
always has. Note that tap to click is not enabled by default.


The issue lies with two touch press to perform a right button press. In 
clickpad mode, this will not be possible and is a regression. The 
options for getting right click behavior are: a) enable the right button 
area or b) enable tap to click and perform a two-touch tap. There are 
many people who hate tap to click, so relying on b would be bad.


If we make the assumption that right click must be possible, then we 
either need to enable the right button area whenever clickpad 
functionality is enabled, or we need to disable clickpad functionality.


The button area I would propose would be the lower right of the 
trackpad, from half way across in the horizontal direction, and 18% of 
the height of the trackpad.


It sounds like you are suggesting that multitouch press and drag is 
important enough to impose this regression, so does that mean you are ok 
with enabling the right button area by default?


Thanks,

-- Chase

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

Re: ClickPads and Click Actions

[Chase Douglas]

On 02/29/2012 02:11 PM, Nicholas Skaggs wrote:

Chase, I would try and make the use case of clicking and dragging along
with 2 finger clicking work. The other scenario could possibly be worked
out via a ppa or script for users who wish to change or otherwise enable
the split clickpad. I personally don't like the split clickpad idea and
I think making things standard for all users would be best. Aka,

1 finger tap/click = left click
2 finger tap/click = right click
multitouch click and drag = just works :-)


Well, the point of this thread is that we can't do all three :). We're 
past the feature freeze, and I don't have the time to hack up a solution 
that enables them all at the same time :(.


Do you have a preference between having multitouch click and drag vs 2 
finger click for right click?



It's late and I'm failing to remember.. is tap to click configurable for
this? IE, I can tap the clickpad for a click, or I have to depress the
clickpad to register a click.


Tap to click is still possible, and a two touch tap will still trigger a 
right click. However, tap to click is not enabled by default. Check in 
the mouse and trackpad settings for the option.


Thanks,

-- Chase

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

ClickPads and Click Actions

[Chase Douglas]

Hi all,

I'm sending this to both ubuntu-devel and ubuntu-desktop to try to get a 
larger pool of feedback.


I recently added "ClickPad" support in Precise. This is automatically 
picked up by most Synaptics and all Apple Macbook trackpads. It will 
soon be picked up by more Synaptics trackpads and the Apple Magic 
Trackpad. ClickPad support entails the ability to press the trackpad 
with one finger and perform a drag by moving a second finger.


The problem we face is that currently "ClickPad" support conflicts with 
"click actions". Click actions is the term for supporting right button 
behavior by clicking on the trackpad with two fingers. This has been 
supported for years, and has helped people perform right clicks on 
clickpad devices before the clickpad support landed in Precise. 
Unfortunately, we can't have clickpad support and click action support 
at the same time yet (ran out of time for Precise).


One feature that hasn't been turned on by default yet is a right button 
area. On Synaptics trackpads, the lower right area of the trackpad is 
marked as a right button. If you enable the right button area and then 
press with one finger in the area, a right button click will be emitted.


We can enable the right button area by default for all clickpads. The 
problem is that Apple trackpads do not have a marking for a right button 
area, and OS X doesn't provide such a feature. People coming from OS X 
will have to figure out that we a) don't have click action support, and 
b) if you click in the lower right area you will perform a right button 
click. However, people coming from OS X also expect to be able to click 
and drag with two fingers...


Our options are:

* Disable clickpad support by default
* Enable clickpad support, but disable right button area by default
* Enable clickpad support and right button area by default

We can have a different default for Apple trackpads and everything else.

The next Precise kernel will enable clickpad support for all known 
trackpads by default, but right button area remains disabled. Until 
then, you can manually enable support by finding your trackpad device id 
using 'xinput', then running the following scripts:


http://people.canonical.com/~cndougla/enable-clickpad.sh
http://people.canonical.com/~cndougla/enable-rightbutton.sh

If you have tried all the options and have an opinion on which option we 
should take, please send your thoughts.


Thanks!

-- Chase

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

Re: Smoke testing of Precise X server bits

[Chase Douglas]

On 01/20/2012 09:21 PM, Rohan Garg wrote:
> There seems to be a bit of a issue with rotating plasmoids on my KDE
> desktop using two fingers ( MacBookPro8,2 ). Earlier I could rotate my
> plasmoids using 2 fingers. That functionality seems to be lost with
> the latest updates ( I'm guessing I need a updated utouch-geis to get
> this to work? )  . Scrolling works as expected.

The utouch stack is broken right now until we get a new utouch-geis
uploaded. Hopefully that will occur late this week or early next.

-- Chase

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

Re: Smoke testing of Precise X server bits

[Chase Douglas]

On 01/20/2012 02:52 PM, Tim Gardner wrote:
> Will any of these updates address cut and paste on a Mac touchpad ? It 
> appears to be impossible to select text without using an external mouse.

Not yet. We are still working on that feature and hope to land it before
feature freeze.

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

Re: Smoke testing of Precise X server bits

[Chase Douglas]

On 01/20/2012 03:01 AM, Chase Douglas wrote:
> Hi all,
> 
> We have everything ready (almost) for the upload of the X server into
> Precise. It includes X server 1.11 plus the input stack from 1.12. It
> also includes a bunch of interdependent packages that would break if you
> were only to update your X server. Here's the known issues with the PPA:
> 
> * No utouch-geis support, which means most of your gestures won't work
>   - Will be fixed by feature freeze
> * Multitouch in Qt from indirect devices (e.g. trackpads) is broken
>   - Will be fixed in next Qt upload *after* we push these packages
> * Qt is still building for armel, so don't test this on armel yet
> * A security hole will kill your screen saver if you type
>   Ctrl+Alt+KP_Multiply
>   - Will be fixed in xkeyboard-config upload in the next couple hours
> 
> Notably, xserver-xorg-input-synaptics has a large patch added in today
> for multitouch support. The X synaptics module is used for all
> trackpads. Please test that your trackpad is behaving sanely.
> 
> We are mostly looking for blocker bugs right now (random X server
> crashes, really obnoxious behavior, etc.). Please reply with any such
> bugs you find.

Oops, I forgot to mention the packages are in ppa:canonical-x/x-staging.
The following should get you set up for testing:

$ sudo add-apt-repository ppa:canonical-x/x-staging
$ sudo apt-get update
$ sudo apt-get upgrade

I don't think you need to dist-upgrade for this as there shouldn't be
any new packages or packages needing to be removed, but I'm not entirely
certain.

-- Chase

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

Smoke testing of Precise X server bits

[Chase Douglas]

Hi all,

We have everything ready (almost) for the upload of the X server into
Precise. It includes X server 1.11 plus the input stack from 1.12. It
also includes a bunch of interdependent packages that would break if you
were only to update your X server. Here's the known issues with the PPA:

* No utouch-geis support, which means most of your gestures won't work
  - Will be fixed by feature freeze
* Multitouch in Qt from indirect devices (e.g. trackpads) is broken
  - Will be fixed in next Qt upload *after* we push these packages
* Qt is still building for armel, so don't test this on armel yet
* A security hole will kill your screen saver if you type
  Ctrl+Alt+KP_Multiply
  - Will be fixed in xkeyboard-config upload in the next couple hours

Notably, xserver-xorg-input-synaptics has a large patch added in today
for multitouch support. The X synaptics module is used for all
trackpads. Please test that your trackpad is behaving sanely.

We are mostly looking for blocker bugs right now (random X server
crashes, really obnoxious behavior, etc.). Please reply with any such
bugs you find.

Thanks!

-- Chase

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

Re: Plans for Precise X upload

[Chase Douglas]

On 01/17/2012 06:48 PM, Scott Kitterman wrote:
> On Saturday, January 14, 2012 05:17:37 AM Chase Douglas wrote:
>> On Jan 13, 2012, at 10:21 PM, Jonathan Riddell  wrote:
>>> On 13 January 2012 16:03, Chase Douglas  
> wrote:
>>>> How does this sound? If it works for everyone, the only remaining
>>>> question is which qt4-x11 version to upload.
>>>
>>> Qt 4 4.8 is about to be uploaded, got a new patch for it?
>>
>> Yes, though I get build errors at dpkg-makeshlibs (or something like that).
>> It isn't related to the XI work though. I needed to add a few exceptions to
>> the the call to make it complete. I'll be back to work on Tuesday, but I
>> might be able to propose the patch before then.
> 
> FYI, it's Qt4 4.8 that's in precise now, so that's the version you'll need to 
> be ready to copy.

Yep, I'm pushing a branch up to propose right now :).

-- Chase

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

Re: Plans for Precise X upload

[Chase Douglas]

On 01/17/2012 06:02 PM, Oliver Grawert wrote:
> hi,
> On Tue, 17 Jan 2012 17:44:27 +0100
> Chase Douglas  wrote:
>>> could you also make sure to make your PPA build for armhf (which is
>>> likely to be the supported arm subarch for precice (to be decided at
>>> feature freeze) ?
>>
>> I don't know how to do that. I'll ask, but I would guess the answer is
>> no at this point due to the newness of armhf in Ubuntu.
>>
> it is the matter of filing one RT ticket and waiting a few days for IS
> and a LOSA to enable the arch for the respective PPA, if it already
> builds armel it is a no-brainer to also enable armhf ...

It should build for armhf now :).

> the important part for us is that if you start the transition now, can
> you guarantee that all packages are in order for the alpha2 milestone on
> armhf without having them built in the PPA ? 
> our image builds indeed depend on the package dependencies
> being correct in the archive and we don't want to risk missing alpha2
> due to this transition.
> armhf is our poposed default arch for precise and there are high chances
> that arm might even be an LTS this time round so we urgently need the
> testing of the last milestone before feature freeze where we plan to
> make the final decision about the default arm arch.

Hopefully we have all the arches covered (amd64, i386, powerpc, armel,
armhf). We would only pocket copy if we are not in a milestone freeze.
Pocket copying should take a small amount of time, less than an hour I
believe.

For Alpha 2, we have a soft freeze on Monday, January 30th. Our hope is
to have everything uploaded to the PPA in the next day or so. Build
times would then be added on top (but at least buildds work on weekends
and through the night without complaining :). My guess is that if we
don't have any issues we would be doing the pocket copy around the
beginning of next week. That's one week before the Alpha 2 soft freeze.

Sound good?

-- Chase

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

Re: Plans for Precise X upload

[Chase Douglas]

On 01/16/2012 11:18 AM, Oliver Grawert wrote:
> hi,
> 
> On Fri, 13 Jan 2012 17:03:24 +0100
> Chase Douglas  wrote:
> 
>> * Pocket copy source and binary packages from the PPA into Precise
>>   - This PPA has been blessed and builds amd64, i386, armel, and
>> powerpc. Due to security issues with armel PPAs, Canonical will
>> only allow us to bless a PPA that is restricted to Canonical
>> employees. Hopefully, the security issues will be resolved soon, but
>> not in the next week :).
> could you also make sure to make your PPA build for armhf (which is
> likely to be the supported arm subarch for precice (to be decided at
> feature freeze) ?

I don't know how to do that. I'll ask, but I would guess the answer is
no at this point due to the newness of armhf in Ubuntu.

Pushing the source packages and having armhf build them in the archive
isn't a problem, it just means that for a few days you might find that
some packages are "held" back until all the packages that satisfy
"breaks" and "depends" clauses are available. Using the PPA merely
shortens the window of time in which people find packages held back.

-- Chase

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

Re: Plans for Precise X upload

[Chase Douglas]

On Jan 13, 2012, at 10:21 PM, Jonathan Riddell  wrote:

> On 13 January 2012 16:03, Chase Douglas  wrote:
>> How does this sound? If it works for everyone, the only remaining
>> question is which qt4-x11 version to upload.
> 
> Qt 4 4.8 is about to be uploaded, got a new patch for it?

Yes, though I get build errors at dpkg-makeshlibs (or something like that). It 
isn't related to the XI work though. I needed to add a few exceptions to the 
the call to make it complete. I'll be back to work on Tuesday, but I might be 
able to propose the patch before then.

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

Plans for Precise X upload

[Chase Douglas]

Hi all,

We're now all ready to push the new X server to Precise. This will cause
breakages for many items, so we need to plan this carefully. Chris
Halse-Rogers and I have devised the following plan:

* Push all new packages (Xorg and packages that need changes) to
ppa:canonical-x/x-staging, including:
  - utouch-geis 2.2.3 rebuild for XI API changes
  - qt4-x11 either current package with refreshed XI patch for API
changes, or 4.8 branch if it's ready. I have patches ready for both.
  - utouch-frame 2.1 for XI API changes
  - utouch-grail rebuild for XI API changes

* Use the following Breaks: for xorg-server:
  - unity < 5.0.0 (due to crasher if utouch stack is unavailable)
  - utouch-geis < 2.2.3 (due to infinite loop if utouch XCB backend is
 unavailable)
  - utouch-frame < 2.1.0 (due to XI API change)
  - qt4-x11 < [qt4-x11 ubuntu version to be uploaded] (due to XI API
   change)

* Pocket copy source and binary packages from the PPA into Precise
  - This PPA has been blessed and builds amd64, i386, armel, and
powerpc. Due to security issues with armel PPAs, Canonical will only
allow us to bless a PPA that is restricted to Canonical employees.
Hopefully, the security issues will be resolved soon, but not in the
next week :).

How does this sound? If it works for everyone, the only remaining
question is which qt4-x11 version to upload.

Thanks!

-- Chase

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

Re: [ubuntu-x] Heisenbug in xserver-xorg-input-synaptics

[Chase Douglas]

On 01/07/2012 09:09 AM, Tormod Volden wrote:
> On Sat, Jan 7, 2012 at 5:48 PM, Chase Douglas
>  wrote:
>> On 01/06/2012 06:05 PM, Chase Douglas wrote:
>>> Hi all,
>>>
>>> I tried to track down the bug in the X staging ppa
>>> (ppa:ubuntu-x-swat/x-staging) that causes trackpads to flip to the edge
>>> of the screen. This is what I found:
>>>
>>> In the X server when there's a relative motion event it computes an
>>> acceleration for it. You can follow the events from QueuePointerEvents()
>>> to BasicComputeAcceleration(). BasicComputeAcceleration() then calls a
>>> function pointer, which by default for the X synaptics driver calls back
>>> into the driver's SynapticsAccelerationProfile() function.
>>>
>>> If you set a breakpoint in BasicComputeAcceleration() with the condition
>>> of "result > 1", you'll get a hit. When you continue, your pointer
>>> will flip to an edge of the screen. Generally, the value of the result
>>> variable is on the order of +e+304 or inf when this occurs.
>>> The next step is to try setting a breakpoint in
>>> SynapticsAccelerationProfile() with the condition "accelfct > 1" on
>>> the return statement.
>>>
>>> I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
>>> trigger the bug. Then, I compiled with the default optimizations, and
>>> the bug reappeared, but the breakpoint with the condition was never hit.
>>> I tried removing the condition, and the breakpoint worked as expected.
>>>
>>> I've sent this to both ubuntu-x and ubuntu-devel to ask if anyone has
>>> any ideas on how to debug this without getting to the level of
>>> compiler/assembly/linker debugging :).
>>
>> Nevermind, I should have looked closer at the build log. The signature
>> of the acceleration callback changed to returning a double instead of a
>> float. This emitted a warning that I failed to see.
>>
> 
> Just figured this out before seeing your mail :) You will need (at least)
> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=7c0361d4ec6b1f1325cb6551d0ee2e7f5cfae15b

I fixed it by merging from debian-experimental, which has all the latest
goodies from upstream git master.

> Not only the return value changed type, also the input parameters. You
> would see this in the debugger that e.g. acc was not the same inside
> BasicComputeAcceleration() as inside SynapticsAccelerationProfile().

Yeah, I really just needed another 15 mins of work on this bug, but it
was the end of the day yesterday so I just threw up my hands in
annoyance :). Thanks for looking into it for me!

-- Chase

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

Re: [ubuntu-x] Heisenbug in xserver-xorg-input-synaptics

[Chase Douglas]

On 01/06/2012 06:05 PM, Chase Douglas wrote:
> Hi all,
> 
> I tried to track down the bug in the X staging ppa
> (ppa:ubuntu-x-swat/x-staging) that causes trackpads to flip to the edge
> of the screen. This is what I found:
> 
> In the X server when there's a relative motion event it computes an
> acceleration for it. You can follow the events from QueuePointerEvents()
> to BasicComputeAcceleration(). BasicComputeAcceleration() then calls a
> function pointer, which by default for the X synaptics driver calls back
> into the driver's SynapticsAccelerationProfile() function.
> 
> If you set a breakpoint in BasicComputeAcceleration() with the condition
> of "result > 1", you'll get a hit. When you continue, your pointer
> will flip to an edge of the screen. Generally, the value of the result
> variable is on the order of +e+304 or inf when this occurs.
> The next step is to try setting a breakpoint in
> SynapticsAccelerationProfile() with the condition "accelfct > 1" on
> the return statement.
> 
> I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
> trigger the bug. Then, I compiled with the default optimizations, and
> the bug reappeared, but the breakpoint with the condition was never hit.
> I tried removing the condition, and the breakpoint worked as expected.
> 
> I've sent this to both ubuntu-x and ubuntu-devel to ask if anyone has
> any ideas on how to debug this without getting to the level of
> compiler/assembly/linker debugging :).

Nevermind, I should have looked closer at the build log. The signature
of the acceleration callback changed to returning a double instead of a
float. This emitted a warning that I failed to see.

-- Chase

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

Heisenbug in xserver-xorg-input-synaptics

[Chase Douglas]

Hi all,

I tried to track down the bug in the X staging ppa
(ppa:ubuntu-x-swat/x-staging) that causes trackpads to flip to the edge
of the screen. This is what I found:

In the X server when there's a relative motion event it computes an
acceleration for it. You can follow the events from QueuePointerEvents()
to BasicComputeAcceleration(). BasicComputeAcceleration() then calls a
function pointer, which by default for the X synaptics driver calls back
into the driver's SynapticsAccelerationProfile() function.

If you set a breakpoint in BasicComputeAcceleration() with the condition
of "result > 1", you'll get a hit. When you continue, your pointer
will flip to an edge of the screen. Generally, the value of the result
variable is on the order of +e+304 or inf when this occurs.
The next step is to try setting a breakpoint in
SynapticsAccelerationProfile() with the condition "accelfct > 1" on
the return statement.

I compiled xserver-xorg-input-synaptics with noopt, but I wasn't able to
trigger the bug. Then, I compiled with the default optimizations, and
the bug reappeared, but the breakpoint with the condition was never hit.
I tried removing the condition, and the breakpoint worked as expected.

I've sent this to both ubuntu-x and ubuntu-devel to ask if anyone has
any ideas on how to debug this without getting to the level of
compiler/assembly/linker debugging :).

Thanks!

-- Chase

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

Precise X staging

[Chase Douglas]

Hi all,

At UDS we decided to use the X.org 1.11 server with the input subsystem
backported from 1.12 for multitouch. The upstream 1.12 server
development branch just landed the multitouch support, so I packaged it
up for Precise.

Ubuntu has had multitouch support in our X server since 11.04, but it
was a prototype implementation. The protocol specification and
implementation merged upstream is very similar, but includes a few key
modifications.

Over the past week, Chris Halse-Rogers and I have created a staging PPA
(ppa:ubuntu-x-swat/x-testing) for all the X packages and any packages
that need fixes due to the input protocol changes. This PPA is as much
for our own development benefit as it as a chance for others to test it
out. We would gladly appreciate feedback on ubunt...@lists.ubuntu.com.
However, note that the code is still rather unstable.

We need to determine what to do about the qt4-x11 package in particular.
The Ubuntu package includes a patch that enables multitouch using the
prototype implementation. I have reworked the patch for the upstream
implementation (it was far easier than I thought it would be :), and it
is available in the ppa as well. For the transition, we could do one of
the following:

1. Drop the patch from qt4-x11 now, and add it back in after the X
packages land in precise.

2. Synchronize the X package and Qt package uploads and use "Breaks"
debian control clauses to hold back packages during the transition period.

I proposed option #1 to Scott on irc this past week. I think it's the
least hassle because it does not require significant synchronization
between the kubuntu packagers and the ubuntu-x teams. There are no
API/ABI changes from the patch, it merely hooks up the plumbing in the
qt x11 implementation. I am also unaware of any applications in the
archive using the qt multitouch capability yet. However, I have no
issues with either approach. Any thoughts?

Thanks!

-- Chase

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

Patch Pilot Report 2011-08-22

[Chase Douglas]

* lp:~sergio91pt/ubuntu/oneiric/gvfs/bug-388904
  - Bug #388904: Nautilus 'Computer' displays redundant labels
  - Patch looks ok
  - Needs to be forward ported from Natty to Oneiric
  - Needs to be converted to a packaging quilt patch
  - Was blocked on lp:ubuntu/gvfs getting updated to latest upload
  - Max Bowsher on #launchpad helped fix branch import

* lp:~mathieu-tl/ubuntu/oneiric/usb-modeswitch/lp824147
  - Bug #824147: usb_modeswitch_[2193]: segfault at 8 ip
7eff40eab681 sp 7fff6a785f58 error 4 in
libc-2.13.so[7eff40e29000+195000]
  - Patch looks ok, though it includes unrelated changes
  - Question on why call /bin/tar instead of just tar

* lp:~jtaylor/ubuntu/natty/meld/meld-sru
  - Bug #770549: meld /path/to/folder doesn't work
  - Bug #774265: [natty] meld hangs comparing attached files
  - Bug #786134: Meld chokes on file comparison
  - Bug #787831: Meld crashes if svn working dir contains svn externals dirs
  - Fixes four bugs for Natty as an SRU
  - Overall it looks good
  - One minor gotcha that can be fixed by an uploader if needed
  - Bug reports needed regression potential discussion
  - Submitter added regression potential information
  - I approved merge proposal

*
lp:~paulbrianstewart/ubuntu/oneiric/alarm-clock-applet/830806-Punctuation-Correction
  - Bug #830806: Missing Period at end of sentence in the control file
description
  - Fixes a grammar issue in debian/control
  - Patch has already been incorporated by debian maintainer
  - I disapproved merge proposal

* lp:~jtaylor/ubuntu/oneiric/mooproxy/fix-770784
  - Bug #770784: mooproxy version 0.1.3-1 failed to build on amd64 with
GCC-4.6/oneiric
  - Fix for handling linker flags appropriately
  - Patch looks good, but needs to be redone as a quilt patch
  - Packaging needs to have quilt integration
  - Asked submitter to try to get it into Debian first if easy
  - Debian maintainer has not been responsive
  - Submitter updated package to quilt (3.0) format
  - I approved merge proposal
  - Should go upstream, but not sure how to contact upstream

* lp:~phw/sound-juicer/sound-juicer-lucid-libmb3
  - Bug #455461: Sound Juicer depends on deprecated libmusicbrainz4
  - Rebuild against libmusicbrainz3 instead of libmusicbrainz4
  - Yes, that seems to be the correct thing to do according to upstream
  - Some extra build deps added, asked submitter if they were necessary
  - Copied SRU info from a bug comment to the bug summary

* lp:~jtaylor/ubuntu/oneiric/buzztard/fix-803173
  - Bug #803173: buzztard version 0.5.0-4 failed to build on i386
  - Fix FTBFS due to linker flags
  - debdiff posted to Debian bug
  - Changes look good
  - Debian maintainer has been unresponsive, we should upload
  - I approved in case that doesn't happen

* lp:~dannf/ubuntu/natty/multipath-tools/lp829061
  - Bug #829061: [SRU] double free of mpp->dmi in free_multipath()
  - SRU merge proposal
  - Changes look good, cherry-picked patch from upstream
  - Bug report needs SRU candidate treatment
  - I approved merge proposal content

* lp:~florian-bandes/ubuntu/oneiric/monster-masher/fix-for-766042
  - Bug #766042: monster-masher version 1.8.1-2 failed to build on amd64
  - Proposes a change to configure.ac and then ran autoreconf directly
  - Asked submitter to use dh_autoreconf instead

*
lp:~paulbrianstewart/ubuntu/oneiric/balazarbrothers/829819-Spelling-Error-Fix
  - Bug #829819: Spelling Errors in Control file
  - Sebastien Bacher asked that the fix be sent to Debian
  - Submitter encountered error trying to do so
  - Asked submitter to push latest code to a branch for someone to help
diagnose

* lp:~utlemming/ubuntu/oneiric/ipxe/oneiric
  - Bug #814038 (maybe?): Please offer a grub-ipxe.deb package
  - I'm confused about the bug and the branch
  - The bug is already marked as Fix Committed
  - The branch looks like it is being reused
  - Asked submitter for clarification on what is going on

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/04/2011 08:52 AM, Mackenzie Morgan wrote:
> On Thu, Aug 4, 2011 at 11:46 AM, Chase Douglas
>  wrote:
>> Realistically, you also can't expect that if you are on a publicly
>> elected board that evaluates individuals that there will not be
>> disagreements. It is a very personal process. It may not be apparent,
>> but it can cause a high level of anxiety for the individual applying.
>> This can increase or decrease the volume of the rhetoric. The board
>> needs to be able to handle individuals who disagree in a graceful
>> manner. Harboring assumptions of ill will and intent is not healthy for
>> either the applicants or the board.
> 
> What are we supposed to think is up if when a Canonical employee is
> rejected their manager has a hissy fit in the meeting, possibly with
> some rage-tweeting, and then within 12-24 hours someone else in
> Canonical starts up a mailing list thread about changing the way the
> board works or the criteria?  Are we supposed to think it's just a
> coincidence that Jono asks the TB to change the way the DMB works
> (without even CC'ing the DMB) so soon after...twice now?  From the
> outside it sure looks like strings being pulled to "fix" us.

I confess to not reading the entire IRC logs, but I saw about 5 irc
messages of disagreement at the top of each and then things were left
hanging. One participant tried to state how he felt the policies were
not being applied correctly (about needing a full 6 months for
membership), and this is a perfectly valid point to try to argue. Maybe
he's wrong, but he is within his rights to raise the issue. It's true
that the communication style in the messages may have been sarcastic or
a little heated, but it's an irc channel and par for the course. If
people can't voice disagreements in this fashion, then that's a problem.

Tweets are, as far as I'm concerned, personal messages. If you don't
like them, don't read them. Nothing of consequence should occur through
tweets, and nothing of consequence should happen because of tweets
(outside of really egregious issues that I'll leave aside).

I don't know exactly what Jono or others are attempting to do that make
you think they are trying to "fix" you. If he did not raise issues with
you before going to the TB, then maybe he should have. However, the TB
is a public board as well, and I don't understand who sets the policy
for how to DMB operates, so perhaps Jono was just trying to make things
better for everyone and thought this was the right way. And as I noted
elsewhere, how one communicates with the DMB is a bit murky since the
only mechanism is a private mailing list which you can't find on
lists.ubuntu.com (I had to google for it by name).

If this all revolves around something Jono is doing, I don't know any
specifics, but as someone who has worked with him I really do believe he
is trying to make things better. There are many historical examples of
how good intentions lead to bad results, and this very well could be one
of them. But please understand that everyone is trying to make things
better.

If you do find yourself in a position where you feel you are being
marginalized by specific people, it's always best to first try to
approach them directly and ask what is going on. I think if you
approached Jono or whoever is making you feel this way, you might find
that he just has a few concerns and you can help resolve them. Or, you
might find maliciousness, in which case you now have evidence and can do
something about it. However, leaving things as they are and assuming ill
will does nobody any good.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/04/2011 08:09 AM, Mackenzie Morgan wrote:
> On Thu, Aug 4, 2011 at 10:41 AM, Marc Cluet  wrote:
>> Amongst those projects are Orchestra and Ensemble, both are mainly driven by 
>> Canonical but are Ubuntu projects, as emerging projects they do need some 
>> time to catch the community interest, so far they've been driving by very 
>> sharp minds working for Canonical (amongst them Clint Byrum and Gustavo 
>> Niemeyer, my kudos go to them).
> 
> Dustin has made it clear that he thinks they are part of Ubuntu.  He
> and Emmet were supposed to have a discussion post-meeting about where
> Orchestra/Ensemble fit, and as mentioned up-thread, the CC is now
> going to have to weigh in on which Canonical projects are separate
> versus part of Ubuntu.  All we had to go on in Juan's meeting, though,
> was this:
> 
>   I understand that.  Do you believe them to be part of the
> same project, or do you see Orchestra as a project to deploy the
> output of the Ubuntu project?
> persia:  separate projects with a very parallel development
> and deployment cycle ( after all, Orchestra is mainly managed by the
> server/platform team )
> 
> If he doesn't think it's part of Ubuntu... we were a bit hand-tied.
> 
>> When our manager Dustin believed that we had gathered enough experience in 
>> order to become Ubuntu members he recommended us to do so, since he believes 
>> strongly in the community and Ubuntu (as so do we, otherwise we wouldn't be 
>> working for Canonical), and he gave us his recommendation, not out of being 
>> our manager but out of believing that we could be very useful community 
>> members and that after working with us in a day to day basis for months he 
>> thought we were more than ready for taking this step. I can completely 
>> understand Dustin's frustration from this point of view and I'm sad that 
>> this is resounding negatively with you Mackenzie, I do apologise personally 
>> (for my contributing part of being rejected) for that.
> 
>> When I stepped in front of the DMB in the irc meeting I was rejected because 
>> they felt that I didn't interact enough with the Ubuntu community, even if 
>> I've been interacting directly with upstreams (mcollective, ruby, etc…) and 
>> there's no community involvement yet with Orchestra, although there's some 
>> already with Ensemble that I'm very happy about. As you can understand it's 
>> a very complicated situation to be in.
>>
>> Please don't get me wrong, I'm very grateful for the DMB and its altruistic 
>> task, and I'll be the first one to defend its judgements. I learned from the 
>> DMB meeting and try very hard to downplay the negative parts of it and learn 
>> constructively from the recommendations, I'll try again to apply for 
>> contributing developer in the future because I believe I can be useful to 
>> the community not only when I'm working for Canonical but also on my free 
>> time.
>>
>> Hope this extended explanation gives you a bit more insight from the other 
>> side :)
> 
> I don't have a problem with anyone applying or having their
> coworker/managers encourage them.  Contributors should all be
> encouraging each other. It's the refusal to accept "not yet" as an
> outcome by some of the endorsers that is causing chunks of various
> membership boards to burn out. Why not just appoint a board stacked
> with the people who will vote the "right" way?

Here's what I see happening:

* Some individuals have the differing impressions of what it takes to
get approval for the various levels of membership offered by the DMB. I
don't think anyone at Canonical is trying to subvert the DMB, so the
other reason for these issues is that they really don't understand the
requirements. This is borne out by the fact that the
membership-through-upstream issue has been raised. Outlining the
criteria more clearly or in a different way may help.

* Few people are interested in criticizing any board that they have to
go in front of to be evlauted. I know that for me I just put up with it
for a while, but I crossed a threshold where I felt things weren't
working well enough and decided to make my voice heard.

* Canonical employees are in a somewhat unique position in that they can
often perform their work better by becoming members and getting upload
rights. This can affect how they perceive the process and how willing
they are to attempt to provide criticism (hopefully constructive). If
I'm a random contributor from outside and I'm rejected, especially at
the membership level, then there's a good chance I throw my hands up and
say "I'm gonna take my ball home". Canonical employees don't have this
luxury, we need to try to work with the system, and that's a good thing.

* I believe the last point ends up resulting in a disparity of who
voices criticism. If how well you perform at your job, which feeds your
family, etc, is determined partly by whether you are approved to be an
Ubuntu member, then if you are rejected you will likely try to figure

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 02:01 PM, Chase Douglas wrote:
> On 08/03/2011 01:45 PM, Stéphane Graber wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 08/03/2011 04:36 PM, Chase Douglas wrote:
>>> On 08/03/2011 12:50 PM, Allison Randal wrote:
>>>> On 08/03/2011 12:23 PM, Chase Douglas wrote:
>>>>> On 08/03/2011 12:14 PM, Mackenzie Morgan wrote:
>>>>>> On Wed, Aug 3, 2011 at 3:07 PM, Chase Douglas 
>>>>>>  wrote:
>>>>>>> What is the policy for email applications? Can anyone apply
>>>>>>> this way, or is it only under specific circumstances?
>>>>>>
>>>>>> Split votes go to the mailing list to try to find enough +1s
>>>>>> after a meeting. Board members can email in advance a +1/-1 if
>>>>>> they have no questions (either because they didn't to start
>>>>>> with or because they already talked to the person)
>>>>>>
>>>>>> The only time I've seen the application be done *completely* in
>>>>>> email was when there was a 9-person-ish queue.
>>>>>
>>>>> Ok, that's evidence of what's been done in the past, but what is
>>>>> the policy? Can I do it myself? I'm asking because I seriously
>>>>> would rather do apply through email than get up at 6 AM on a
>>>>> Monday morning, hoping there's a quorum :).
>>>>
>>>> In my experience with various projects and communities, review
>>>> processes that are done entirely by email or bug queues are
>>>> generally less responsive, not more responsive. Regular time-based
>>>> meetings are a useful social motivator. And, as an applicant, a
>>>> multi-week email thread picking over their credentials is likely to
>>>> be far more daunting than a quick discussion on IRC.
>>>>
>>>> But, this is a decision for the DMB, or if they choose to escalate
>>>> it, a decision for higher community authorities. They understand
>>>> the concern raised by several community members (including you), so
>>>> it's time to step back and allow the community process to operate.
>>>
>>> Maybe my problem is that I'm asking in the wrong forum or the wrong
>>> way. I have this legitimate question for the board, so how do I ask
>>> it? I asked Mackenzie because it naturally flowed in the email
>>> thread, but she's just one member of the board, so it might have
>>> seemed I was singling her out.
>>>
>>> Do I simply need to sit and wait for a response on this thread, or do
>>> I need to ask somewhere else? I really don't mean to badger with
>>> questions on the list, it's only because I can't find any information
>>> on how else to interact with the board.
>>>
>>> Thanks!
>>>
>>> -- Chase
>>
>> Hi,
>>
>> You can contact the whole DMB at:
>> developer-membership-bo...@lists.ubuntu.com
>>
>> Or add an agenda item for our next meeting:
>> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
> 
> Ahh, thanks! I'll subscribe to the list and send any more emails about
> this there.

Hrm, that list is private and I can't join. There must be some way to
communicate with the board other than by adding a meeting agenda or
hoping that an email you send to a private list is attended to. I would
also like responses to questions I ask be available to others, and a
private mailing list doesn't allow for this.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 02:05 PM, Scott Kitterman wrote:
> On Wednesday, August 03, 2011 04:06:26 PM Chase Douglas wrote:
>> On 08/03/2011 12:44 PM, Scott Kitterman wrote:
>>> On Wednesday, August 03, 2011 03:04:14 PM Chase Douglas wrote:
>>>> On 08/02/2011 09:33 AM, Chase Douglas wrote:
>>> I think it's really up to the DMB to decide how they want to run their
>>> application process.  I think you should let them figure it out with our
>>> input. There appeared to me to be a very different ratio of
>>> liking/not-liking your proposal based on if someone was employed by
>>> Canonical or not.  I would suggest that given the current level of
>>> pressure on the membership boards by various Canonical people that this
>>> would be a particularly good time NOT to be pushing about trying to
>>> force a process change on them.
>>
>> Please, stop assuming input here has anything to do with Canonical. I
>> can state unequivocally that my input has nothing to do with who I work
>> for. I am but an Ubuntu developer here. If it helps, I've used my
>> @ubuntu.com email address to make it even more clear :).
>>
>> I also do not believe anyone is trying to whitewash things for
>> Canonical. I want to point out a few things:
>>
>> 1. Many Canonical employees started out as Ubuntu members before they
>> were employees. I doubt they are now trying to subvert a community they
>> were and currently are a part of.
>> 2. I have not seen anyone at Canonical apply for membership levels that
>> did not make sense for that individual. I am unaware of anyone being
>> granted membership based even in part on their status as a Canonical
>> employee.
>> 3. There are many Canonical employees who do not participate in Ubuntu.
>> I have not seen any of them try to subvert the Ubuntu community.
>> 4. I have no numbers here, but I believe if you look at the percentage
>> of top Ubuntu contributors you will find that many also happen to be
>> Canonical employees. If you filter them out, you may be forsaking
>> valuable input from a large portion of the community.
>>
>> Every once in a while there may be a case where an individual Canonical
>> employee has stepped out of bounds. I feel I can guarantee that it was
>> not done to harm the Ubuntu project or community, but the end result may
>> have been just that. Where I have seen that happen, I believe the
>> parties have taken responsibility and corrected their actions. However,
>> I see no reason to believe there is a systemic problem.
>>
>> If you believe there is a problem, please bring it up in whole in a
>> separate thread. Comments like this do nothing but poison the
>> conversation. Please judge things on their merits, not on who the
>> contributor is employed by.
> 
> Much of this entire discussion was started by Canonical employees wanting 
> special case treatment for upstream work sponsored by Canonical.  It was a 
> Canonical employee that proposed to the Tech Board, without even consulting 
> with the DMB first, to change how the DMB could assess applications and 
> restrict their ability to deny applications.  Multiple members of multiple 
> boards have complained they feel like they are subject to harrassment from 
> Canonical managers if they don't approve a Canonical applicant.  The 
> agree/disagree ratio on your proposed change in how to change the application 
> process was roughly reversed depending on if someone was employed by 
> Canonical 
> or not.
> 
> I think there is a serious split between the Canonical and non-Canonical 
> parts 
> of the community right now and trying to pretend it doesn't exist doesn't 
> help.  I think it is broad and systematic.  I don't believe it's intentional. 
>  
> I do believe it's a problem.

If that's the case, then I am unaware of it. I will take your word for
it, and would tend to agree with you if what you have stated is full and
accurate. I apologize for any unbeknownst mistakes in my
characterization of the relationship between Canonical and Ubuntu.

However, please understand that I have nothing to do with any of that
(other than ancillarily dragging myself into the upstream contributions
discussion without knowing anything of it). Everything I read here on
ubuntu-devel from Canonical employees appears to be unbiased to me. If
you see bias, please feel free to call it out, but I haven't seen
anything. However, do not assume that the intentions of everyone who
works at Canonical are biased, and please evaluate input on the merits
of the input alone.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 01:45 PM, Stéphane Graber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 08/03/2011 04:36 PM, Chase Douglas wrote:
>> On 08/03/2011 12:50 PM, Allison Randal wrote:
>>> On 08/03/2011 12:23 PM, Chase Douglas wrote:
>>>> On 08/03/2011 12:14 PM, Mackenzie Morgan wrote:
>>>>> On Wed, Aug 3, 2011 at 3:07 PM, Chase Douglas 
>>>>>  wrote:
>>>>>> What is the policy for email applications? Can anyone apply
>>>>>> this way, or is it only under specific circumstances?
>>>>>
>>>>> Split votes go to the mailing list to try to find enough +1s
>>>>> after a meeting. Board members can email in advance a +1/-1 if
>>>>> they have no questions (either because they didn't to start
>>>>> with or because they already talked to the person)
>>>>>
>>>>> The only time I've seen the application be done *completely* in
>>>>> email was when there was a 9-person-ish queue.
>>>>
>>>> Ok, that's evidence of what's been done in the past, but what is
>>>> the policy? Can I do it myself? I'm asking because I seriously
>>>> would rather do apply through email than get up at 6 AM on a
>>>> Monday morning, hoping there's a quorum :).
>>>
>>> In my experience with various projects and communities, review
>>> processes that are done entirely by email or bug queues are
>>> generally less responsive, not more responsive. Regular time-based
>>> meetings are a useful social motivator. And, as an applicant, a
>>> multi-week email thread picking over their credentials is likely to
>>> be far more daunting than a quick discussion on IRC.
>>>
>>> But, this is a decision for the DMB, or if they choose to escalate
>>> it, a decision for higher community authorities. They understand
>>> the concern raised by several community members (including you), so
>>> it's time to step back and allow the community process to operate.
>>
>> Maybe my problem is that I'm asking in the wrong forum or the wrong
>> way. I have this legitimate question for the board, so how do I ask
>> it? I asked Mackenzie because it naturally flowed in the email
>> thread, but she's just one member of the board, so it might have
>> seemed I was singling her out.
>>
>> Do I simply need to sit and wait for a response on this thread, or do
>> I need to ask somewhere else? I really don't mean to badger with
>> questions on the list, it's only because I can't find any information
>> on how else to interact with the board.
>>
>> Thanks!
>>
>> -- Chase
> 
> Hi,
> 
> You can contact the whole DMB at:
> developer-membership-bo...@lists.ubuntu.com
> 
> Or add an agenda item for our next meeting:
> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda

Ahh, thanks! I'll subscribe to the list and send any more emails about
this there.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 12:50 PM, Allison Randal wrote:
> On 08/03/2011 12:23 PM, Chase Douglas wrote:
>> On 08/03/2011 12:14 PM, Mackenzie Morgan wrote:
>>> On Wed, Aug 3, 2011 at 3:07 PM, Chase Douglas
>>>  wrote:
>>>> What is the policy for email applications? Can anyone apply this way, or
>>>> is it only under specific circumstances?
>>>
>>> Split votes go to the mailing list to try to find enough +1s after a 
>>> meeting.
>>> Board members can email in advance a +1/-1 if they have no questions
>>> (either because they didn't to start with or because they already
>>> talked to the person)
>>>
>>> The only time I've seen the application be done *completely* in email
>>> was when there was a 9-person-ish queue.
>>
>> Ok, that's evidence of what's been done in the past, but what is the
>> policy? Can I do it myself? I'm asking because I seriously would rather
>> do apply through email than get up at 6 AM on a Monday morning, hoping
>> there's a quorum :).
> 
> In my experience with various projects and communities, review processes
> that are done entirely by email or bug queues are generally less
> responsive, not more responsive. Regular time-based meetings are a
> useful social motivator. And, as an applicant, a multi-week email thread
> picking over their credentials is likely to be far more daunting than a
> quick discussion on IRC.
> 
> But, this is a decision for the DMB, or if they choose to escalate it, a
> decision for higher community authorities. They understand the concern
> raised by several community members (including you), so it's time to
> step back and allow the community process to operate.

Maybe my problem is that I'm asking in the wrong forum or the wrong way.
I have this legitimate question for the board, so how do I ask it? I
asked Mackenzie because it naturally flowed in the email thread, but
she's just one member of the board, so it might have seemed I was
singling her out.

Do I simply need to sit and wait for a response on this thread, or do I
need to ask somewhere else? I really don't mean to badger with questions
on the list, it's only because I can't find any information on how else
to interact with the board.

Thanks!

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 12:44 PM, Scott Kitterman wrote:
> On Wednesday, August 03, 2011 03:04:14 PM Chase Douglas wrote:
>> On 08/02/2011 09:33 AM, Chase Douglas wrote:
>>> My proposal would be to do away with formal meetings, at least for
>>> evaluating typical applications, and move them to Launchpad. Create a
>>> project (maybe "ubuntu-developer-membership") and then have people open
>>> bugs when they have something to bring up before the board.
>>
>> There seem to be people who are in favor of this and people who are
>> sceptical. That's fine for now, but I think it would be worthwhile to
>> explore this option. This could also be used to supplement rather than
>> replace the current mechanism in cases where timezones don't line up or
>> at the applicants preference.

Sure, all I'm doing is providing an option and following through by
starting a foundation so it can be evaluated. I'm not on the board, and
I realize I don't have a vote in this manner.

> I think it's really up to the DMB to decide how they want to run their 
> application process.  I think you should let them figure it out with our 
> input.  
> There appeared to me to be a very different ratio of liking/not-liking your 
> proposal based on if someone was employed by Canonical or not.  I would 
> suggest that given the current level of pressure on the membership boards by 
> various Canonical people that this would be a particularly good time NOT to 
> be 
> pushing about trying to force a process change on them.

Please, stop assuming input here has anything to do with Canonical. I
can state unequivocally that my input has nothing to do with who I work
for. I am but an Ubuntu developer here. If it helps, I've used my
@ubuntu.com email address to make it even more clear :).

I also do not believe anyone is trying to whitewash things for
Canonical. I want to point out a few things:

1. Many Canonical employees started out as Ubuntu members before they
were employees. I doubt they are now trying to subvert a community they
were and currently are a part of.
2. I have not seen anyone at Canonical apply for membership levels that
did not make sense for that individual. I am unaware of anyone being
granted membership based even in part on their status as a Canonical
employee.
3. There are many Canonical employees who do not participate in Ubuntu.
I have not seen any of them try to subvert the Ubuntu community.
4. I have no numbers here, but I believe if you look at the percentage
of top Ubuntu contributors you will find that many also happen to be
Canonical employees. If you filter them out, you may be forsaking
valuable input from a large portion of the community.

Every once in a while there may be a case where an individual Canonical
employee has stepped out of bounds. I feel I can guarantee that it was
not done to harm the Ubuntu project or community, but the end result may
have been just that. Where I have seen that happen, I believe the
parties have taken responsibility and corrected their actions. However,
I see no reason to believe there is a systemic problem.

If you believe there is a problem, please bring it up in whole in a
separate thread. Comments like this do nothing but poison the
conversation. Please judge things on their merits, not on who the
contributor is employed by.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 12:35 PM, Mackenzie Morgan wrote:
> On Wed, Aug 3, 2011 at 3:24 PM, Scott Moser  wrote:
>> At very least, this issue needs to be fixed.  Meetings need to happen at
>> scheduled times, or be postponed/rescheduled at least 24 hours in advance.
> 
> Believe I already said this, but...
> The first two were when the board first went in, at which point we
> realised that the old board's meeting timeroyally sucked for all
> of us. So we changed it. And then it went along fine with us meeting
> all the time. The third was a holiday in the US, so I'm not at all
> surprised that it was missed, though we should've conferred first to
> see if anyone was planning on being awake before BBQ time ;)  My work
> schedule has changed so that I *cannot* attend the early meeting,
> period, which is part of why there was no quorum this week. A Doodle
> poll is up for us to pick a new time that actually works for
> everybody.

I think the message isn't that there aren't unforeseen circumstances.
It's that they need to be handled in a better fashion. Custom courtesy
(where I'm from at least :) says that meetings that are cancelled or
postponed have advance notice of at least 24 hours. If you can't give 24
hour notice of an absence, then perhaps you should reconsider if you are
a good fit for the board.

If one or two meetings a year don't reach quorum, that's reasonable. But
when members know ahead of time they will miss meetings, the board
should take responsibility to convey the information to other attendees.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 12:30 PM, Mackenzie Morgan wrote:
> On Wed, Aug 3, 2011 at 3:23 PM, Chase Douglas
>  wrote:
>> On 08/03/2011 12:14 PM, Mackenzie Morgan wrote:
>>> On Wed, Aug 3, 2011 at 3:07 PM, Chase Douglas
>>>  wrote:
>>>> What is the policy for email applications? Can anyone apply this way, or
>>>> is it only under specific circumstances?
>>>
>>> Split votes go to the mailing list to try to find enough +1s after a 
>>> meeting.
>>> Board members can email in advance a +1/-1 if they have no questions
>>> (either because they didn't to start with or because they already
>>> talked to the person)
>>>
>>> The only time I've seen the application be done *completely* in email
>>> was when there was a 9-person-ish queue.
>>
>> Ok, that's evidence of what's been done in the past, but what is the
>> policy? Can I do it myself? I'm asking because I seriously would rather
>> do apply through email than get up at 6 AM on a Monday morning, hoping
>> there's a quorum :).
> 
> There's *always* quorum at the...what-I-call-3-pm meeting, if that
> helps any. I don't know of a rule either way on processing by email by
> request.

What meeting is this? I only saw the 6 AM meeting on the agenda.

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 12:14 PM, Mackenzie Morgan wrote:
> On Wed, Aug 3, 2011 at 3:07 PM, Chase Douglas
>  wrote:
>> What is the policy for email applications? Can anyone apply this way, or
>> is it only under specific circumstances?
> 
> Split votes go to the mailing list to try to find enough +1s after a meeting.
> Board members can email in advance a +1/-1 if they have no questions
> (either because they didn't to start with or because they already
> talked to the person)
> 
> The only time I've seen the application be done *completely* in email
> was when there was a 9-person-ish queue.

Ok, that's evidence of what's been done in the past, but what is the
policy? Can I do it myself? I'm asking because I seriously would rather
do apply through email than get up at 6 AM on a Monday morning, hoping
there's a quorum :).

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 11:43 AM, Mackenzie Morgan wrote:
> On Wed, Aug 3, 2011 at 2:32 PM, Chase Douglas
>  wrote:
>> I don't think the DMB process is an important piece of community
>> socialization at all. I doubt many people pay attention to it if they
>> don't have a specific need to. There are much better and more important
>> social pieces of Ubuntu. I just want to make this piece as painless as
>> possible.
> 
> I can think of one case where seeing the social interactions between
> an applicant and board members in a meeting *should* have put up big
> red flags around that applicant. Apparently they weren't big enough,
> but he's gone now, and you can probably guess who I mean. Those red
> flags, if they were being noticed, would have been the usefully
> "social" part of the meeting.

Perhaps, but there are two issues:

1. I guess the red flags weren't seen, so the process didn't actually help
2. If the DMB allows email applications in lieu of board meetings, then
the point is moot

What is the policy for email applications? Can anyone apply this way, or
is it only under specific circumstances?

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/02/2011 09:33 AM, Chase Douglas wrote:
> My proposal would be to do away with formal meetings, at least for
> evaluating typical applications, and move them to Launchpad. Create a
> project (maybe "ubuntu-developer-membership") and then have people open
> bugs when they have something to bring up before the board.

There seem to be people who are in favor of this and people who are
sceptical. That's fine for now, but I think it would be worthwhile to
explore this option. This could also be used to supplement rather than
replace the current mechanism in cases where timezones don't line up or
at the applicants preference.

I created a script that would process Launchpad based DMB applications.
To do this, I am (ab)using the qastaging LP instance. I've created a
test scenario as follows:

New team: test-dmb-team
Members: Me
New project: test-dmb

The scenario is: I (Chase Douglas) am filing an application for Core
Dev. I created a bug for the application:

https://bugs.qastaging.launchpad.net/test-dmb/+bug/800139

If the bug disappears, it's because they wiped the qastaging instance. I
can recreate the bug with a script, so let me know if you want to see it
but it's gone

Here's where it gets a bit confusing: I can create a bunch of stuff on
qastaging, but I can't create new LP users to act as dummy DMB board
members. Thus, in the bug you see a mix of stuff from myself (the
applicant), and myself (the dummy DMB member), and myself (the output of
the script). I also had to set the threshold for approval to +1 since I
can't get anyone else to vote :).

If you go to the bug you'll see the end result. I'll explain what
happened in a timeline fashion:

1. I filed the bug. The description started at "I, Chase Douglas, apply
for core developer membership". The header was not present. The status
is New and no one is assigned.

2. The DMB ran the script (remember, I am also the DMB so it says I made
these changes). The status is moved to In Progress and the DMB team is
assigned. The comments are searched for anyone on the DMB who has made a
comment with only the following text: "+1", "0", or "-1". These are
considered votes and are tallied and prepended as a header to the
comment description. If a DMB member votes more than once, only the last
vote counts. The approval threshold is checked, but is not met yet.

3. A DMB member (myself again!) leaves a comment and a vote ("+1"). The
script is re-run, and the votes are tallied. The application meets the
threshold, so the header is updated and an "Official" notification of
approval is made as a comment. Since anyone can edit a description, this
official notification serves as the real testament of approval since the
comment creater is authenticated and obvious. The status is moved to Fix
Committed.

4. (Not done yet) A DMB member follows up and twiddles any bits required
to give Core Dev status. The member would then move the bug status to
Fix Released.

-

The next step would be to generate a web page with the status of all the
open applications so the DMB team can review it and quickly determine
what needs to be done. The web page would list vote totals, who has
reviewed, who still needs to review, and the status for each
application. I didn't do this yet because I was interested in feedback
on this approach overall.

P.S.: Code can be found at lp:~chasedouglas/+junk/dmbscripts. It's very
raw and obviously copy/pasted in the current form

Thoughts?

Thanks!

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/03/2011 09:18 AM, Oliver Grawert wrote:
> hi,
> Am Dienstag, den 02.08.2011, 09:33 -0700 schrieb Chase Douglas:
>> Hi all,
>>
>> Yesterday I attempted to attend a DMB meeting, but unfortunately only
>> two members showed so there wasn't a quorum. I think I've been to about
>> an equal number of meetings where quorum has and has not been reached
>> :(. This led me to think that there must be a better way to handle DMB
>> proceedings.
>>
>> My proposal would be to do away with formal meetings, at least for
>> evaluating typical applications, and move them to Launchpad. Create a
>> project (maybe "ubuntu-developer-membership") and then have people open
>> bugs when they have something to bring up before the board. Here's an
>> example of a bug I would create for this:
> 
> so you would turn a very important piece of community socialization into
> a plain formal buerocratic process, sorry but that doesnt feel like
> "linux for human beings" ...

/!\ Warning: The following represents how things seemed to me when I
went before a previous DMB. It may not apply to the current DMB, and if
so please excuse.

I don't think the DMB process is an important piece of community
socialization at all. I doubt many people pay attention to it if they
don't have a specific need to. There are much better and more important
social pieces of Ubuntu. I just want to make this piece as painless as
possible.

For me personally it feels like a bureaucratic process already, though I
don't think that can be helped much. It's a vetting process, and no one
really likes to be vetted.

> the meetings and direct conversation are an essential social bit of the
> membership process. while i agree there should be fallbacks for special
> cases so that people *can* use mail or special web forms if needed,
> using such a process as default to me looks like we moving away from our
> spirit completely ...
> 
> please dont turn the processes into unpersonal bruerocracy, while that
> works for many things i still like to think of ubuntus community as
> something that can do better and impose humanity towards others (since
> we still advertise that), especially for such an important step like
> entering said community.

I feel the process is already impersonal. Every time I've gone in front
of the board there was no social aspect to it. The only way it could be
conceived as social was that it was real-time communication. However,
that belies the fact that it was bland back and forth about details and
circumstances. If the DMB wants to make this process a "social" one, it
needs to re-evaluate how the meetings are driven. I don't think that's
necessary though.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/02/2011 06:46 PM, Scott Kitterman wrote:
> On Tuesday, August 02, 2011 04:04:31 PM Chase Douglas wrote:
>> On 08/02/2011 12:43 PM, Mackenzie Morgan wrote:
>>> On Tue, Aug 2, 2011 at 3:23 PM, Bryce Harrington  
> wrote:
>>>> Sounds like a good idea to me.  It makes it analogous to other processes
>>>> such as the sponsorship, MIR, SRU, etc. processes that applicants may
>>>> already be familiar with.
>>>
>>> And drastically different from the other team membership processes
>>> (Ubuntu Membership, Kubuntu Membership, etc.) that applicants may
>>> already be familiar with.
>>
>> True, but progress sometimes means change. I think this system would
>> work better, and if proven right it could be a model for other boards to
>> adopt. If it's worse, then the DMB can easily switch back. I would also
>> be happy to be a guinea pig for any process changes.
> 
> Speaking as someone who considers Kubuntu membership (as part of Kubuntu 
> Council) and developer (as part of kubuntu-dev), I don't think this is a good 
> idea.  As difficult as finding a good time for a meeting can be, I think the 
> interactive discussion is an important part of it.  I would hate to change 
> the 
> process into just a review of static content.  I believe this proposed change 
> would be a step backwards.  Membership boards already use email voting on a 
> case by case basis to address problems with sync when needed.  I think that's 
> sufficient.

I thought about this aspect some, but then I remembered what it was like
when I've gone before the DMB before. What I remember is getting a
question, me answering it within 30 seconds, and then waiting a few
minutes for another question. Loop this around for 15 minutes or more
per person. There was a lot of dead time that could have been chopped
out, and I don't think there was really a feeling of a dynamic conversation.

There's also an issue with applicants who aren't native english
speakers. It can be unsettling for anyone to go in front of a board, and
to do it in realtime as a non-native speaker of the language. It can
make things bad enough that it deters people from trying. AFAIK (and
I've been proven wrong many times recently :), the DMB is the only way
to get upload rights like Core Dev and MOTU and to handle package sets.

The issue with the email voting is two-fold:

1. It's not advertised anywhere. I didn't know it was possible until it
was mentioned yesterday. This is easy to fix.
2. As mentioned yesterday, there's the possibility that applications
fall through the cracks.

I personally would rather skip the meeting altogether and do it
completely static anyways, either through email or LP or something else.
Would the DMB find it acceptable if people opt for that option just
because applicants prefer it? Or is it only available if nothing else works?

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/02/2011 01:26 PM, Brad Figg wrote:
> On 08/02/2011 01:12 PM, Dan Chen wrote:
>> On Tue, Aug 2, 2011 at 16:04, Chase Douglas  
>> wrote:
>>> True, but progress sometimes means change. I think this system would
>>> work better, and if proven right it could be a model for other boards to
>>> adopt. If it's worse, then the DMB can easily switch back. I would also
>>> be happy to be a guinea pig for any process changes.
>>
>> I echo Chase's opinion in this regard; we should remain flexible in
>> adapting our approval processes.
>>
>> The only thing I add is that we should be cognizant of building a
>> timeout into the process using Launchpad so that applications don't
>> "spin indefinitely," e.g., "the stale five-digit Launchpad bug
>> report."
>>
>> Cheers,
>> -Dan
>>
> 
> You could use the model the kernel team is using for tracking workflow for
> SRU kernels. We have a project set up and a set of custom series that are
> used for tracking the workflow. A "bot" runs at regular intervals sending
> out nags if necessary or changing the status of a workflow item as previous
> dependencies are met.

That's interesting. How are custom bug series managed? I admin a few
projects on LP, but I can't find any way of doing this.

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/02/2011 01:12 PM, Dan Chen wrote:
> The only thing I add is that we should be cognizant of building a
> timeout into the process using Launchpad so that applications don't
> "spin indefinitely," e.g., "the stale five-digit Launchpad bug
> report."

Launchpad can auto-expire bug reports that remain inactive for a period
of X days. This could be used to handle stale applications where the
applicant isn't responsive. Would this fit what you are looking for?

-- Chase

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

Re: DMB: Proposal for a different review process

[Chase Douglas]

On 08/02/2011 12:43 PM, Mackenzie Morgan wrote:
> On Tue, Aug 2, 2011 at 3:23 PM, Bryce Harrington  wrote:
>> Sounds like a good idea to me.  It makes it analogous to other processes
>> such as the sponsorship, MIR, SRU, etc. processes that applicants may
>> already be familiar with.
> 
> And drastically different from the other team membership processes
> (Ubuntu Membership, Kubuntu Membership, etc.) that applicants may
> already be familiar with.

True, but progress sometimes means change. I think this system would
work better, and if proven right it could be a model for other boards to
adopt. If it's worse, then the DMB can easily switch back. I would also
be happy to be a guinea pig for any process changes.

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/29/2011 11:24 AM, Jordon Bedwell wrote:
> Hola,
> 
> On Fri, July 29, 2011 11:01 am, Michael Bienia wrote:
>> This leads to the next question: how much do you trust the person
>> writing the endorsement?
>>
>> Of course I trust endorsements from long-standing dev members with a
>> great reputation where I trust their ability to judge the packaging
>> skills and trustworthiness of the applicant. But should I apply the same
>> trust to e.g. a dev member who got accepted himself a month ago?
> 
> Why should you not trust that persons judgement unless there is compelling
> reason to believe their judgement should not be trusted.  It seems
> counter-intuitive to okay them for inclusion and then default on your own
> judgement of them by not trusting them without a very good reason to not
> trust them.
> 
> Yes, it's just fine to review an endorsement they give, like any open
> ecosystem would and does currently do, but flat out not trusting their
> judgement seems like you feel they don't belong there in the first place
> which leads to two questions: Why did you okay them them for inclusion at
> all if you aren't going to trust their judgement on skill?  Why would you
> okay him/her for inclusion if you have any reasonable doubt about their
> judgement on skill?

I think I may understand where Michael is coming from. If, for example,
I endorse someone based on their Python skills, that endorsement should
be near meaningless since I don't really know Python. If the application
reviewer doesn't know me, they might not realize this.

However, an application reviewer should be able to look up an unknown
endorser's credentials fairly readily. If you can't find any through a
glance at the endorser's LP page, Ubuntu wiki page, or Google search,
then I think it's fair to give up and not count that endorsement.

This can also be extrapolated beyond specific developer skills to more
subjective criteria like trustworthiness. For example, if an endorser is
a Core Dev, then their endorsement of the trustworthiness of an
applicant for upload rights should be valid even if the reviewer and
endorser don't know each other.

-- Chase

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

DMB: Proposal for a different review process

[Chase Douglas]

Hi all,

Yesterday I attempted to attend a DMB meeting, but unfortunately only
two members showed so there wasn't a quorum. I think I've been to about
an equal number of meetings where quorum has and has not been reached
:(. This led me to think that there must be a better way to handle DMB
proceedings.

My proposal would be to do away with formal meetings, at least for
evaluating typical applications, and move them to Launchpad. Create a
project (maybe "ubuntu-developer-membership") and then have people open
bugs when they have something to bring up before the board. Here's an
example of a bug I would create for this:

---

Affects: ubuntu-developer-membership
Status: New
Importance: Medium
Assigned to: Unassigned
Description:
I, Chase Douglas, am applying for Ubuntu Core Dev upload rights.


---

Endorsements can be added as bug comments. Since Launchpad is
authenticated, this removes the necessity of GPG signing of endorsements
(which no one seems to do anyways).

Once an applicant is ready to submit the application for review, they
subscribe the developer-membership-board team. Each board member can
review the application and ask questions in the bug comments. Once each
member has made a decision, they can comment with a +1/0/-1. When all
the votes are in (or a necessary amount), the bug can be moved to Fix
Committed or Fix Released. Fix Committed would mean a decision was
reached and following step must take place, like adding the developer to
the ubuntu-dev team. Fix Released would mean a decision was made and any
following steps have been completed.

One nice thing about this system would be the ability to re-open
applications. If an application is deferred, when the applicant is ready
to re-apply they can simply reopen the bug with more information.

This also can shorten the turn-around time for simple tasks, like adding
a package to a package set. These trivial tasks are slowed down by
waiting for a DMB meeting (with a quorum!), when they are very likely to
receive quick +1's from all the board members.

What do you think?

Thanks!

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/27/2011 03:59 PM, Iain Lane wrote:
> Hello,
> 
> On Wed, Jul 27, 2011 at 03:04:49PM -0700, Chase Douglas wrote:
>> [...] 
>> (Note: I don't want to get into specific cases, but the following is an
>> issue that I imagine is fairly unique. I've used my own personal case
>> here to illustrate the point, but I don't want to get into a
>> conversation about my particular merits here.)
>>
>> The other thing that I forgot to mention is that moving to a "trust"
>> model of requirements resolves the issue that I face: acceptable for
>> core-dev, but not for motu, and thus I'm not acceptable for core-dev. I
>> was told that I would be strongly considered for core-dev because of the
>> amount of work I've done on packages in main. However, core-dev implies
>> MOTU, and since I haven't done any (well, very little) universe work, I
>> couldn't be a MOTU. Hence, I'm stuck, and I seriously have no extra time
>> in the day to do any universe work.
>>
>> (The technical reason why I was told I was not acceptable for MOTU was
>> because I did not have a breadth of experiences dealing with universe
>> packages. By that, the board meant I did not have experience with
>> potentially poorly maintained packaging.)
>>
>> If one is trusted to upload system-critical packages and to know the
>> limits of his or her packaging competencies for main, then it shouldn't
>> be any different for universe.
> 
> I don't know who told you this, but it is not true.
> 
> Indeed it would be strange if you were to apply for MOTU and didn't
> actually care about universe at all.
> 
> Just because ~ubuntu-core-dev is a member of ~motu (and /many/ other
> teams, including hopefully all uploading teams) does not mean that you
> must demonstrate interest or competence in all of those areas.
> 
> If you've demonstrated competence, know your boundaries (can be
> trusted), and have endorsers then you should apply for upload rights.
> 
> This type of misinformation I think is a serious issue. I want to shout
> the previous paragraph from the rooftops. It's why I don't think the DMB
> has a serious problem in this area. It's what I think is at the heart of
> this huge thread: the perception that getting upload rights is
> impossible or that we deny good people the access they desire. I just
> simply do not think it is true.
> 
> I tried to write some guidelines, at least as much as can be written
> down
> 
>   https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess

Thanks Iain! I reviewed the guidelines and they seem reasonable and
appropriate to me.

I'll see about dusting off my application and giving it another go.

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/27/2011 01:08 PM, Mackenzie Morgan wrote:
> On Wed, Jul 27, 2011 at 3:55 PM, Chase Douglas
>  wrote:
>> However, I'm not quite sure on what the policy is for upload rights. The
>> issue I see is that the upload rights seem to be based on an intangible
>> "quantity" of stuff, and the "stuff" does not feel appropriate to me. My
>> understanding is that the "stuff" is experience in packaging. The
>> "quantity" of stuff relates both to how much packaging one has done, and
>> how many different forms of packaging one has worked on.
> 
> I was unsure about my MOTU application when I applied. On the one
> hand, I had Ogra being surprised when I needed a sponsor for Universe
> packages (other devs are surprised you can't upload? take it as a
> hint), but on the other I had like 15 uploads (wasn't sure that was
> enough). I kind of had the impression that I might need more uploads
> than that, and I've heard things where people think they need like
> 30+, and that's just...a lot.  I did do my first merge only a half
> hour before the IRC meeting, and in the meeting I explained this as "I
> didn't think I stood a chance without having done one."  I did not do
> any FTBFS or binary-new packages before my application.
> 
> So, for me, the quantity of "stuff" expected is not huge.  For a MOTU,
> I'd be more interested in the variety. If the person uploaded the same
> 5 packages 3 times each...why not go for PPU? If you're interested in
> a broader range of packagesshow that.
> 
> If you're just going for PPU, I'm not likely to care whether you have
> experience with lots of types of packaging, as long as you understand
> the ones used in the packages you're asking for.  For MOTU/Core-Dev,
> the "knowing your limits" thing comes in and includes "knowing when
> you're running across one of those types you haven't done before"

Assuming this is agreeable to everyone, why don't we write this down as
guidelines for the amount of work required. Some reference is better
than none. I've tried in the past to get this exact information out of
some on the board, and it was like pulling teeth and I didn't end up
with any information.

>> The problem with this approach is that it doesn't fit the granted
>> privileges. The privilege is the ability to upload to the official
>> archive. AFAIK, there is no other privilege associated with PPU, MOTU,
>> or Core-Dev. Essentially, the question is: do we trust the applicant
>> with the ability to make any changes to the set of packages they apply
>> for. Trust is orthogonal to skills/experience.
> 
> They are related though. Experience teaches you your limits.  Spending
> some time getting involved also gives you a chance to get to know lots
> of members of the community, and therefore establish trust with them.

Certainly they are related. I believe the problem is that the amount of
experience, which isn't really defined, is held up as a hard
requirement. It should be that you have enough experience such that you
know your limits and that you have valid endorsements from others. If
you cross that threshold, what more is there to prove?

---

(Note: I don't want to get into specific cases, but the following is an
issue that I imagine is fairly unique. I've used my own personal case
here to illustrate the point, but I don't want to get into a
conversation about my particular merits here.)

The other thing that I forgot to mention is that moving to a "trust"
model of requirements resolves the issue that I face: acceptable for
core-dev, but not for motu, and thus I'm not acceptable for core-dev. I
was told that I would be strongly considered for core-dev because of the
amount of work I've done on packages in main. However, core-dev implies
MOTU, and since I haven't done any (well, very little) universe work, I
couldn't be a MOTU. Hence, I'm stuck, and I seriously have no extra time
in the day to do any universe work.

(The technical reason why I was told I was not acceptable for MOTU was
because I did not have a breadth of experiences dealing with universe
packages. By that, the board meant I did not have experience with
potentially poorly maintained packaging.)

If one is trusted to upload system-critical packages and to know the
limits of his or her packaging competencies for main, then it shouldn't
be any different for universe.

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/27/2011 11:47 AM, Michael Bienia wrote:
> On 2011-07-26 15:53:09 -0500, Dustin Kirkland wrote:
>>  - The pressing need for some standards for what counts as "enough".
>> I've long been frustrated with the fuzzy, moving targets we have for
>> membership and privileges in Ubuntu, and I think we are long, long
>> overdue for some better published standards.
> 
> The requirements for membership didn't change: it was always
> "significant and sustained contributions". Where "sustained" is in the
> range of 6 months and I check if this is fulfilled when processing
> membership applications. But please don't understand that as strict 6
> months. I don't defer someone who is missing one or two weeks for those
> 6 months, but on the other hand I'd have concerns to count it as 6
> months if someone contributed for 2 weeks, then took a 5 month break and
> contributed for 2 weeks again. I like to see around 1-2 contributions
> per month (more is of course welcome; based on an average package
> complexity) to count for "sustained". Of course if someone is working on
> a very complex package I won't insist on that number but like to see
> that the applicant worked on it during that time (e.g. questions on IRC
> or mailing lists about certain problems he encountered).
> 
> But what counts as "contribution" seems to have changed over time. In
> the past (before UDD) my understanding of contribution was sponsored
> uploads to the main archive only (PPA don't count). It didn't change
> much till now and might need a discussion in the dev community what
> should count as contributions (for membership):
> I assume there is no much discussion needed for merge proposals (they
> should count).
> But what about packages in PPA: currently PPA don't count at all (at
> least for MOTU, not sure if they count for membership or not). Should it
> stay that way or should PPA count fully or only under certain
> conditions?
> What about "upstream" contributions? There was some discussion about it
> recently.
> Any other types of contributions I missed?

For me, the "quantity" that you mentioned (1-2 contributions/mo for 6
months) seems reasonable for Ubuntu membership. It's a very general role
and doesn't grant much responsibility. I see it as more of a badge of
honor. I don't have a lot of input to give on the "types" of
contributions, other than that I'd prefer it to be more inclusive than
exclusive, and with leeway for the board to take into consideration
alternative types.

(I also think the length of time of contributions should have some
leeway, but I'm not sure how to phrase my thoughts.)

However, I'm not quite sure on what the policy is for upload rights. The
issue I see is that the upload rights seem to be based on an intangible
"quantity" of stuff, and the "stuff" does not feel appropriate to me. My
understanding is that the "stuff" is experience in packaging. The
"quantity" of stuff relates both to how much packaging one has done, and
how many different forms of packaging one has worked on.

The problem with this approach is that it doesn't fit the granted
privileges. The privilege is the ability to upload to the official
archive. AFAIK, there is no other privilege associated with PPU, MOTU,
or Core-Dev. Essentially, the question is: do we trust the applicant
with the ability to make any changes to the set of packages they apply
for. Trust is orthogonal to skills/experience.

Imo, What we should be looking for is two-fold:

Packaging:
1. Has the applicant properly worked on packages in the past?
2. Is the applicant aware of the limits of their packaging competency?
3. Does the applicant seek out guidance when confronted with packaging
they are not competent with?

(Note that questions 2 and 3 should be answered through endorsements.)

Overall Trust:
1. Has the applicant used previous upload privileges (where granted)
properly?
2. Do endorsements provide positive feedback about the trustworthiness
of the applicant?
3. Are there any past issues that would show the applicant should not be
trusted with upload rights to the archive?

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/21/2011 03:52 PM, Iain Lane wrote:
> On Wed, Jul 20, 2011 at 04:11:16PM -0400, Jorge O. Castro wrote:
>> Hi everyone,
>>
>> I am confused as to the definition of the different levels of Ubuntu
>> Developers and how that relates to membership in each of the various
>> teams (though probably involves overall project membership as well). I
>> thought I would bring this up for discussion as it seems to be getting
>> more confusing and I'm having a hard time understanding what the level
>> of expectations for someone applying for Ubuntu membership for a given
>> role is, as well as to what the expected behavior is for endorsements
>> from existing members.
>>
>> According to https://wiki.ubuntu.com/UbuntuDevelopers an "Ubuntu
>> Prospective Developer" is someone "who probably just started
>> contributing to Ubuntu". The description on the wiki page doesn't list
>> anything critical there; the person still needs a sponsor to upload,
>> etc. From what I can read it's basically the same as Ubuntu Membership
>> but you're interested in eventually going down the development path
>> and you have a mentor/sponsor. Ok, that sounds good to me. This feels
>> like a position that should be relatively low barrier.
> 
> I didn't write that page, and I don't know who did. If it's confusing
> then please go ahead and fix it.
> 
> Prospective developer isn't a position. It's just what you are when you
> start being interested in Ubuntu Development. I found this definition on
> Google
> 
>   Likely to happen at a future date; concerned with or applying to the
>   future
> 
> By the way, I am disturbed at the amount of implied criticism the DMB is
> receiving in the past couple of weeks. Is it a coincidence that it comes
> shortly after we defer some applications (for the first time in a long
> while)? I am not just referring to this and the TB email thread, but
> also comments that appear on IRC when individuals don't feel an
> application is going the way they like.

For me, it has nothing to do with anything recent. My case is likely an
outlier, but the immediate problem I have is two-fold:

1. I've been lazy and haven't found time to provide feedback and try to
resolve my issues.

2. I don't really know of any way to provide feedback about the process.
I have talked to people outside the process and explained my situation,
and most of them scratch their head and agree that, at least how I
explained it, the outcome of my ordeal did not seem best.

I believe the criteria for acceptance of an applicant at some levels
does not match the role. If this is the appropriate forum to discuss
such issues, I'd be happy to elaborate. If I could be pointed to a more
appropriate place, that would be appreciated as well.

> I just found two quotes on [0] that both applicants and endorsers should
> be aware of.
> 
>   While contributions to those projects are appreciated and worth being
>   recognised, involvement in Ubuntu is required. After all it's all
>   about Ubuntu membership.
> 
> and
> 
>   We look for sustained and significant contributions. While there is no
>   precise period that we look for, it is rare for applications to be
>   accepted from people contributing for less than 6 months.
> 
> The DMB also applies these tests when granting membership. Please be
> mindful of these when you (even implicitly and without naming specific
> occasions, which invariably is what happens) criticise our actions.

My assumption was that since upstream contributions for Ubuntu
membership was brought up, then it was something that was likely to
happen. Apparently that's not the case :).

Thanks,

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/21/2011 11:48 AM, Mackenzie Morgan wrote:
> On Thu, Jul 21, 2011 at 2:40 PM, Chase Douglas
>  wrote:
>> On 07/21/2011 11:17 AM, Scott Kitterman wrote:
>>> All of that is equally true for any upstream work.  Should all postgresql
>>> developers be Ubuntu members?  If not, then why Unity developers?
>>
>> I believe all upstream developers of software that is meaningful to
>> Ubuntu (this is subjective) who also apply for membership and go through
>> the process should be acceptable for Ubuntu membership. If you have gone
>> through the process you are showing that you are interested in
>> contributing to Ubuntu. There's no short-cut here, you still have to
>> prepare an application, receive endorsements, and be reviewed by the
>> board. But I feel upstream contributions should be enough under certain
>> circumstances to warrant membership.
> 
> For regular membership or developer membership? Neither is for "I'm
> interested in contributing."  Both are for "I'm already contributing
> to Ubuntu."  For regular membership, we tend to expect some level of
> involvement with a LoCo team or mailing list or IRC or other form of
> tech support, maybe writing documentation, translating, etc.

I don't mean to say that mere "interest" in contributing is enough. But
if someone has been active in an upstream project that Ubuntu has
benefited from, then showing interest in direct Ubuntu development could
be taken into account for membership.

Maybe you could count a new contributor with 1 year of upstream
contributions to a core Ubuntu package plus a month or so of Ubuntu
packaging/bug triage/etc. of Ubuntu work as enough to merit membership.

It's just not very fun if there's this wall put up in front of
contributors saying: unless you fit into one of these 5 classes of
contributors, you can't be a member. All I'm advocating for is
flexibility in the process and the requirements where it makes sense.

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/21/2011 12:05 PM, Iain Lane wrote:
> On Thu, Jul 21, 2011 at 11:40:44AM -0700, Chase Douglas wrote:
>> The point is that I believe there are cases where it makes sense to
>> bestow Ubuntu membership on upstream-only individuals. When we create
>> and enforce policy, we need to keep in mind that we may be forsaking
>> valid corner-cases. Imo, A policy that says the DMB cannot grant
>> membership to an upstream-only contributor is too restrictive. If
>> anything, we should be as open as possible at the membership level.
>> Spread the love!
> 
> I didn't say that these people shouldn't be given membership. I said
> that the DMB isn't the right board to do this. We're don't grant
> membership to everyone who makes technical contributions. We grant
> membership (and upload access) to people interested in doing Ubuntu
> Development. This isn't excessive bureaucracy. It's a board not
> overstepping its bounds and, frankly, its competence.

I understand that the DMB wasn't set up to deal with this specific case.
However, if every board says "this isn't my realm", then we have a
problem. There should be a board that is capable of handling
non-standard applications. Maybe that isn't the DMB.

The reason I thought it should be the DMB is because it is the most
centralized membership board, in terms of geography and understanding of
Ubuntu development, that I am aware of.

> As I said before, there's currently no way for people who are only
> upstream contributors to get membership. The CC needs to decide how this
> should work, and how the membership applications are to be handled.

Perhaps it would be better to just define one board to handle "other"
applicants.

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/21/2011 12:32 PM, Scott Kitterman wrote:
> I disagree that a pure upstream membership path is appropriate.  It's been a 
> long held project value that "Because you work for Canonical" doesn't get you 
> special treatment in the project (either better or worse).  Treating 
> Canonical 
> sponsored upstream projects as anything other than the upstream projects they 
> are would change that in a way I don't think we want.  
> 
> I do agree that there are times when upstream work can be A factor in 
> membership, but unless people are actively involved in Ubuntu, they shouldn't 
> be members.  I know that will result in some Canonical people feeling like 
> they are left out.  If so, they should do like the rest of us do who aren't 
> paid to work on Ubuntu and just contribute.

I only want to address one small part of this. The reply seems to focus
quite a bit on Canonical developers and contributions. I do not make any
distinction, for or against, between a Canonical owned/developed and a
third-party owned/developed contribution. Because I eluded to personal
anecdotes earlier in the thread, I want to make clear that none of them
were based around whether any individual was a Canonical employee or not.

I have not personally seen any bias for or against Canonical in the
membership process. I believe membership is being granted on an
egalitarian basis.

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/21/2011 11:17 AM, Scott Kitterman wrote:
> On Thursday, July 21, 2011 01:09:46 PM Chase Douglas wrote:
>> On 07/20/2011 04:02 PM, Iain Lane wrote:
>>> On Wed, Jul 20, 2011 at 06:16:45PM -0400, Scott Kitterman wrote:
>>>> On Wednesday, July 20, 2011 05:43:23 PM Mackenzie Morgan wrote:
>>>>> [...] And then I guess you could add "should
>>>>> Canonical-sponsored upstream projects be treated differently than
>>>>> other upstream projects for purposes of Ubuntu Developer status?"
>>>>
>>>> I think it would be a serious mistake to treat them differently.
>>>
>>> Indeed. It's not clear to me why we're being expected to assess
>>> applicants whose contributions are (mainly) to upstream projects for
>>> Ubuntu membership. At least in my eyes, we as the DMB exist to consider
>>> Ubuntu developer applications. *This is not to say that upstream
>>> development does not count when considering developer applications, so
>>> please don't interpret it as such.*
>>>
>>> If upstream contributions to certain projects are to count as
>>> contributions towards Ubuntu membership status then it should be some
>>> other board that approves these memberships, not the Ubuntu Developer
>>> Membership Board. IMHO.
>>
>> I think this highlights an issue I see, however. It feels to me like
>> there's too much unnecessary "policy" that is bandied about when it
>> comes to ubuntu membership at multiple levels. Why does there really
>> need to be a different membership board? Would you not be able to
>> understand the merits of such an applicant and judge them appropriately?
>>
>> For example, say a community member has contributed a bunch of patches
>> to Unity code, which is incorporated upstream and not as patches against
>> the Ubuntu Unity package. This is technically upstream development, but
>> I feel everyone would agree that the contribution is benefiting Ubuntu.
>> If this person wants to be an Ubuntu member and participate in Ubuntu
>> outside of the Unity realm too, then I feel it is deserved. Does this
>> really need a different board to be handled?
>>
>> This is why there is a board of people in the first place: to handle
>> subjective issues and corner cases that an algorithm cannot deal with.
>>
>> I bring this up partly to illustrate the fact that I think the current
>> process errs too heavily on the "policy" side at the expense of common
>> sense. The approval process works well if you fit the standard mold of
>> applicants, but I feel I have been one and heard of other applicants
>> that by common sense should be approved but by strict adherence to
>> policy have been denied. This is all anecdotal, so I don't want to go
>> into details, but I think it is worthwhile to keep in mind whether
>> policy changes will really help to encourage and foster new and
>> continuing contributions to Ubuntu.
> 
> All of that is equally true for any upstream work.  Should all postgresql 
> developers be Ubuntu members?  If not, then why Unity developers?

I believe all upstream developers of software that is meaningful to
Ubuntu (this is subjective) who also apply for membership and go through
the process should be acceptable for Ubuntu membership. If you have gone
through the process you are showing that you are interested in
contributing to Ubuntu. There's no short-cut here, you still have to
prepare an application, receive endorsements, and be reviewed by the
board. But I feel upstream contributions should be enough under certain
circumstances to warrant membership.

If I were on the board, I would review an upstream-only application by
looking for:

* Upstream contributions whose goal was to make the software work better
on Ubuntu (not necessarily exclusively on Ubuntu, but if Ubuntu was the
personal impetus for the developer it would qualify)
* An interest in becoming more involved in Ubuntu development
* Endorsements specifically by current Ubuntu members that the
applicants work is improving the quality of Ubuntu

The point is that I believe there are cases where it makes sense to
bestow Ubuntu membership on upstream-only individuals. When we create
and enforce policy, we need to keep in mind that we may be forsaking
valid corner-cases. Imo, A policy that says the DMB cannot grant
membership to an upstream-only contributor is too restrictive. If
anything, we should be as open as possible at the membership level.
Spread the love!

-- Chase

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

Re: Understanding the definitions and expectations of our membership processes

[Chase Douglas]

On 07/20/2011 04:02 PM, Iain Lane wrote:
> On Wed, Jul 20, 2011 at 06:16:45PM -0400, Scott Kitterman wrote:
>> On Wednesday, July 20, 2011 05:43:23 PM Mackenzie Morgan wrote:
>>> [...] And then I guess you could add "should
>>> Canonical-sponsored upstream projects be treated differently than
>>> other upstream projects for purposes of Ubuntu Developer status?"
>>
>> I think it would be a serious mistake to treat them differently.
> 
> Indeed. It's not clear to me why we're being expected to assess applicants
> whose contributions are (mainly) to upstream projects for Ubuntu membership.
> At least in my eyes, we as the DMB exist to consider Ubuntu developer
> applications. *This is not to say that upstream development does not count
> when considering developer applications, so please don't interpret it as
> such.*
> 
> If upstream contributions to certain projects are to count as contributions
> towards Ubuntu membership status then it should be some other board that
> approves these memberships, not the Ubuntu Developer Membership Board. IMHO.

I think this highlights an issue I see, however. It feels to me like
there's too much unnecessary "policy" that is bandied about when it
comes to ubuntu membership at multiple levels. Why does there really
need to be a different membership board? Would you not be able to
understand the merits of such an applicant and judge them appropriately?

For example, say a community member has contributed a bunch of patches
to Unity code, which is incorporated upstream and not as patches against
the Ubuntu Unity package. This is technically upstream development, but
I feel everyone would agree that the contribution is benefiting Ubuntu.
If this person wants to be an Ubuntu member and participate in Ubuntu
outside of the Unity realm too, then I feel it is deserved. Does this
really need a different board to be handled?

This is why there is a board of people in the first place: to handle
subjective issues and corner cases that an algorithm cannot deal with.

I bring this up partly to illustrate the fact that I think the current
process errs too heavily on the "policy" side at the expense of common
sense. The approval process works well if you fit the standard mold of
applicants, but I feel I have been one and heard of other applicants
that by common sense should be approved but by strict adherence to
policy have been denied. This is all anecdotal, so I don't want to go
into details, but I think it is worthwhile to keep in mind whether
policy changes will really help to encourage and foster new and
continuing contributions to Ubuntu.

-- Chase

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

Re: touchpad: can we reverse up and down like iPod?

[Chase Douglas]

On 11/03/2010 03:16 PM, Peter Hendriks wrote:
> Hi,
> 
> would it be possible to enhance the touchpad properties/settings with an
> option for the two-finger scrolling to reverse up and down.
> 
> The reason is that when you frequently use iPod Touch and the like, the
> touchscreen or touchpad is used in a way that resembles
> the way when you put your fingers on a piece of paper. When you move
> your fingers down, the visible part moves up. And when
> you move your fingers up, the visible part becomes the lower part of the
> window.
> 
> Now, without the reverse up/down, there is no alignment towards the new
> way of scrolling used in not only Apple devices but
> also Samsung and others use this.

Hi Peter,

This is really due to a difference in device types. Touchpads are
indirect devices whereas touchscreens are direct devices. Direct devices
affect objects where you touch them in real space. Indirect devices
affect objects through some intermediary mechanism like a mouse cursor.

Right now there's ongoing work upstream in X.org to properly handle
multitouch devices. One part of this work entails identifying direct and
indirect devices and handling them as appropriate. I doubt we will need
a user configuration setting to ensure things work properly.

If you want to be more involved in this upstream development discussion,
I suggest following the multi-touch-...@lists.launchpad.net and/or
xorg-de...@lists.x.org mailing lists. Otherwise, I believe you can rest
assured that your thoughts are being accounted for in the current design
work.

Thanks,

-- Chase

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