Making it easier for people to work with upstreams

[C de-Avillez]

On 01/11/10 11:52, Jorge O. Castro wrote:
> On Mon, Jan 11, 2010 at 11:25 AM, Sense Hofstede <sense at qense.nl> wrote:
>   
>> I hope I'm not disturbing someone's precious plans right now, or am
>> repeating things that are already planned. However, I would find it a
>> waste if something like Adopt-a-Package would disappear because of
>> this, and I would find it bad when there would exist two different
>> structures with the same purpose next to each other.
>>     
> As far as I understand it the UpstreamContacts bit is a subset of
> Adopt-an-Upstream. Daniel?
>   

This is also my understanding.

Hopefully answering Sense's point more directly: (again, to my
understanding) adopt-a-package is a bug-(squad|control) activity, where
we are trying to achieve a faster and, ah, effectiver response to Ubuntu
bugs. There is no real requirement in it to be a formal contact
upstream. Nothing prohibits, or inhibits, an adopter to eventually being
an upstream contact, though.

On adopt-an-upstream, we are looking for a formal (as much as possible)
contact with an upstream. I would, anyway, never expect these positions
to be filled by *one* *single* person, but by a group of persons. Two
(of the many) reasons for this are:

* if you have one person, you have noone -- all that is needed is for
this person to get sick, or be overwhelmed by real work, and we lose the
contact with upstream;
* one person has to sleep, eat, work, have a personal life -- this means
no 24x7 coverage. This might not sound critical, but I remember one
upstream project that had weekly meetings at 04:00 my TZ every week. In
one year, I participated in two of them (because of insomnia!). I would
have been much more productive for us if there were more of us that
would be able to attend the meetings.

FWIW, all the times I discussed this I never thought of, or expected,
one single person to deal with one entire upstream (like, say, Debian,
or GNOME, or KDE, or GNU, etc). There are, of course, situations that
deal with the generic upstream (e.g., Debian directions and policies,
and Ubuntu directions and policies); in those cases, this would be a
discussion between the councils (or equivalents) and their proxies on
both sides, since this would probably require folks with some commit power.

Which is to say: adopt-an-upstream is (to my understanding) much more
geared towards *packages* in any upstream, than to the *whole* upstream.

We have to keep in mind that there are whole upstreams (that deal with
policies) and there are the projects under them (that deal with actual
packages, or directions). Each of these projects will most probably have
its own way of working. This is where adopt-an-upstream would really shine.

..C..

p.s. Just for the record, I have no commit power in Ubuntu, but I would
still adopt-an-upstream, and adopt-some-packages.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20100111/cc097efd/attachment.sig>