Re: Technical committee resolution

[Russ Allbery]

Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Mon, 17 Mar 2008 19:51:56 -0400, Clint Adams <[EMAIL PROTECTED]> said: 

>> I believe it is closer to the current process than
>> policy-process.(html|sgml|txt), but not yet spot-on.  I think if
>> someone were to match it to practice, it would help a large number of
>> people.

> I believe that wiki article came from email  proposal from
>  me. The idea is indeed to  move the current practice to what I
>  proposed, unless further discussi9on results in improvement of the
>  proposal.  Any takers?

I basically just went ahead and did that.  However, please do look over
what I sent to debian-policy about that, since I fiddled with it a bit and
the fiddling is certainly open for discussion.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Technical committee resolution

[Manoj Srivastava]

On Mon, 17 Mar 2008 19:51:56 -0400, Clint Adams <[EMAIL PROTECTED]> said: 

> On Tue, Mar 18, 2008 at 12:43:14AM +0100, Kurt Roeckx wrote:
>> I also think that the process is not clear to everybody.  There is an
>> policy-process.txt, but that doesn't seem to be current.  From
>> Anthony's mail about the delegation:

> Marga put this up: http://wiki.debian.org/PolicyChangesProcess

> I believe it is closer to the current process than
> policy-process.(html|sgml|txt), but not yet spot-on.  I think if
> someone were to match it to practice, it would help a large number of
> people.

I believe that wiki article came from email  proposal from
 me. The idea is indeed to  move the current practice to what I
 proposed, unless further discussi9on results in improvement of the
 proposal.  Any takers?

manoj
-- 
A truly great man will neither trample on a worm nor sneak to an
emperor. Franklin
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Desm S.A. Newsletter No65

[DESM S.A.]

This message is in MIME format. Since your mail reader does not understand this 
format, some or all of this message may not be legible.

Re: Q: All: Account creation latency

[Russ Allbery]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

>   FWIW Reviewing an AM report and an application is nothing near a small
> 5 minutes task. I believe it's rather 30 minutes of work per applicant
> if you do it seriously enough. Creating an account should though
> (meaning I don't know if it is, but I see no valid technical reasons for
> it not to be).

In theory, right now, Joerg already does the review, so all that's left
afterwards is a task that could theoretically be under two minutes.  I
don't know if that's how it works in practice, though.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Technical committee resolution

[Russ Allbery]

Clint Adams <[EMAIL PROTECTED]> writes:
> On Tue, Mar 18, 2008 at 12:43:14AM +0100, Kurt Roeckx wrote:

>> I also think that the process is not clear to everybody.  There is an
>> policy-process.txt, but that doesn't seem to be current.

It is almost completely wrong.  It will not be present in the next
release.

> Marga put this up:
> http://wiki.debian.org/PolicyChangesProcess
>
> I believe it is closer to the current process than
> policy-process.(html|sgml|txt), but not yet spot-on.  I think if someone
> were to match it to practice, it would help a large number of people.

It's high on my list to update that page and include it in a Team/Policy
page area on the Debian wiki similar to what I started doing for Lintian
and what other teams have already set up.  I was actually hoping to get to
that yesterday, but the bug triage took me a lot longer than I expected
(it always does).

Unfortunately, I'm in the middle of project deathmarch at work, which
means that the amount of time I have during the week for Debian work is
very limited, but I'm trying to find as much time as I can to get all of
this unstuck.  I know that right now what's going on is fairly opaque and
a few simple changes should help that a great deal.

I'm sorry this has taken so long -- I've been struggling to find time to
provide enough information to other people so that they can help.  I have
now finally also pinged all the other Policy delegates to get an idea of
where everyone stands.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Technical committee resolution

[Clint Adams]

On Tue, Mar 18, 2008 at 12:43:14AM +0100, Kurt Roeckx wrote:
> I also think that the process is not clear to everybody.  There is an
> policy-process.txt, but that doesn't seem to be current.  From Anthony's
> mail about the delegation:

Marga put this up:
http://wiki.debian.org/PolicyChangesProcess

I believe it is closer to the current process than
policy-process.(html|sgml|txt), but not yet spot-on.  I think if
someone were to match it to practice, it would help a large number of
people.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Technical committee resolution

[Kurt Roeckx]

On Mon, Mar 10, 2008 at 10:45:25PM -0700, Russ Allbery wrote:
> Anthony Towns <[EMAIL PROTECTED]> writes:
> > or the tech-ctte's involvement in technical improvement of Debian before
> > a conflict exists.
> 
> Well, with my Policy delegate hat on, I'd certainly welcome more help in
> that area, but on the other hand I'm not sure I see any specific need for
> the tech-ctte as such to get involved.  What's needed here more than
> anything else is simply more *people* who are actively doing more *work*,
> not more formal authority.
> 
> For example, there are currently insufficient Policy proposal reviewers
> active on debian-policy to even reach seconding thresholds on anything
> other than the most obvious or important proposals.
> 
> Some of this problem rests with me for not more actively soliciting help.
> I'm working on fixing that, although currently I prioritize my work as a
> Lintian maintainer over my work as a Policy delegate and Policy has been
> losing to Lintian frequently lately.

I think for most people it's unclear what the status of the various
bugs/proposals is.  I think the recent changes to the BTS you did should
atleast make it more clear.

I also think that the process is not clear to everybody.  There is an
policy-process.txt, but that doesn't seem to be current.  From Anthony's
mail about the delegation:
| AIUI, they'll be updating the policy-process document fairly soon to
| make it clear how other people can contribute to policy, and I believe
| that at least Russ and Marga will be spending some time doing some more
| routine policy tasks to improve their understanding of policy related
| issues. I know some other folks have already expressed interest in helping
| out on policy related tasks, and I'm pretty sure the policy team would
| appreciate your assistance, and be glad to offer suggestions on what
| forms your help might take.
[...]
| only includes the authority to create policy
[...]
| In so far as I was concerned that the policy delegation was being
| used to avoid working towards a consensus on technical policy, I've
| been reassured by subsequent discussion both on the -project and -vote
| lists and off-list that no one has any intention of letting that happen.
| The new policy team have my full confidence and support in their technical
| decisions and in their ability to help others contribute to policy,
| both individually and collectively.

I think if you asked for some help where you need it, people will try
and help.  It's just unclear to me how I can help.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Q: Steve McIntyre: 2IC vs. DPL

[Steve McIntyre]

On Wed, Mar 12, 2008 at 08:54:27PM -0400, Clint Adams wrote:
>Steve,
>
>You served a term as "Assistant Project Leader". What are the
>differences between the job you did then and the job you would
>do as DPL?

Hi Clint,

Mainly, I would expect to push some more high-profile issues than when
I was working with AJ, and also to be more visible. Back in 2006-7 I
did pick up on a few small issues, but I wouldn't have felt
comfortable working on anything too major myself. And then in some
respects I expect I'll be doing much the same, e.g. posting bits mail
highlighting cool stuff going on in the project.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Dasmohapatra


signature.asc
Description: Digital signature

Re: Q: All: Account creation latency

[Steve McIntyre]

On Sat, Mar 15, 2008 at 11:35:18AM +0100, Nacho Barrientos Arias wrote:
>Hello,
>
>If you get elected, what will you do to prevent people from waiting
>for weeks (and usually for months) to see their account created after
>DAM approval?

Hi Nacho,

NM is one of quite a few areas in Debian that I'd like to see
improved. If elected, I'd like to talk with a lot of our teams to see:

 a) how they think things are going
 b) how other people think things are going
 c) what can be changed to make the job easier / faster

and then I'd like to follow through to see those changes made. I'm not
going to promise full details or quick fixes in these places before
these reviews have happened, but I do promise to work on things.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds


signature.asc
Description: Digital signature

Re: Q: All: Account creation latency

[Joerg Jaspert]

On 11327 March 1977, Pierre Habouzit wrote:

>> We need to break that logic. I would like to talk with James and try to
>> convince him to create accounts as they come. It's well known that small
>> task (when they take less than 5 minutes) are usually best done "on the
>> fly" instead of accumulating them. And if Joerg notices that accounts are
>> created quickly, it will also help him process them more regularly instead
>> of reviewing AM reports by batches.
>   FWIW Reviewing an AM report and an application is nothing near a small
> 5 minutes task. I believe it's rather 30 minutes of work per applicant
> if you do it seriously enough. Creating an account should though
> (meaning I don't know if it is, but I see no valid technical reasons for
> it not to be).

Depending on the quality of the report (which doesnt mean quality of AM
or NM, also amount of mails and quoting style the people use and
stuff like that), its between 30 and 60 minutes.

If one does a reject you can count at least 2 hours, as you then need to
write a good reason for it. And that shouldn't be a small task, ever.

-- 
bye, Joerg
 There is no point in trying to fix bugs if I won't have an
  account. Sorry.


pgpuYo2uRTRBd.pgp
Description: PGP signature

Re: Q: Small tasks best on the fly? was: Q: All: Account creation latency

[Raphael Hertzog]

On Mon, 17 Mar 2008, MJ Ray wrote:
> Is creating accounts really now a sub-two-minute task? If so, that's
> great, but I believed there was still often a lot of multi-step
> independent double-checking in that task.

Honestly I don't know. But if it's not, then it gives us at least
a precise idea of technical improvement: that process must be quick and
the people in charge of steps before account creation should be able to
prepare a document ready to be used by a tool that creates the account.
The review of that document should be enough and the other checks should
be automated by the tool.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Q: Small tasks best on the fly? was: Q: All: Account creation latency

[Cyril Brulebois]

On 17/03/2008, MJ Ray wrote:
> Is creating accounts really now a sub-two-minute task? If so, that's
> great, but I believed there was still often a lot of multi-step
> independent double-checking in that task.

If not so, is that sooo long that there are only a
couple of runs each *year*?

-- 
Cyril Brulebois


pgp1kNoffFrgL.pgp
Description: PGP signature

Re: Q: All: Account creation latency

[Pierre Habouzit]

On Mon, Mar 17, 2008 at 07:35:35AM +, Raphael Hertzog wrote:
> We need to break that logic. I would like to talk with James and try to
> convince him to create accounts as they come. It's well known that small
> task (when they take less than 5 minutes) are usually best done "on the
> fly" instead of accumulating them. And if Joerg notices that accounts are
> created quickly, it will also help him process them more regularly instead
> of reviewing AM reports by batches.

  FWIW Reviewing an AM report and an application is nothing near a small
5 minutes task. I believe it's rather 30 minutes of work per applicant
if you do it seriously enough. Creating an account should though
(meaning I don't know if it is, but I see no valid technical reasons for
it not to be).
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpXyqLR5B4nS.pgp
Description: PGP signature

Re: Q: Small tasks best on the fly? was: Q: All: Account creation latency

[MJ Ray]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Mar 2008, MJ Ray wrote:
> > Where is this well known?  I thought opinion was divided. [...]
>
> I must admit that I've read some "Getting Things Done" related literature
> and that this organization method usually suggests to do small tasks on the
> fly instead of putting them in a TODO list as putting them in TODO list
> takes almost as much time as doing them. [...]
> http://wiki.43folders.com/index.php/GTD [...]
> GTD is quite popular and has been discussed on planet Debian several times
> together with the "Inbox Zero" principle... that's why I said "well-known".
> But you're right that I should have given more references.
> http://www.43folders.com/izero

I'm familiar with Inbox Zero and use similar practices myself, even
before I knew about it explicitly (thanks to the great gonzo again),
but it looks like Just Flippin' Do It has a *really* small threshold
under both systems there.  That's understandable, else we'd never get
out of our inboxes.

Is creating accounts really now a sub-two-minute task? If so, that's
great, but I believed there was still often a lot of multi-step
independent double-checking in that task.

Regards,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Q: Small tasks best on the fly? was: Q: All: Account creation latency

[Mark Brown]

On Mon, Mar 17, 2008 at 10:40:18AM +0100, Raphael Hertzog wrote:

> GTD is quite popular and has been discussed on planet Debian several times
> together with the "Inbox Zero" principle... that's why I said "well-known".
> But you're right that I should have given more references.

Note that the whole Inbox Zero approach tends to recommend batch mode
processing of your inbox as well as ensuring that you deal with
everything when you are processing stuff.  See for example:

http://www.43folders.com/2006/03/15/email-dash

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: All Candidates: Do you plan to be prominently visible during your term?

[Raphael Hertzog]

Hi,

On Sun, 16 Mar 2008, Holger Levsen wrote:
> On Saturday 15 March 2008 22:40, Marc Haber wrote:
> > Additionally, it may be a good idea to have regular "IRC conferences"
> > where the DPL is available to answer questions. A good time would
> > probably be a week after bits have been posted so that the questions
> > that the bits have raised can be answered. But that's only an idea,
> > not a "must", as long as the regular "bits" actually appear.
> 
> I actually like the idea. "IRC conference" might sound a bit too much, rather 
> something like "IRC feedback time" or such... 

As a regular IRC user, I have nothing against trying that. It would make a
good excuse to create #debian-meeting (similar to #ubuntu-meeting with
facilities to create IRC logs, a topic with a schedule and a bot to
translate hours in any local timezone).

But I don't see IRC as a very effective "mass-communication mechanism" [1]
and as such, it would probably be more useful to discuss the status of
various projects and inform people interested to help so that they are
up-to-date and can help effectively.

Cheers,

[1] Because not everybody uses IRC (Moritz for example doesn't use it
often), because it's difficult to refer to an IRC discussion and because
the ideas discussed "live" are not always well thought out.
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Q: Small tasks best on the fly? was: Q: All: Account creation latency

[Raphael Hertzog]

On Mon, 17 Mar 2008, MJ Ray wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > [...] It's well known that small
> > task (when they take less than 5 minutes) are usually best done "on the
> > fly" instead of accumulating them. [...]
> 
> Where is this well known?  I thought opinion was divided.  See
> Ganging your mosquito tasks http://www.43folders.com/2006/02/01/ganging-tasks
> for example.

I must admit that I've read some "Getting Things Done" related literature
and that this organization method usually suggests to do small tasks on the
fly instead of putting them in a TODO list as putting them in TODO list
takes almost as much time as doing them.

I do use GTD to keep up with all my work. (And an example of this
"on-the-fly" processing is for creation of VCS repositories on Alioth)

http://wiki.43folders.com/index.php/GTD

GTD is quite popular and has been discussed on planet Debian several times
together with the "Inbox Zero" principle... that's why I said "well-known".
But you're right that I should have given more references.

http://www.43folders.com/izero

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Q: Small tasks best on the fly? was: Q: All: Account creation latency

[MJ Ray]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> [...] It's well known that small
> task (when they take less than 5 minutes) are usually best done "on the
> fly" instead of accumulating them. [...]

Where is this well known?  I thought opinion was divided.  See
Ganging your mosquito tasks http://www.43folders.com/2006/02/01/ganging-tasks
for example.

I'd like to know whether a DPL candidate is prone to talking out of
their hat, or simply didn't give a reference for something they
thought was obvious. ;-)

Thanks,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Q: All: Account creation latency

[Raphael Hertzog]

(resending to list, I responded privately by error)

Hi,

On Sat, 15 Mar 2008, Nacho Barrientos Arias wrote:
> If you get elected, what will you do to prevent people from waiting
> for weeks (and usually for months) to see their account created after
> DAM approval?

Account creation is not the only problem, Joerg takes too much time to
DAM approve people as well. James creates accounts but he tends to do big
batches only... and when Joerg doesn't process them regularly, it takes
quite some time until we have a sizable number of DD waiting for account
creation.

We need to break that logic. I would like to talk with James and try to
convince him to create accounts as they come. It's well known that small
task (when they take less than 5 minutes) are usually best done "on the
fly" instead of accumulating them. And if Joerg notices that accounts are
created quickly, it will also help him process them more regularly instead
of reviewing AM reports by batches.

On the other side, it would be great if Joerg could create accounts
directly as well. But for this to happen, we need to implement some
changes to userdir-ldap (as right now DSA-like rights are needed to be
able to create accounts, and Joerg is not part of DSA but James is).
Maybe I can get a spec written by discussing with the involved parties and
then find someone to implement it.

On Sat, 15 Mar 2008, Marc Haber wrote:
> I would like to extend this question to "what will you do to improve
> the reaction speed of keyring management". We all know that if
> somebody wants to have a new key in the keyring today, that might not
> happen in 2008, which is a  shame. Will you candidates, as
> DPL, take measures (and which measures) to have requested keyring
> changes happen while you're still in power?

I would check with James what's exactly needed so that Jonathan McDowell
<[EMAIL PROTECTED]> (who has been added to the keyring group by James)
really gets write access to the keyring and can start handling tickets
where one has to modify/update the keyring to close them (maybe part of
the answer is that they should switch to jetring so that they can work
together on the keyring).

I would also ask to be granted read rights on the keyring request tracker,
so that I can have an idea of the work done (or not).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]