Re: Are Martin and Sam's platforms equivalent?

[Adam Borowski]

On Wed, Apr 03, 2019 at 12:40:45PM +0100, Ian Jackson wrote:
> I hesitate to bang this drum again, but this would be a great place to
> think about how we can use git more.
> 
> Ideally, our default sponsorship workflow would *not involve source
> packages or orig tarballs at all*.

It's too easy to get orig tarballs wrong.  Until all or most upstreams have
public git with tags, this might be problematic.  For this reason, I tend to
ask for an upload to mentors.d.n even when provided with a
some-random-workflow-git-repo (I especially hate anything related to gbp).

> If sponsorship was as simple as
> git debsponsor clone 
> cd 
> git diff dgit/dgit/sid # or maybe git diff upstream/stable-4.12
> dgit push-source

Shouldn't this include actual build, etc?  I have sponsored over 1000
uploads, yet not a single time I skipped the build step.  Sponsorees don't
tend to package libreoffice-sized stuff, and even uploads I otherwise merely
rubber-stamp too often miss some obscure B-Dep or something.  There's no way
I'd upload even an one-line change without a test build + bin-debdiff.

And, without a built package, you can't look at lintian.  It automates a
good part of reviewing.

> then (i) I would want to do much more sponsorship (ii) my sponsees
> would get the kind of timely service I can provide for `oh this is a
> 5 min job' type of task, rather than what I can provide for `this
> might take half an hour or it might take two hours'.

While git does have many upsides, I fail to see how it'd be better for
estimating required effort.  For comparison, my workflow is:

.--==[ .bashrc ]
alias lsdebs='grep ^Package: debian/control |cut -d" " -f2 >/tmp/deb-list'
alias diffdebs='for x in `cat /tmp/deb-list`;do c "$x" && apt download "$x" && 
debdiff --wt "$x"_*deb;done'
`--

dget 
cd 
lsdebs
dpkg-buildpackage -S -d# repack, gen changes
cd ..
sbuild 
diffdebs
apt source 
debdiff package_*.dsc|colordiff|less -R

This is the point where, having glanced at both diffs, I decide whether to 
rubber-stamp
or to do actual review.  Of course folks like Gürkan can pass even complex
changes with only a cursory look, newbies and poor-quality contributors get
even trivial changes fully reviewed, usual folks are in the middle.

What I'd wish for, is some CI that takes sponsoree-provided package, builds
it, and provides ready bin-lintian, src-debdiff, bin-debdiff, and the .debs
to look over -- but such a tool can be fed a dgit repo just the same as
existing mentors .dsc packages.  Unless you make dgit fully distributed like
"dget from some random URL" is, there's no gain.

And, monstrosities like gbp or patches-unapplied make quilt-in-git workflows
nastier to review than just comparing two unpacked dirs, the old way.


So, if you'd want to make _me_ happy, it would be nice if you could kill
quilt dead.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Re: Are Martin and Sam's platforms equivalent?

[Ian Jackson]

Sean Whitton writes ("Re: Are Martin and Sam's platforms equivalent?"):
> On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote:
> > 2. Package sponsorship
...
> > There are too few people reviewing packages at sponsorship-requests,
> > but proper and timely reviews would be very important both for not
> > frustrating new contributors and ensuring that new contributors
> > are learning to do high-quality packaging.

I hesitate to bang this drum again, but this would be a great place to
think about how we can use git more.

Ideally, our default sponsorship workflow would *not involve source
packages or orig tarballs at all*.

> The question is whether those processes could be changed such that the
> manpower problem would be less keenly felt.  I cannot myself see any way
> to achieve that -- there are tooling issues but improving the relevant
> tools would not significantly speed either queue.

Whenever I do sponsorship I find the task of consuming the bits I have
been provided by my sponsee far outweighs the task of checking what
they have done to the package.

This is seriously exacerbated by the additional friction which occurs
if I have any comment on the package which results in a respin.

If sponsorship was as simple as
git debsponsor clone 
cd 
git diff dgit/dgit/sid # or maybe git diff upstream/stable-4.12
dgit push-source
then (i) I would want to do much more sponsorship (ii) my sponsees
would get the kind of timely service I can provide for `oh this is a
5 min job' type of task, rather than what I can provide for `this
might take half an hour or it might take two hours'.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Are Martin and Sam's platforms equivalent?

[Paul Wise]

On Tue, Apr 2, 2019 at 6:11 AM Sean Whitton wrote:

> Fair enough, thanks.  I don't look at QA summaries opportunistically, so
> I see why we'd have different impressions in this area.

I wonder if folks are using how-can-i-help, that reports sponsorship
requests for packages you have installed these days. Of course that
doesn't help for new packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Are Martin and Sam's platforms equivalent?

[Paul Wise]

On Mon, Apr 1, 2019 at 3:05 AM Sean Whitton wrote:

> If I have relevant expertise or experience to improve Debian in some
> particular respect (e.g. fixing bugs in a packages written in a
> particular programming language that isn't so commonly used), I have
> strong reason to use my time to deploy that expertise and experience,
> rather than review some sponsorship requests.  The latter very rarely
> requires skills not possessed by all DDs.

OTOH, if you spend your time mentoring someone in that area, then once
they have gotten up to speed, you could potentially be responsible for
double the output after doing mentoring compared to before the
mentoring :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Are Martin and Sam's platforms equivalent?

[Sean Whitton]

Hello,

On Sun 31 Mar 2019 at 09:46PM +02, Jonathan Carter wrote:

> Well, maybe you and I just fundamentally disagree on this one then. My
> point was that if only 10 more DD's each took care of one more
> sponsorship request of the last month, we'd now basically efficiently
> have no backlog. As for your comment that additional tooling won't help,
> I know it will help at least for me, because I check my QA pages often
> because they're comprehensive, except for sponsorship requests. If they
> were more prominent, then at least I would spend more opportunistic
> attention to them. I certainly wasn't suggesting that DDs abandon some
> of the deep-focus work that they're doing to do forced reviews, so, I
> would not say that your summary is a fair representation of what I was
> putting across.

Fair enough, thanks.  I don't look at QA summaries opportunistically, so
I see why we'd have different impressions in this area.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Debian presence on newer platforms

[Jonas Meurer]

Hi Alex,

Alexander Wirt:
>>> And I tested hyperkitty some time ago with our archive and it was
>>> unusable slow.
>>
>> Interesting. I wonder how Fedora deals with this. I haven't used their
>> archives extensively, but from quick tests it appeared to be quite
>> responsive.
>
> One question that came into mind: which problems with our lists do you think
> mailman would solve? 
> 
> If its list archives: provide (or let someone do so) a hyperkitty plugin for
> reading our mboxes (bonus points if its able to also remove mails from it
> afterwards (gpdr, spam). 

Yeah, it's mainly the archive. I agree that a modern archiver that has
forum-like capabilities to participate in a discussion would lower the
barrier for contributors who're more into web applications that into
mail clients. Which - like it or not - seems to be the case even for
developers and techies in younger generations.

Besides, a huge advantage of mailman3 in my eyes is that it has a proper
user management. After registering *once* in Postorius (the mailman3 web
interface), you can manage *all* your mailing list subscriptions on that
mailman3 instance with one account. That's very convenient and something
I miss on lists.debian.org.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Re: Are Martin and Sam's platforms equivalent?

[Jonathan Carter]

Hi Sean

On 2019/03/31 21:05, Sean Whitton wrote:
> On Sat 30 Mar 2019 at 10:23AM +02, Jonathan Carter wrote:
>> That leaves less than 10 packages that need reviewing right now. I do
>> think that reviewing/sponsoring should be a lot better, and that more
>> DDs should play their part, and that our tooling can improve to bring
>> more visibility to these requests, but I would classify this more as a
>> medium priority problem TBH... hmm, am I being pedantic about
>> classification of problems... I digress..
>>
>> More packages moving to teams have been a great thing for Debian, I
>> think we should leverage that more for sponsorship requests. It would be
>> nice if a DD looked at their DDPO page and it would also show
>> outstanding sponsorship requests for the teams they're part of. It's
>> great that the DDPO pages now show outstanding merge requests from salsa
>> in the VCS column, I would've probably missed the few MRs I've received
>> so far if it wasn't for that.
>>
>> If a quarter of active DDs checked the RFS list / mentors.debian.net
>> just once a month and reviewed a package, there would probably be no
>> problem in terms of waiting to get a package sponsored whatsoever, I
>> think we could do more to advertise the todo list, maybe a weekly report
>> to debian-devel like the WNPP report may work well.
> 
> If I may summarise, your response is to invite more DDs to spend time
> reviewing sponsorship requests, and improve tooling a bit to reduce the
> friction in doing that; in particular, by pointing team members to
> sponsorship requests for packages that either are or will be maintained
> under the umbrella of that team.
> 
> As I said in the message to which you're replying, I am not convinced
> that any tooling improvements are going to change the state of play in
> this area.
> 
> So, then, your response is to ask more people to spend time on it.  The
> problem with that is that it ignores the good reasons people have for
> not spending time on it!
> 
> If I have relevant expertise or experience to improve Debian in some
> particular respect (e.g. fixing bugs in a packages written in a
> particular programming language that isn't so commonly used), I have
> strong reason to use my time to deploy that expertise and experience,
> rather than review some sponsorship requests.  The latter very rarely
> requires skills not possessed by all DDs.
> 
> Such reasons are defeasible, such as if I just really feel like
> reviewing sponsorship requests, but I think it's at the heart of the
> problem.  We *all* have particular things we can do better than most
> other DDs, so we have strong reason to work on those, not on something
> that all of us can do.

Well, maybe you and I just fundamentally disagree on this one then. My
point was that if only 10 more DD's each took care of one more
sponsorship request of the last month, we'd now basically efficiently
have no backlog. As for your comment that additional tooling won't help,
I know it will help at least for me, because I check my QA pages often
because they're comprehensive, except for sponsorship requests. If they
were more prominent, then at least I would spend more opportunistic
attention to them. I certainly wasn't suggesting that DDs abandon some
of the deep-focus work that they're doing to do forced reviews, so, I
would not say that your summary is a fair representation of what I was
putting across.

-Jonathan


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Are Martin and Sam's platforms equivalent?

[Sean Whitton]

Hello Jonathan,

On Sat 30 Mar 2019 at 10:23AM +02, Jonathan Carter wrote:

> That leaves less than 10 packages that need reviewing right now. I do
> think that reviewing/sponsoring should be a lot better, and that more
> DDs should play their part, and that our tooling can improve to bring
> more visibility to these requests, but I would classify this more as a
> medium priority problem TBH... hmm, am I being pedantic about
> classification of problems... I digress..
>
> More packages moving to teams have been a great thing for Debian, I
> think we should leverage that more for sponsorship requests. It would be
> nice if a DD looked at their DDPO page and it would also show
> outstanding sponsorship requests for the teams they're part of. It's
> great that the DDPO pages now show outstanding merge requests from salsa
> in the VCS column, I would've probably missed the few MRs I've received
> so far if it wasn't for that.
>
> If a quarter of active DDs checked the RFS list / mentors.debian.net
> just once a month and reviewed a package, there would probably be no
> problem in terms of waiting to get a package sponsored whatsoever, I
> think we could do more to advertise the todo list, maybe a weekly report
> to debian-devel like the WNPP report may work well.

If I may summarise, your response is to invite more DDs to spend time
reviewing sponsorship requests, and improve tooling a bit to reduce the
friction in doing that; in particular, by pointing team members to
sponsorship requests for packages that either are or will be maintained
under the umbrella of that team.

As I said in the message to which you're replying, I am not convinced
that any tooling improvements are going to change the state of play in
this area.

So, then, your response is to ask more people to spend time on it.  The
problem with that is that it ignores the good reasons people have for
not spending time on it!

If I have relevant expertise or experience to improve Debian in some
particular respect (e.g. fixing bugs in a packages written in a
particular programming language that isn't so commonly used), I have
strong reason to use my time to deploy that expertise and experience,
rather than review some sponsorship requests.  The latter very rarely
requires skills not possessed by all DDs.

Such reasons are defeasible, such as if I just really feel like
reviewing sponsorship requests, but I think it's at the heart of the
problem.  We *all* have particular things we can do better than most
other DDs, so we have strong reason to work on those, not on something
that all of us can do.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Are Martin and Sam's platforms equivalent?

[Jonathan Carter]

On 2019/03/30 00:16, Sean Whitton wrote:
> On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote:
>> 2. Package sponsorship
>> Any mentoring outreach aimed at finding new contributors should start
>> with no longer frustrating the people who have already started to
>> contribute. They might stop their contributions.
>> There are too few people reviewing packages at sponsorship-requests,
>> but proper and timely reviews would be very important both for not
>> frustrating new contributors and ensuring that new contributors
>> are learning to do high-quality packaging.
>> Spending any resources on finding new contributors who are starting
>> at zero doesn't really make sense as long as people who are already
>> contributing have to wait months for getting their ITPs reviewed
>> and uploaded (and then have to wait additional months while the
>> package is in NEW).
>
> This is a huge problem, indeed.
> 
> The two current processes that you identify as getting in newcomers' w
ay
> -- RFS bugs and the NEW queue -- are slow simply because of the fact
> that both of them are understaffed.  It's the usual problem with Debia
n
> not having the manpower we would like to have.
> 
> The question is whether those processes could be changed such that the
> manpower problem would be less keenly felt.  I cannot myself see any w
ay
> to achieve that -- there are tooling issues but improving the relevant
tools would not significantly speed either queue.

I acknowledge that it's a problem, but I don't agree that much that it's
a *huge* problem.

Here are the RFS bugs list:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;d
ist=unstable

Those 30 bugs which close ITPs are all reasonably recent (most bug
numbers start with 92...), and since we're in deep freeze they will
naturally be low priority.

That leaves 14 requests, of which one introduces a removed package back
to the archive, one would cause a transition, and a few of those have
been addressed and are going trough discussion / solving issues.

That leaves less than 10 packages that need reviewing right now. I do
think that reviewing/sponsoring should be a lot better, and that more
DDs should play their part, and that our tooling can improve to bring
more visibility to these requests, but I would classify this more as a
medium priority problem TBH... hmm, am I being pedantic about
classification of problems... I digress..

More packages moving to teams have been a great thing for Debian, I
think we should leverage that more for sponsorship requests. It would be
nice if a DD looked at their DDPO page and it would also show
outstanding sponsorship requests for the teams they're part of. It's
great that the DDPO pages now show outstanding merge requests from salsa
in the VCS column, I would've probably missed the few MRs I've received
so far if it wasn't for that.

If a quarter of active DDs checked the RFS list / mentors.debian.net
just once a month and reviewed a package, there would probably be no
problem in terms of waiting to get a package sponsored whatsoever, I
think we could do more to advertise the todo list, maybe a weekly report
to debian-devel like the WNPP report may work well.

In the #debian-python IRC channel, when a sponsorship request lands
there it goes in to the channel topic. I admit that I often forget to
look there myself, but there are small changes like that that could
become a project-wide cultural habbit that might also help bring
attention to sponsorship requests.

Well, that's just my views as a DD who thinks this is important and this
is an area I'd like to put some focus on regardless of the DPL elections
.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Are Martin and Sam's platforms equivalent?

[Sean Whitton]

Hello,

On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote:

> 1. Non-DDs getting single changes into Debian
> If you are not a DD, there is no process to get a change into
> Debian if the maintainer is MIA or is one of those maintainers
> who ignores the BTS and only uploads new upstream versions.
> Note that I am not talking about contoversial changes NAKed by the
> maintainer, I am talking about 10 year old clearly correct patches
> or "New upstream version" bugs that are rotting in the BTS.
> Whether a patch is rotting in the BTS or is rotting in a MR on salsa
> doesn't really make a difference on the underlying problem.

I'm not sure about this -- there is the same NMU process everyone else
uses, except that you need a sponsor.  Which brings me to...

> 2. Package sponsorship
> Any mentoring outreach aimed at finding new contributors should start
> with no longer frustrating the people who have already started to
> contribute. They might stop their contributions.
> There are too few people reviewing packages at sponsorship-requests,
> but proper and timely reviews would be very important both for not
> frustrating new contributors and ensuring that new contributors
> are learning to do high-quality packaging.
> Spending any resources on finding new contributors who are starting
> at zero doesn't really make sense as long as people who are already
> contributing have to wait months for getting their ITPs reviewed
> and uploaded (and then have to wait additional months while the
> package is in NEW).

This is a huge problem, indeed.

The two current processes that you identify as getting in newcomers' way
-- RFS bugs and the NEW queue -- are slow simply because of the fact
that both of them are understaffed.  It's the usual problem with Debian
not having the manpower we would like to have.

The question is whether those processes could be changed such that the
manpower problem would be less keenly felt.  I cannot myself see any way
to achieve that -- there are tooling issues but improving the relevant
tools would not significantly speed either queue.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Are Martin and Sam's platforms equivalent?

[Adrian Bunk]

On Tue, Mar 26, 2019 at 07:06:26PM -0400, Sam Hartman wrote:
> > "Jose" == Jose Miguel Parrella  writes:
> 
> Jose> The question is _what_ would be up for discussion, given it's
> Jose> only a year.
> 
> In the discussions here, three items have come up that resonate with me
> significantly:
> 
> 1) Can we recommend/require dh > 9?
> 
> 2) Do we want to more strongly recommend that people have packages in
> Git repos on Salsa?
> 
> 3) An eventual Git-based source format.
> 
> Note that I've discussed these as pure items about policy around
> packaging.  However, embedded in these discussions will be questions of
> work flow and collaboration.
> 
> So, at a minimum, I'd like to try and lead discussions on these 3 items.
> The specific discussions will be very different, but I think they will
> all be valuable discussions in helping make it easier to contribute to
> Debian.

They might be relevant for people already in Debian.

If you want to "make it easier to contribute to Debian" for non-DDs,
I'd say they are mostly irrelevant and the actual problems are elsewhere:

1. Non-DDs getting single changes into Debian
If you are not a DD, there is no process to get a change into 
Debian if the maintainer is MIA or is one of those maintainers
who ignores the BTS and only uploads new upstream versions.
Note that I am not talking about contoversial changes NAKed by the 
maintainer, I am talking about 10 year old clearly correct patches
or "New upstream version" bugs that are rotting in the BTS.
Whether a patch is rotting in the BTS or is rotting in a MR on salsa 
doesn't really make a difference on the underlying problem.

2. Package sponsorship
Any mentoring outreach aimed at finding new contributors should start 
with no longer frustrating the people who have already started to 
contribute. They might stop their contributions.
There are too few people reviewing packages at sponsorship-requests,
but proper and timely reviews would be very important both for not
frustrating new contributors and ensuring that new contributors
are learning to do high-quality packaging.
Spending any resources on finding new contributors who are starting
at zero doesn't really make sense as long as people who are already 
contributing have to wait months for getting their ITPs reviewed
and uploaded (and then have to wait additional months while the
package is in NEW).

> I'm sure other issues will come up, but those three are specifically
> items that people in the -vote discussion seem open to discussing more
> broadly and that I think are real pain points.
>...

My points are non-issues for DDs participating in a -vote discussion,
but are real barriers for people who are beginning to contribute.

Coming from the Debian bubble, it was a surprising experience when the
first patch I submitted to Yocto was on the master branch a day later.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Debian presence on newer platforms

[Alexander Wirt]

On Wed, 27 Mar 2019, Jonas Meurer wrote:

> Hi Alex,
> 
> Alexander Wirt:
> > On Tue, 26 Mar 2019, Jonas Meurer wrote:
> >> Alexander Wirt:
> >>> In my experience as a former mailman admin and listadmin mailman is a
> >>> no-go.
> >>> Getting our feature set even nearly into mailman is impossible, takes 
> >>> years
> >>> and will just get us an unmaintainable thing. I don't want to ever run a
> >>> bigger mailman setup again. 
> >>
> >> Can you give an example, what from "our feature set" is missing in
> >> mailman? Also, you probably mean mailman2, right? Have you taken a look
> >> at mailman3 recently?
> >
> > Sure, just a few coming into mind: 
> > 
> > All those gpg related features we use, our spam removal tools, our special
> > archiving hacks, we way we support blacklist through several lists, our
> > second line of spamfiltering, crossassassin, the way we can do management on
> > several lists and probably a lot more I forgot. It may take man years to do 
> > a
> > migration (in fact we talked about that a few days ago in our internal IRC
> > channel and this is more or less consense about the needed effort). 
> 
> Thanks for elaborating on that. At least some of them might be
> interesting to submit as mailman3 feature requests as they probably
> would be of help for other projects that use mailman3 as well.
> 
> I fully understand that you as the listmasters don't consider to switch
> right now though.
> 
> > And I tested hyperkitty some time ago with our archive and it was
> > unusable slow.
> 
> Interesting. I wonder how Fedora deals with this. I haven't used their
> archives extensively, but from quick tests it appeared to be quite
> responsive.
One question that came into mind: which problems with our lists do you think
mailman would solve? 

If its list archives: provide (or let someone do so) a hyperkitty plugin for
reading our mboxes (bonus points if its able to also remove mails from it
afterwards (gpdr, spam). 

Alex


signature.asc
Description: PGP signature

Re: Are Martin and Sam's platforms equivalent?

[Martin Michlmayr]

* Jose Miguel Parrella  [2019-03-26 15:30]:
> Martin, do you really see "lot of parallels" with Sam's platform?

My platform contains two major topics: 1) creating a more healthy
commercial ecosystem around Debian and 2) changing the culture.

While Sam doesn't mention 1), I do see a lot of parallels regarding 2).

> Sam's platform is all about innovative people mechanics.
...
> I get that no one wants to run for DPL on a platform of "let's get rid
> of the DPL" but Sam says he doesn't "see significant changes in
> governance required" while Martin mentions "change" 9 times, including:
> "I think Debian has reached a point where it's important to
> fundamentally rethink how our community operates"

Right, there's probably a difference in how severe Sam and I perceive
the problems to be, but when it comes to culture I think there are
parallels in terms of what needs to change.  That's what I was
referring to in my rebuttal.

> It's also clear there's a different approach to money and resources
> in the two platforms.

Yes.

-- 
Martin Michlmayr
https://www.cyrius.com/

Re: Debian presence on newer platforms

[Miles Fidelman]

On 3/26/19 7:07 PM, Jonas Meurer wrote:


Hi Alex,

Alexander Wirt:

On Tue, 26 Mar 2019, Jonas Meurer wrote:

Alexander Wirt:

In my experience as a former mailman admin and listadmin mailman is a
no-go.
Getting our feature set even nearly into mailman is impossible, takes years
and will just get us an unmaintainable thing. I don't want to ever run a
bigger mailman setup again.

Can you give an example, what from "our feature set" is missing in
mailman? Also, you probably mean mailman2, right? Have you taken a look
at mailman3 recently?

Sure, just a few coming into mind:

All those gpg related features we use, our spam removal tools, our special
archiving hacks, we way we support blacklist through several lists, our
second line of spamfiltering, crossassassin, the way we can do management on
several lists and probably a lot more I forgot. It may take man years to do a
migration (in fact we talked about that a few days ago in our internal IRC
channel and this is more or less consense about the needed effort).

Thanks for elaborating on that. At least some of them might be
interesting to submit as mailman3 feature requests as they probably
would be of help for other projects that use mailman3 as well.

I fully understand that you as the listmasters don't consider to switch
right now though.

I expect it wouldn't be all that hard to migrate to Sympa.  Also open 
source, well supported, and designed for much larger operations than 
mailman (designed for universities).  Converting archives might be an 
issue, or older archives could just be left as is.


Miles Fidelman (runs a Sympa installation)




--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: Are Martin and Sam's platforms equivalent?

[Sam Hartman]

>>>>> "Jose" == Jose Miguel Parrella  writes:

Jose> The question is _what_ would be up for discussion, given it's
Jose> only a year.

In the discussions here, three items have come up that resonate with me
significantly:

1) Can we recommend/require dh > 9?

2) Do we want to more strongly recommend that people have packages in
Git repos on Salsa?

3) An eventual Git-based source format.

Note that I've discussed these as pure items about policy around
packaging.  However, embedded in these discussions will be questions of
work flow and collaboration.

So, at a minimum, I'd like to try and lead discussions on these 3 items.
The specific discussions will be very different, but I think they will
all be valuable discussions in helping make it easier to contribute to
Debian.

I'm sure other issues will come up, but those three are specifically
items that people in the -vote discussion seem open to discussing more
broadly and that I think are real pain points.


Jose> Sam's platform is principled about the DPL not
Jose> having an agenda and OK with leaving some things as they
Jose> are.

I don't think the DPL should have an agenda on what the answer should
be.  I think a DPL should have an agenda on questions to ask and on how
they will focus their effort.
(And I think collaboration with others is a great way to broaden that
agenda and allow us to make progress on more than one person's focuses)


Jose> In Sam's platform, the difficulty of making changes in
Jose> Debian is a "perception".

It's a bit more complex than that.  First, I do think that there is a
perception change is hard.  That alone is bad: it discourages people
from driving changes and creates a perception that Debian is harder to
join and contribute to.

Beyond that though, I think that decisions are actually difficult to make.
I think that fixing that may involve better use of tools that we already
have rather than new tools.  I think we could do a lot more of
summarizing and leading discussions and calling consensus explicitly to
the extent we have it.  I think we could do a lot more of helping people
feel heard and considered so they do not feel a need to repeat the same
point again and again.  I think that putting someone in charge of
driving a discussion can be valuable because they can help make sure
that important parties don't drop the discussion and things don't stall.

And as I discussed, I think that we can find less confrontational ways
to use our existing tools to make decisions when consensus doesn't
happen.


Jose> I get that no one wants to run for DPL on a platform of "let's
Jose> get rid of the DPL" but Sam says he doesn't "see significant
Jose> changes in governance required" while Martin mentions "change"
Jose> 9 times, including: "I think Debian has reached a point where
Jose> it's important to fundamentally rethink how our community
Jose> operates"

I don't think the way Martin uses operates is really similar to the way
I use governance.
Which is to say I don't see an inherent conflict in saying that Debian's
governance doesn't need to change significantly, while the way Debian
operates does.

I suspect Martin and I do disagree some here, especially around
degreee and on how well Debian is working today.  I'm just not sure the
text you point to is a good example of that disagreement.


Jose> It's also clear there's a different approach to money and
Jose> resources in the two platforms.

That's not obvious to me.  Martin and I seem reasonably well aligned on
*what* we'd like to have happen with money.  Martin is willing to take
more risk than I am to get there (or try something new) on the money
front; especially he's willing to risk more controversy.
I'd love to accomplish the same goals, but I'm not willing to take on as
much risk to do it, and I think the best way for me to drive those goals
might well be to delegate to someone else.



signature.asc
Description: PGP signature

Re: Debian presence on newer platforms

[Jonas Meurer]

Hi Alex,

Alexander Wirt:
> On Tue, 26 Mar 2019, Jonas Meurer wrote:
>> Alexander Wirt:
>>> In my experience as a former mailman admin and listadmin mailman is a
>>> no-go.
>>> Getting our feature set even nearly into mailman is impossible, takes years
>>> and will just get us an unmaintainable thing. I don't want to ever run a
>>> bigger mailman setup again. 
>>
>> Can you give an example, what from "our feature set" is missing in
>> mailman? Also, you probably mean mailman2, right? Have you taken a look
>> at mailman3 recently?
>
> Sure, just a few coming into mind: 
> 
> All those gpg related features we use, our spam removal tools, our special
> archiving hacks, we way we support blacklist through several lists, our
> second line of spamfiltering, crossassassin, the way we can do management on
> several lists and probably a lot more I forgot. It may take man years to do a
> migration (in fact we talked about that a few days ago in our internal IRC
> channel and this is more or less consense about the needed effort). 

Thanks for elaborating on that. At least some of them might be
interesting to submit as mailman3 feature requests as they probably
would be of help for other projects that use mailman3 as well.

I fully understand that you as the listmasters don't consider to switch
right now though.

> And I tested hyperkitty some time ago with our archive and it was
> unusable slow.

Interesting. I wonder how Fedora deals with this. I haven't used their
archives extensively, but from quick tests it appeared to be quite
responsive.

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Are Martin and Sam's platforms equivalent?

[Jose Miguel Parrella]

Thanks to all candidates for putting together your rebuttals. It's
always good to see lots of "if elected, I plan to work with other
candidates"

Martin, do you really see "lot of parallels" with Sam's platform?

Sam's platform is all about innovative people mechanics. I would much
rather prefer a DPL that works _less_, but having DPL and not just DDs
propose GRs and bring up issues to tech-ctte is interesting.

The question is _what_ would be up for discussion, given it's only a
year. Sam's platform is principled about the DPL not having an agenda
and OK with leaving some things as they are. In Sam's platform, the
difficulty of making changes in Debian is a "perception".

I don't think any platform in this vote can be reduced to "what's your
position re. Stapelberg" (it's been a great debate) and Martin's
platform is more about questioning status quo... so much so that he
acknowledges the platform is highly critical of Debian (in a good way IMHO)

I get that no one wants to run for DPL on a platform of "let's get rid
of the DPL" but Sam says he doesn't "see significant changes in
governance required" while Martin mentions "change" 9 times, including:
"I think Debian has reached a point where it's important to
fundamentally rethink how our community operates"

It's also clear there's a different approach to money and resources in
the two platforms. I like it that we see opportunities to work together
but I don't think these platforms are equivalent or differ only in the
personal style of the candidate.

Re: Debian presence on newer platforms

[Louis-Philippe Véronneau]

On 19-03-25 12 h 54, Ansgar wrote:
> a lot of communication in Debian happens over IRC.  However IRC is not
> as nice to use as newer alternatives, creating a barrier for newer
> contributors.

The way I see it, IRC is a barrier for new contributors, but there are
ways to make IRC more accessible:

1. Someone could host a ZNC bouncer on a .debian.net address and offer
accounts.

This seems like the easier solution, but the experience would still not
be up to par with something like Matrix.


2. Someone could host a weechat server on a .debian.net address and have
them be accessible through a Glowing Bear instance [1]

I've been using Glowing Bear for a while now and it's a really modern
experience. You can log in your IRC session directly in any browser,
notifications use the Notification Web API [2], there is sound of out of
the box, links to 'popular' websites can be rendered directly in the
chat window, etc.

A quick look in the Debian archive tells me most (if not all) of the
Glowing Bear deps are already packaged. I'm sure it wouldn't be that
hard to package it.

(now that I'm talking about it, maybe I should... 🤔)

Running weechat as a relay also means you can use Android apps like
weechat-android [3] to connect on mobile devices.

The main problem would be to host weechat sessions securely. One would
need to ensure good user isolation and look at securing weechat [4]

Anyway, my point is: IRC is working well for tons of people already.
Instead of trying to replace it, efforts could be made to make it easier
to use for all.

[1] https://github.com/glowing-bear/glowing-bear
[2] https://developer.mozilla.org/en-US/docs/Web/API/notification
[3] https://github.com/ubergeek42/weechat-android
[4] https://github.com/weechat/weechat/issues/928

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Re: Debian presence on newer platforms

[John Paul Adrian Glaubitz]

On 3/26/19 9:32 AM, Ansgar wrote:
> Both Mattermost and Rocket.chat are centralized services.  This means
> users have to create a Debian-specific account and might have to keep a
> Debian-specific instance of the client running (if the client doesn't
> support logging into multiple accounts at the same time).  That is a
> technical problem on phones.

I think you can also run your own Rocket Chat instance, at least we do
that at SUSE internally. But I have no idea whether Rocket Chat is free
software or not.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Debian presence on newer platforms

[Jonathan Carter]

On 2019/03/26 10:32, Ansgar wrote:
> What makes Matrix interesting for me is that it is federated and that
> there is a client ecosystem developing[1].
> 
> I might be interested in trying to get a Matrix homeserver for
> debian.org as an experimental service.  Need to investigate what this
> needs a bit further (and probably discuss the idea further on
> #debian-matrix:matrix.org for now).

Yeah, catching up with Matrix, it does look like a better solution
overall for Debian than either rocketchat or mattermost. The
integrations has also come a long way since I last tried out Matrix.

I now I'm new to debian-matrix, but will also he happy to help there, I
think getting a Debian test instance up would be fantastic, it looks
like there's some energy and momentum already, which is great!

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Debian presence on newer platforms

[Ansgar]

Paulo Henrique de Lima Santana writes:
> On 3/25/19 3:42 PM, Jonathan Carter wrote:
>> There's a massive amount of interesting things happening in the space.
>> Matrix is good, but Mattermost is certainly worth looking at as well.
>> 
>> https://mattermost.com/
[...]
> There is also Rocket.chat.
> https://rocket.chat/

Both Mattermost and Rocket.chat are centralized services.  This means
users have to create a Debian-specific account and might have to keep a
Debian-specific instance of the client running (if the client doesn't
support logging into multiple accounts at the same time).  That is a
technical problem on phones.

What makes Matrix interesting for me is that it is federated and that
there is a client ecosystem developing[1].

I might be interested in trying to get a Matrix homeserver for
debian.org as an experimental service.  Need to investigate what this
needs a bit further (and probably discuss the idea further on
#debian-matrix:matrix.org for now).

Ansgar

  [1] https://matrix.org/docs/projects/clients-matrix

Re: Debian presence on newer platforms

[Alexander Wirt]

On Tue, 26 Mar 2019, Jonas Meurer wrote:

> Hi Alex,
> 
> Alexander Wirt:
> >> While I agree that some "more modern" going way would be nice for lists,
> >> I don't think that is an easy task. Nor one where DPL can do much
> >> (unless listmasters need some resources that DPL can approve for such a
> >> change). Its up to the listmasters, though as far as i know, our current
> >> setup is anything but easily converted.
> >> In my experience as a former mailman admin and listadmin mailman is a
> no-go.
> > Getting our feature set even nearly into mailman is impossible, takes years
> > and will just get us an unmaintainable thing. I don't want to ever run a
> > bigger mailman setup again. 
> 
> Can you give an example, what from "our feature set" is missing in
> mailman? Also, you probably mean mailman2, right? Have you taken a look
> at mailman3 recently?
Sure, just a few coming into mind: 

All those gpg related features we use, our spam removal tools, our special
archiving hacks, we way we support blacklist through several lists, our
second line of spamfiltering, crossassassin, the way we can do management on
several lists and probably a lot more I forgot. It may take man years to do a
migration (in fact we talked about that a few days ago in our internal IRC
channel and this is more or less consense about the needed effort). 

And I tested hyperkitty some time ago with our archive and it was unusable
slow. 

Alex


signature.asc
Description: PGP signature

Re: Debian presence on newer platforms

[Jonathan Carter]

On 2019/03/26 04:09, Paulo Henrique de Lima Santana wrote:
> There is also Rocket.chat.
> https://rocket.chat/

Not really the place for me to rant about rocketchat, but I've used and
supported it before and wasn't impressed with its quality, it's one of
those node.js spaghetti cases and if presented with any kind of a choice
I'd rather not have to support it.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Debian presence on newer platforms

[Jonathan Carter]

On 2019/03/25 22:27, Laura Arjona Reina wrote:
>> More on Mastodon: https://en.wikipedia.org/wiki/Mastodon_(software)
>> Follow me on Mastodon! :) https://mastodon.xyz/@highvoltage
>>
> 
> Debian is already in Mastodon (which federates with GNU Social):
> 
> https://fosstodon.org/@debian
> 
> (it's a non-official account replicating what is posted in
> https://micronews.debian.org ).

Ah yes, I should've mentioned that, thanks!

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Debian presence on newer platforms

[Paulo Henrique de Lima Santana]

Hi,

On 3/25/19 3:42 PM, Jonathan Carter wrote:
> 
> There's a massive amount of interesting things happening in the space.
> Matrix is good, but Mattermost is certainly worth looking at as well.
> 
> https://mattermost.com/
> 
> It's a free software alternative to Slack, but it's not a mere copy,
> Mattermost is a superset of Slack in terms of features. Mattermost
> integrates with many different existing services. In particular, it also
> integrates really well with GitLab, to the point where GitLab ships a
> configuration of GitLab that contains an entire Mattermost installation.
> You can also enable commands for channels and users that let them
> contron GitLab right out of chat (or even add completely new commands
> that control stuff pretty much anywhere):
> 
> https://docs.gitlab.com/ee/user/project/integrations/mattermost_slash_commands.html

There is also Rocket.chat.
https://rocket.chat/

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Organizador da DebConf19 - Conferência Mundial de Desenvolvedores(as) Debian
Curitiba - 21 a 28 de julho de 2019
http://debconf19.debconf.org



signature.asc
Description: OpenPGP digital signature

Re: Debian presence on newer platforms

[Jonas Meurer]

Hi Alex,

Alexander Wirt:
>> While I agree that some "more modern" going way would be nice for lists,
>> I don't think that is an easy task. Nor one where DPL can do much
>> (unless listmasters need some resources that DPL can approve for such a
>> change). Its up to the listmasters, though as far as i know, our current
>> setup is anything but easily converted.
>> In my experience as a former mailman admin and listadmin mailman is a
no-go.
> Getting our feature set even nearly into mailman is impossible, takes years
> and will just get us an unmaintainable thing. I don't want to ever run a
> bigger mailman setup again. 

Can you give an example, what from "our feature set" is missing in
mailman? Also, you probably mean mailman2, right? Have you taken a look
at mailman3 recently?

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Re: Debian presence on newer platforms

[Alexander Wirt]

On Mon, 25 Mar 2019, Joerg Jaspert wrote:

> On 15352 March 1977, ans...@debian.org wrote:
> 
> > Do you think Debian should be more active to establish (official)
> > presence on newer platforms?
> 
> For those that are free, sure.
> 
> > In particular I also wonder if Debian should look at Matrix[1]: it is a
> > free and decentralized platform, and the UI (of Riot[2]) seems more
> > friendly than IRC clients.
> 
> I think that doesn't need a DPL. Anyone who wants can do it. And setup
> (to speeak in irc terms) channels for the users to get in. And then it
> can go the usual way of "the more people use it, the more important it
> becomes".
> 
> > Similar things also apply to mailing lists; there are solutions that
> > might be more accessible to some users (e.g. mailman3's web interface
> > which for example Fedora uses).  Though I can't say much about those as
> > I haven't used them so far.
> 
> While I agree that some "more modern" going way would be nice for lists,
> I don't think that is an easy task. Nor one where DPL can do much
> (unless listmasters need some resources that DPL can approve for such a
> change). Its up to the listmasters, though as far as i know, our current
> setup is anything but easily converted.
In my experience as a former mailman admin and listadmin mailman is a no-go.
Getting our feature set even nearly into mailman is impossible, takes years
and will just get us an unmaintainable thing. I don't want to ever run a
bigger mailman setup again. 

Just my 2 cent

Alex - Debian Listmaster

Re: Debian presence on newer platforms

[Joerg Jaspert]

On 15352 March 1977, ans...@debian.org wrote:


Do you think Debian should be more active to establish (official)
presence on newer platforms?


For those that are free, sure.


In particular I also wonder if Debian should look at Matrix[1]: it is a
free and decentralized platform, and the UI (of Riot[2]) seems more
friendly than IRC clients.


I think that doesn't need a DPL. Anyone who wants can do it. And setup
(to speeak in irc terms) channels for the users to get in. And then it
can go the usual way of "the more people use it, the more important it
becomes".


Similar things also apply to mailing lists; there are solutions that
might be more accessible to some users (e.g. mailman3's web interface
which for example Fedora uses).  Though I can't say much about those as
I haven't used them so far.


While I agree that some "more modern" going way would be nice for lists,
I don't think that is an easy task. Nor one where DPL can do much
(unless listmasters need some resources that DPL can approve for such a
change). Its up to the listmasters, though as far as i know, our current
setup is anything but easily converted.

--
bye, Joerg

Re: Debian presence on newer platforms

[Brian May]

Ansgar  writes:

> As a simple test I tried to join #debian over the bridge.  It doesn't
> work out of the box as #debian need registered nicks.
>
> Figuring out how to register a nickname on OFTC over the Matrix bridge
> and having to do that before joining a channel is a pretty high barrier.

This was a problem for the last linux.conf.au which uses Matrix
successfully.

For me the process made perfect since *after* I had done it.

Surely it wouldn't be too difficult to write some sort of tool to
automate the process?
-- 
Brian May 

Re: Debian presence on newer platforms

[Laura Arjona Reina]

Hi

El 25/3/19 a las 19:42, Jonathan Carter escribió:

> 
> Here are some of them many of you may already be familiar with.
> 
> 1. Mastodon
> 
> Mastodon is a twitter-like platform with a tweetdeck-like interface.
> 
> More on Mastodon: https://en.wikipedia.org/wiki/Mastodon_(software)
> Follow me on Mastodon! :) https://mastodon.xyz/@highvoltage
> 

Debian is already in Mastodon (which federates with GNU Social):

https://fosstodon.org/@debian

(it's a non-official account replicating what is posted in
https://micronews.debian.org ).

Kind regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Re: Debian presence on newer platforms

[Jonas Smedegaard]

Quoting Jonathan Carter (2019-03-25 20:20:11)
> Hi Martin
> 
> On 2019/03/25 21:16, martin f krafft wrote:
> > And while surely not representative: 11 out of 12 teams I personally 
> > know who looked at Matrix and Mattermost a couple of years back and 
> > went with Mattermost then are now migrating to Matrix, which has the 
> > following benefits:

[...]

> >  - real-time voice/video conferencing

[...]

> (I didn't know it had real-time voice/video conferencing... that's 
> also pretty cool, might be nice for DebConf remote attendees if it 
> becomes more of a formal part of Debian)

Matrix doesn't really do realtime A/V conferencing.  The Matrix client 
"Riot Web" (and probably "Riot Desktop" as well, but not "Riot Android" 
or "Riot iOS" afaik) - offers a plugin to load Jitsi Meet in rooms. This 
means constraints like concurrent users and bandwidth load and 
reliability are same as when using https://meet.jit.si/ - benefit is 
convenience of all Riot users in a Matrix room being auto-registered for 
the Jitsi Meet room as well.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian presence on newer platforms

[martin f krafft]

Quoting "John Paul Adrian Glaubitz", who wrote on 2019-03-25 at 20:23 Uhr +0100:
Does Matrix allow a client to be idling on some server to act as a 
bouncer?


There's matrix-ircd, which is in theory a client that acts as an 
IRCd. I write "in theory" because it's abandonware.


But otherwise with Matrix you don't need bouncers. Your homeserver 
is your bouncer. You can log in there with many devices, and they'll 
all sync whenever online.


Quoting "Ansgar", who wrote on 2019-03-25 at 20:26 Uhr +0100:
As a simple test I tried to join #debian over the bridge.  It 
doesn't work out of the box as #debian need registered nicks.


This is something that #debian can work around. We had this problem 
with #linux.conf.au. See last FAQ of the page I linked. 
https://github.com/matrix-org/matrix-appservice-irc/wiki/End-user-FAQ


I'm not so confident about bridges though; they are far from 
user-friendly.  Native rooms give a better experience.


This can be fixed.

Also, we should have this discussion on #debian-matrix, or another 
mailing list. Sorry for bringing my evangelism to -vote.


--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

"it isn't pollution that's harming the environment.
it's the impurities in our air and water that are doing it."
 - dan quayle


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Debian presence on newer platforms

[Jonathan Carter]

Hi Martin

On 2019/03/25 21:16, martin f krafft wrote:
> Quoting "Jonathan Carter", who wrote on 2019-03-25 at 20:42 Uhr +0200:
>> It's a free software alternative to Slack, but it's not a mere copy,
>> Mattermost is a superset of Slack in terms of features. Mattermost
>> integrates with many different existing services. In particular, it
>> also integrates really well with GitLab, […]
> 
> Matrix bots also provide integration with GitHub and GitLab in similar
> ways. Matrix also has bridging to Mattermost.
> 
> And while surely not representative: 11 out of 12 teams I personally
> know who looked at Matrix and Mattermost a couple of years back and went
> with Mattermost then are now migrating to Matrix, which has the
> following benefits:
> 
>  - federation
>  - multi-device end-to-end encryption (though obviously not in   
> bridged rooms)
>  - real-time voice/video conferencing
>  - widgets
> 
> Yes, I am a huge Matrix evangelist. And why wouldn't I?

Cool, I'm not particularly married to mattermost, but it's what I know
and it works great for me, I actually neglected to say in my previous
mail that personally I would consider Matrix as much as Mattermost...
although I've already contributed in swaying me more to the Matrix side :)

(I didn't know it had real-time voice/video conferencing... that's also
pretty cool, might be nice for DebConf remote attendees if it becomes
more of a formal part of Debian)

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Debian presence on newer platforms

[Ansgar]

martin f krafft writes:
> Quoting "Sam Hartman", who wrote on 2019-03-25 at 13:09 Uhr -0400:
>> I've been looking at Matrix too and it seems kind of nice. There
>> already seem to be a number of channels related to Debian (or
>> gatewayed from oftc) on Matrix.
>
> One benefit of Matrix is that there are a lot of bridges, and the IRC
> bridge is very stable. In fact, any OFTC room is already available on
> Matrix through implicit bridging. All you have to do is join the room
> #_oftc_#channel:matrix.org and you'll be joined bidirectionally to the
> corresponding IRC channel. Also works for other networks. Freenode is
> the one exception in that it doesn't have a leading _.

As a simple test I tried to join #debian over the bridge.  It doesn't
work out of the box as #debian need registered nicks.

Figuring out how to register a nickname on OFTC over the Matrix bridge
and having to do that before joining a channel is a pretty high barrier.

> I've been wanting to suggest Matrix for Debian since DC15, but I
> haven't because of the above, which already allows everyone to use
> Matrix who wants to, while avoiding the debate that will otherwise
> occupy us for years.
>
> But yeah, Matrix is the future of chat/rich-media exchange. KDE has
> recently migrated entirely. I don't expect that Debian ever will,
> which is why the bridging concept is just beautiful.

Yes, I heard about KDE, the French government and ${work} looking at
Matrix and so ended up looking at it.  The first impression was quite
good :-)

I'm not so confident about bridges though; they are far from
user-friendly.  Native rooms give a better experience.

Ansgar

Re: Debian presence on newer platforms

[John Paul Adrian Glaubitz]

On 3/25/19 8:16 PM, martin f krafft wrote:
> Yes, I am a huge Matrix evangelist. And why wouldn't I?

Does Matrix allow a client to be idling on some server to act as a bouncer?

I usually run Weechat on a server and never log off.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Debian presence on newer platforms

[martin f krafft]

Quoting "Jonathan Carter", who wrote on 2019-03-25 at 20:42 Uhr +0200:
It's a free software alternative to Slack, but it's not a mere copy, 
Mattermost is a superset of Slack in terms of features. Mattermost 
integrates with many different existing services. In particular, it also 
integrates really well with GitLab, […]


Matrix bots also provide integration with GitHub and GitLab in 
similar ways. Matrix also has bridging to Mattermost.


And while surely not representative: 11 out of 12 teams I personally 
know who looked at Matrix and Mattermost a couple of years back and 
went with Mattermost then are now migrating to Matrix, which has the 
following benefits:


 - federation
 - multi-device end-to-end encryption (though obviously not in 
   bridged rooms)

 - real-time voice/video conferencing
 - widgets

Yes, I am a huge Matrix evangelist. And why wouldn't I?

--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

"it is the mark of an educated mind
to be able to entertain a thought
without accepting it."
 -- aristoteles


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Debian presence on newer platforms

[martin f krafft]

Quoting "Sam Hartman", who wrote on 2019-03-25 at 13:09 Uhr -0400:
I've been looking at Matrix too and it seems kind of nice. 
There already seem to be a number of channels related to Debian (or 
gatewayed from oftc) on Matrix.


One benefit of Matrix is that there are a lot of bridges, and the 
IRC bridge is very stable. In fact, any OFTC room is already 
available on Matrix through implicit bridging. All you have to do is 
join the room #_oftc_#channel:matrix.org and you'll be joined 
bidirectionally to the corresponding IRC channel. Also works for 
other networks. Freenode is the one exception in that it doesn't 
have a leading _.


See 
https://github.com/matrix-org/matrix-appservice-irc/wiki/End-user-FAQ

for more info, including how to register and take control over the
nickname used.

I've been wanting to suggest Matrix for Debian since DC15, but I 
haven't because of the above, which already allows everyone to use 
Matrix who wants to, while avoiding the debate that will otherwise 
occupy us for years.


But yeah, Matrix is the future of chat/rich-media exchange. KDE has 
recently migrated entirely. I don't expect that Debian ever will, 
which is why the bridging concept is just beautiful.


--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

"a cigarette is the perfect type of pleasure.
it is exquisite, and it leaves one unsatisfied."
 -- oscar wilde


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Debian presence on newer platforms

[Jonathan Carter]

Hi Ansgar

On 2019/03/25 18:54, Ansgar wrote:
> a lot of communication in Debian happens over IRC.  However IRC is not
> as nice to use as newer alternatives, creating a barrier for newer
> contributors.
> 
> Do you think Debian should be more active to establish (official)
> presence on newer platforms?
> 
> A disadvantage is splitting the community, but I'm not sure keeping IRC
> forever as the world moves on is a good option either...
> 
> In particular I also wonder if Debian should look at Matrix[1]: it is a
> free and decentralized platform, and the UI (of Riot[2]) seems more
> friendly than IRC clients.
> 
> (I haven't used Matrix much myself yet... Just played a bit as ${work}
> might use it and they have set up a test installation.)

As it happens, I've put a lot of thought in to this and considered
including it in my platform too, but my platform was already a bit
loaded (both in how long it is and the scope of the role I was laying
out), so I decided to cut it for a second term if that would ever work out.

Yeah yeah, long post coming...
(https://www.enricozini.org/blog/2019/debian/debian-vote-statistics/)

There's a massive amount of interesting things happening in the space.
Matrix is good, but Mattermost is certainly worth looking at as well.

https://mattermost.com/

It's a free software alternative to Slack, but it's not a mere copy,
Mattermost is a superset of Slack in terms of features. Mattermost
integrates with many different existing services. In particular, it also
integrates really well with GitLab, to the point where GitLab ships a
configuration of GitLab that contains an entire Mattermost installation.
You can also enable commands for channels and users that let them
contron GitLab right out of chat (or even add completely new commands
that control stuff pretty much anywhere):

https://docs.gitlab.com/ee/user/project/integrations/mattermost_slash_commands.html

I'm not sure how popular the idea will be to replace IRC with mattermost
completely, I consider it firmly in the needs-more-discussion category,
but I do think it's worth while considering for a lot of reasons, but
basically:

1. Spam. IRC networks aren't that great with dealing with large spam
attacks, Mattermost makes this easier to deal with.

2. IRC Gateway. You don't have to throw away your perfectly good IRC
client like irssi or weechat, they can connect to mattermost via its IRC
gateway.

3. Control. At the beginning of events like DebConf, we always have a
day or two where oftc kicks people off because too many people connect
from the same IP, for this and other reasons Mattermost might be better.

4. New users. I really want to get many new contributors in to debian,
and the average person finds Mattermost (and all its alternatives) *so*
much less intimidating than an IRC client. On top of that, Mattermost
have great phone apps so it's easier for the average person to stay
connected to chats when mobile.

But there's more, there's a lot of exciting things happening in the free
software communications world. There's the whole concept of the
fediverse that I think we should embrace within Debian. In a nutshell,
it allows you to connect different free social network services together
so that you can interact with other networks from yours, even if they're
different software.

Here are some of them many of you may already be familiar with.

1. Mastodon

Mastodon is a twitter-like platform with a tweetdeck-like interface.

More on Mastodon: https://en.wikipedia.org/wiki/Mastodon_(software)
Follow me on Mastodon! :) https://mastodon.xyz/@highvoltage

2. Pixelfed

Pixelfed is a project to recreate Instagram as a free software platform.

Pixelfed website: https://pixelfed.org/
Follow me on Pixelfed! :) https://pixelfed.social/highvoltage

Rhonda has performed a test installation of Pixelfed on Debian, it seems
that it needs minimal changes to run properly on Debian (maybe she can
elaborate if she's reading).

3. Peertube

Peertube is great, it's a decentralised video hosting service.

Website: https://en.wikipedia.org/wiki/PeerTube

Peertube is a game changer. YouTube basically currently has a monopoly
on video hosting on the Internet due to all the eyeballs it's
attracting, but Peertube may be the answer to that, since it allows
users to self-host, but users can discover videos across instances.

I've been looking into various video hosting solutions for the DebConf
video team, because we want to offer users something nicer than just an
html listing of files, and out of the bunch of solutions I've looked at,
Peertube by far makes the most sense.

Not part of my DPL campaign at all, but if we get a Peertube instance
for Debian, I want to encourage our users to make videos about Debian
and share it there, similar to videos that I made for Debian Package of
the Day etc.

I woul

Re: Debian presence on newer platforms

[Sam Hartman]

>>>>> "Ansgar" == Ansgar   writes:

Ansgar> Hi, a lot of communication in Debian happens over IRC.
Ansgar> However IRC is not as nice to use as newer alternatives,
Ansgar> creating a barrier for newer contributors.

Ansgar> Do you think Debian should be more active to establish
Ansgar> (official) presence on newer platforms?

I've been looking at Matrix too and it seems kind of nice.
There already seem to be a number of channels related to Debian (or
gatewayed from oftc) on Matrix.


I think that we're still in the initial explorations stage of this work.
Interested people should explore technologies and put together something
concrete.

This isn't something I would drive as DPL myself, but it's something
where I'd be happy to work with someone who did want to drive it.
Is this something interesting enough to you that you'd like to drive or
be involved in such an effort?

Debian presence on newer platforms

[Ansgar]

Hi,

a lot of communication in Debian happens over IRC.  However IRC is not
as nice to use as newer alternatives, creating a barrier for newer
contributors.

Do you think Debian should be more active to establish (official)
presence on newer platforms?

A disadvantage is splitting the community, but I'm not sure keeping IRC
forever as the world moves on is a good option either...

In particular I also wonder if Debian should look at Matrix[1]: it is a
free and decentralized platform, and the UI (of Riot[2]) seems more
friendly than IRC clients.

(I haven't used Matrix much myself yet... Just played a bit as ${work}
might use it and they have set up a test installation.)

Similar things also apply to mailing lists; there are solutions that
might be more accessible to some users (e.g. mailman3's web interface
which for example Fedora uses).  Though I can't say much about those as
I haven't used them so far.

Ansgar

  [1] https://matrix.org
  [2] https://riot.im

Re: A few high level questions for all platforms

[Jonathan Carter]

Hi JMP

On 2019/03/20 03:43, Jose Miguel Parrella wrote:
> * As a DPL, what steps would you take (if any) towards reducing the
> workload and breadth of activities the DPL is expected to engage in?

Chris's "bits from the dpl" were more frequent and comprehensive than
previous DPLs, and the good communication is universally well received.
I think it would help if such an update mail also contained a 'request
for help' section when appropriate.

It's also good to know how the DPL is actually doing, although that is
tough to communicate properly. Chris mentioned in a few bits updates
that he spent yet another month spending a large amount of time on
harassment issues. I think it's a bit sad that as a project, we couldn't
do more to support him in that, at the same time I don't have all the
answers on how to achieve that either.

I'm keen on the idea of using bugs for the DPL, it could be filed in
different categories in a dpl virtual package:

1. dpl-rfh

Request for help filed by the DPL, this could be for help on very tiny
specific issues or for more ongoing work.

2. dpl-role

Like anything, the role and definition of the DPL isn't perfect, it
would be good if members, and especially the DPL themselves, can file
bugs against the dpl role. It might not necessarily be something that
can easily be fixed, for example "I spend way too much time working on
harassment issues" and problems like those could be food for thought for
future DPLs who are considering their platform.

3. dpl-advice

Perhaps a call for advice from experts when a DPL needs more information
on a topic, or perhaps request a type of a poll if the DPL wants to
gauge an opinion across the project.

And there could be more, or they could be different than the above
altogether, but the idea is that DPL problems can be easily filed and
discovered, which may make it easier for people to step up and help. It
might also be easier for the DPL (or others) to address problems with
the DPL role.

I just noticed again teh "Help needed" section on
https://wiki.debian.org/Teams/DPL - it does seem like that section has
gone a bit stale.

So, I suppose I could say that my biggest weapon in fixing load and
breadth of DPL work would be to make it easier to address issues and
pull our resources together to try and solve it.

On a personal note, dealing with harassment-kind of issues sound
extremely boring and draining and I hope that whoever becomes DPL will
have to deal with less of those than our last DPL did.

> * Would you pursue delegating functions such as representing Debian (as
> a spokesperson or otherwise), resolving differences in the project or
> signing authority for expenditures, etc.?

I would want to have more experience with day to day DPL tasks before
commenting on that.

However, I find the idea of a speakers team really interesting. There
are often interesting events happening all over the world at the same
time, and the DPL can only be one place at a time. It might be great if
a team of debian speakers work together on a set of standard slides that
talk about the Debian projects and different topics that are interesting
to the project as a whole at that point. This might enable the project
to do more CfPs and do better at spreading the word of what we're about
and what we're working on.

> * Do you anticipate anything in your platform would require an amendment
> to the constitution or a foundation document, or to otherwise call a GR
> within the next year? If so, what is it and how would you debate it?

Not at all, everything I envision fit well within the existing
frameworks that exist within Debian.

> * Do you believe in the concept of a DPL team? If so, do you plan to
> implement such a concept in the next year? If so, how?

I think it may end up being multiple teams. I think project members
should also feel welcome to mail the DPL at any time and say "hey can I
help with problem #xx?" and just do a single contribution and move
on. In some ways I think the majority of our active community can have
their part in being a DPL helper. Probably not something that will
happen overnight, but it can be a long-term cultural change.

> * Do you believe Debian is actively pursuing a vision for the next 5
> years? If so, what is it? If not, do you think it should? And if so, how
> do you expect to work with all the decision-making bodies?
I don't believe we are actively pursuing a version for the next 5 years,
and I don't think it's a problem either.

I think 5 years may be an odd fit for us too, our collective rhythms
tend to be synced to Debian releases, so it might be better to sort
collective goals in perious of the next 2, 4 and 6 years to match short,
medium and long term goals with releases.

Mehdi had some great ideas to build a roadmap for Debian, but I think it
got misunderstood by some people and it probably didn't get as much
traction as it deserved.
(https://alioth-lists-archive.debian.net/pipermail/debian-roadmap/Week-of-Mon-2017

Re: A few high level questions for all platforms

[Jonathan Carter]

Hi Martin

On 2019/03/20 19:38, Martin Michlmayr wrote:
> * Jonathan Carter  [2019-03-20 18:57]:
>>> Not right now, although my ideas of spending Debian's money might
>>> trigger some GRs.
> 
> [ I should point that your quote removes a smiley from my sentence and
> that smiley was significant. ]

Ah, I can assure you that that was not on purpose, Thunderbird converted
that to a fancy smiley which it didn't seem to include when selecting
text to reply to (I have now disabled that feature to play it safe for
the future).



Thank you, the rest of your answer sufficiently addressed my question.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: A few high level questions for all platforms

[Martin Michlmayr]

* Jonathan Carter  [2019-03-20 18:57]:
> > Not right now, although my ideas of spending Debian's money might
> > trigger some GRs.

[ I should point that your quote removes a smiley from my sentence and
that smiley was significant. ]

> Your platform doesn't provide much details on that, although you do
> mention grants and paid-for Debian work.

Yes, external grants and external paid work.  None of that is
controversial.

I think we could also think about using Debian's money for grants, but
obviously we'd have to come up with a process and criteria, etc.

> Do you mind expanding on your spending ideas, and how they may be
> controversial?

I probably shouldn't have written the sentence I wrote in jest without
more background or explanation.

For the record, I am not planning on spending money on controversial
things.

However, (as I hinted in my platform) I think it's time to start
asking some serious questions.  For example, why is the DPL not a paid
position?  Would it make sense to pay for release management?

If you step outside our Debian bubble and talk to people, they believe
we're absolutely bonkers that the DPL role is not paid.  All of these
recent questions of "how many hours can you devote to being DPL" show
me what I keep repeating all the time: being DPL is a serious commitment.
If you look around at similar projects, you'll see they generally have
some kind of paid leadership positions.

But yeah, if we decided to go for something like a board plus paid
Executive Director, that may require changes in our documents (which
was the original questions).

(I could write more but I think this isn't the right place or time.)

-- 
Martin Michlmayr
https://www.cyrius.com/

Re: A few high level questions for all platforms

[Jonathan Carter]

Hi Martin

On 2019/03/20 17:11, Martin Michlmayr wrote:
> Not right now, although my ideas of spending Debian's money might
> trigger some GRs. 

Your platform doesn't provide much details on that, although you do
mention grants and paid-for Debian work.

Do you mind expanding on your spending ideas, and how they may be
controversial?

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: A few high level questions for all platforms

[Sam Hartman]

> "Jose" == Jose Miguel Parrella  writes:

Jose> If DPL Team/Committee worked, and delegations start to feel
Jose> more permanent (delegated functions make sense, terms are
Jose> long) then why wouldn't a few of those delegates become Debian
Jose> Leadership Team members alongside DPL, tech-ctte chair and
Jose> Secretary? Why wouldn't the "Debian Spokesperson" role, a
Jose> formal one that could get invited by any event organizer like
Jose> a DPL would, be a Constitution-regulated one?

I would be against this change.  The current system gives the DPL a lot
of flexibility.  Today you're seeing that different candidates would
focus on different things and organize the people who helped them
differently.

Sticking these roles into the constitution removes that flexibility with
very little gain.

I think flexibility is valuable.


signature.asc
Description: PGP signature

Re: A few high level questions for all platforms

[Martin Michlmayr]

* Jose Miguel Parrella  [2019-03-19 18:43]:
> * As a DPL, what steps would you take (if any) towards reducing the
> workload and breadth of activities the DPL is expected to engage in?

I intend to make use of the delegations process (maybe I'll even
create some new roles) and if elected I'd like to work closely with
the other people who ran for DPL.

More generally, in projects and boards I tend to get involved in, I
often find myself doing the things that nobody else does.  I think the
DPL role can be like that sometimes, too.

I *do* believe it's important for the DPL to look at the big picture
and see where connections can be made or where things are not going
well.  However, that doesn't mean that the DPL has to resolve all of
these problems personally.

Everyone who has worked with me knows that I'm not afraid to ask for
little favours. ;-)  As I mentioned in my platform, asking the right
person directly can be very effective.

I started working on a list of tasks that I'd like to see done.  Once
I have a list, the next step is to identify *who* can do those tasks.
I suspect a lot of them don't actually have to be done by the DPL.

> * Would you pursue delegating functions such as representing Debian (as
> a spokesperson or otherwise), resolving differences in the project or
> signing authority for expenditures, etc.?

We've had a Debian speakers list for many years, although I don't
think it's well known or maintained: https://www.debian.org/events/speakers/
I'd definitely encourage other people to represent Debian, and
sometimes ask people who attend conferences to be more visible about
their affiliation (many of us wear many different hats).  At the same
time, as mentioned in my platform, there are cases where they want the
DPL.  (I've been invited as a speaker to at least one conference where
the current DPL was not available and I was their next "best" choice
because I was at least a former DPL ;)

Resolving differences: it depends on the differences.  If it's a
technical difference, you might be able to refer it to the TC.  If it
involves violations of the CoC, it might be something for the
anti-harassment team.  I've been wondering if there should be a team
to deal with more general social differences.  I'm not sure right now,
to be honest, but it's something I will think about some more. (In my
experience, this is the most frustrating part of being DPL and so
anything to make that better is obviously a good idea.).

Expenditures: I don't mind doing this anyway and it gives a good
overview of what's going on in the project.  However, I'd like to be
less reactive and more proactive, e.g. encouraging people to go to
conferences, identifying where hardware might be useful, etc. (both of
which can also be done by delegates, though).

> * Do you anticipate anything in your platform would require an amendment
> to the constitution or a foundation document, or to otherwise call a GR
> within the next year? If so, what is it and how would you debate it?

Not right now, although my ideas of spending Debian's money might
trigger some GRs. :-P

Seriously though, I think the project needs some fundamental changes.
It's possible we may require changes to some documents eventually, but
we're not there -- first of all we need some honest conversations
about who/what we want to be. (See the vision question later)

> * Do you believe in the concept of a DPL team? If so, do you plan to
> implement such a concept in the next year? If so, how?

There have been various suggestions to replace the DPL with a team or
a board.  So far, I have been a bit sceptical of the merits, but I've
started to see some merits in a board plus an executive director /
DPL.  This is another area I intend to think about more in order to
form a clearer opinion.

I currently don't plan to change anything about the DPL structure, but
this may well change over the course of the year.

While I'm not planning to form a DPL team, I intend to work closely
with others (maybe as informal DPL helpers) and see where delegation
is possible (see the first question).  If elected, I'd certainly plan
to work closely with some of the other DPL candidates.

> * Do you believe Debian is actively pursuing a vision for the next 5
> years? If so, what is it? If not, do you think it should? And if so, how
> do you expect to work with all the decision-making bodies?

We don't have a vision or 5 year plan apart from our overall goal to
produce the best free OS out there.  I believe that it would help to
take a step back and to look at the big picture.  Right now we're in
this mode where we keep packages in Debian up-to-date and get out a
release every few years, but I think we need to take more time to
reflect to ask where we are and where we want to be.  Sometimes you're
blind because you're too involved -- you need to step back and look at
it from the outside.

So I think we should reflect and create a vision.  This isn't
necessarily a *technical* vision (e.g

Re: A few high level questions for all platforms

[Joerg Jaspert]

On 15347 March 1977, Michael Meskes wrote:


But yes, depending on/with some events/companies, speaking as a DPL
will be perceived much more strongly. Any "normal" DD won't be heard.
If that is the case, and if its sufficient, a delegation can be good.



Are you saying you would delegate the role of making-presentations-as-
DPL? Or are you planning to do it yourself? Having met Chris all over
the world I do think DPL speaking engagements do involve a bit of
traveling and from my own personal experience, doing that with small
children at home is not ideal to say the least.


I'm saying that sometimes People want to hear the DPL. I don't think
that is something one can delegate, you either are, or are not, the DPL.

And yes, in my original sentence a *not* is missing, it should have read
"If that is NOT the case, ..., a delegation can be good".

Now, me and travelling: I don't think I will be travelling as much as
others do/have done. But I am not planning to just stay home. I am
prepared (and my family too) to attend events as DPL.

--
bye, Joerg

Re: A few high level questions for all platforms

[Jose Miguel Parrella]

Thanks for taking the time to go through this and other people's
questions, Sam.

On 3/20/19 3:04 AM, Sam Hartman wrote:
> I've been kind of confused by all the discussions of changing our
> governance to permit this.  The constitution is quite flexible in this
> area already.
> There are a couple of corner cases that could be discussed after the
> election.  As an example as was pointed out earlier here, Debian France
> does not currently permit the DPL to delegate expenditure approval
> authority.

I can't speak for everyone that has raised questions about this, but my
question hasn't been about the "can it be done", but about the "can it
be made clear and permanent" - as an incentive for the future.

If DPL Team/Committee worked, and delegations start to feel more
permanent (delegated functions make sense, terms are long) then why
wouldn't a few of those delegates become Debian Leadership Team members
alongside DPL, tech-ctte chair and Secretary? Why wouldn't the "Debian
Spokesperson" role, a formal one that could get invited by any event
organizer like a DPL would, be a Constitution-regulated one? Why
wouldn't the Constitution say the DPL Team/Committee makes decision by
consensus, or via Standard Resolution Procedure.

Re: A few high level questions for all platforms

[Michael Meskes]

> But yes, depending on/with some events/companies, speaking as a DPL
> will
> be perceived much more strongly. Any "normal" DD won't be heard. If
> that
> is the case, and if its sufficient, a delegation can be good.
> 
Are you saying you would delegate the role of making-presentations-as-
DPL? Or are you planning to do it yourself? Having met Chris all over
the world I do think DPL speaking engagements do involve a bit of
traveling and from my own personal experience, doing that with small
children at home is not ideal to say the least.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: A few high level questions for all platforms

[Sam Hartman]

>>>>> "Jose" == Jose Miguel Parrella  writes:

A lot of this is in my platform but I'm answering here for clarity.

Jose> * As a DPL, what steps would you take (if any) towards
Jose> reducing the workload and breadth of activities the DPL is
Jose> expected to engage in?

I think every DPL will find their own focus and tends to delegate work
where they can clearly identify boundaries, where the work is plentiful
enough to make delegation valuable, and where there are good choices for
delegates.

In my platform I said that unless some significant problem comes up,
focusing on finances/treasury would not be my focus.  I'll exercise due
diligence and make sure expenditures get approved, but won't focus a lot
of energy improving in that area.

I look forward to traveling to conferences, but suspect I won't spend as
much time doing that as some who have held the DPL office.


Jose> * Would you pursue delegating functions such as representing
Jose> Debian (as a spokesperson or otherwise), resolving differences
Jose> in the project or signing authority for expenditures, etc.?

Yes.
I am personally interested in working on resolving differences, but
that's big enough that I hope to have others helping me.
I talk about that in my platform.

I am definitely open to delegating representing Debian at events.
I think the DPL should be involved in that, but I think the DPL can
empower others to do this too.

I'm very open to delegating financial matters.  The DPL needs to be
aware of what is going on enough to be accountable, but that need not
take up much time.
Bdale at least said that the entire financial task was not a huge time
sink, so I'll need to see how much time is spent on this.
Delegation is only useful if it saves time or gets things done better.


Jose> * Do you anticipate anything in your platform would require an
Jose> amendment to the constitution or a foundation document, or to
Jose> otherwise call a GR within the next year? If so, what is it
Jose> and how would you debate it?

I think that calling a GR can be a valuable tool to actually make a
decision once all the positions are known and it is clear that we don't
have consensus.
I think that by compiling the options the DPL can make that process less
confrontational.

I could see that happening as we discuss some of the pain points and
friction in our processes, and that's a tool I'd be happy to use.

I am not currently seeing any need for constitutional or foundation
document changes.

Jose> * Do you believe in the concept of a DPL team? If so, do you
Jose> plan to implement such a concept in the next year? If so, how?

Yes.
I plan to ask people to help me and then empower them to do so.

One thing I'm doing is looking at the other candidate platforms and
thinking about how aligned their ideas are and whether I could get some
of the other candidates to drive areas where they excel forward if I'm
elected.

At least initially I'd be more likely to delegate (possibly shared)
enumerated responsibilities than to say have a DPL committee.
For the most part I think the DPL has the flexibility to do either, but
I think you need to have a good working relationship with a group before
that sort of committee delegation would be a positive experience.

I've been kind of confused by all the discussions of changing our
governance to permit this.  The constitution is quite flexible in this
area already.
There are a couple of corner cases that could be discussed after the
election.  As an example as was pointed out earlier here, Debian France
does not currently permit the DPL to delegate expenditure approval
authority.

Similarly, I might imagine within a DPL team, we might want to be more
flexible about allowing the DPL to review decisions than with a normal
delegation.  I can think of ways to phrase a delegation to permit that,
but people who wanted to be really strict about the constitution might
object.

I personally think no changes are needed.  If any changes are needed
they are quite small.

The big challenge is finding DPL candidates who can construct a team
that works for them.
I think I'm good at building teams.

Jose> * Do you believe Debian is actively pursuing a vision for the
Jose> next 5 years? If so, what is it? If not, do you think it
Jose> should? And if so, how do you expect to work with all the
Jose> decision-making bodies?

I don't think Debian should have a single vision.
I think we should empower people to pursue mini-visions of how they
would change the free software world.  Reproducible Builds is one such
mini-vision.

I agree with tbm that we should make this sort of visionary work easier.
I also agree that money can help this sort of driven work.

One area where I think we can improve is to remind teams within Debian
of the

Re: A few high level questions for all platforms

[Joerg Jaspert]

On 15347 March 1977, Jose Miguel Parrella wrote:


* As a DPL, what steps would you take (if any) towards reducing the
workload and breadth of activities the DPL is expected to engage in?


Depending on the actual activity and there being any volunteers, it may
get delegated.


* Would you pursue delegating functions such as representing Debian (as
a spokesperson or otherwise), resolving differences in the project or
signing authority for expenditures, etc.?


Now that highly depends on the function. First off, any DD can
"represent" Debian, in some ways. That doesn't need a DPL hat. Sure, the
hat makes it somewhat more "official", but same as any DD, the DPL can
not just go there and "reveal" the new, big, until-now-secret direction
of Debian (or other crazy stuff). Something like that needs the project
to decide on it with the usual way.

But yes, depending on/with some events/companies, speaking as a DPL will
be perceived much more strongly. Any "normal" DD won't be heard. If that
is the case, and if its sufficient, a delegation can be good.

Resolving differences: I think we have ways to do that with technical
differences, so I assume you think of social ones. Being a participant
in the current two bigger such issues, I do think that we can still
evolve a lot there, and a delegation *may* be part of it. But there are
numerous people in the various involved teams already thinking about it,
I don't want to take an early step here and "announce" it should go this
or that way.

Signing for expenditure: I think it should stay the DPLs job to make
large decisions about Debian assets. I also think that not each little
cent needs to be approved by the DPL. Say, something like "DSA can spend
anything below $amount within $timeframe on hardware" (eg. to replace
broken disks) is a good thing to do and can easily be extended to other
such predictable spendings.


* Do you anticipate anything in your platform would require an amendment
to the constitution or a foundation document, or to otherwise call a GR
within the next year? If so, what is it and how would you debate it?


I do not expect a change to a foundational document, but depending on
how it goes, two or three points in it could end up as a GR to have
project backup.


* Do you believe in the concept of a DPL team? If so, do you plan to
implement such a concept in the next year? If so, how?


I do not believe in a DPL team as a predefined thing that MUST happen
and has THOSE members. So no, I do not intend to implement such a concept.
OTOH, as I wrote, I'm not afraid to ask for help and there may be stuff
that can be given to others. If that's the case I would see if there is
a volunteer for it.


* Do you believe Debian is actively pursuing a vision for the next 5
years? If so, what is it? If not, do you think it should? And if so, how
do you expect to work with all the decision-making bodies?


Oi, those are loads of ? here.

I do not think Debian as a whole has a common vision for the next 5
years ecept for "Enhance it and release the next version". Which is a
good vision in and of itself, but (I guess) probably not what you ask
for. I assume a vision for your question would be more like "We need to
become the #1 container provider for all the newfangled technology". Or
"We must integrate all and everything from any derivative and offer it
within Debian directly".

I do not think that there is such a common vision all over Debian.
Instead I think there are multiple areas / groups of people that do have
their own vision where to go with Debian. Like there are the people
working on the cloud stuff, those with Debian med, people who want to
see Debian as the one place for all of nodejs/rust/go/... with all that
entails.

And I think it is a good thing that we have so many different areas.
Molding them all together based on our common grounds makes us stronger
as a whole.

And the way the DPL can work with any decision-making body is by talking.
By organizing meetings, possibly joint ones for multiple teams. And by
finding out what they need and if applicable, get that to them.

--
bye, Joerg

A few high level questions for all platforms

[Jose Miguel Parrella]

Thank you to all of the candidates for your nominations [0] and for
sharing your early vision for the next year (and looking forward to Simon's)

I would like to formulate a few questions not aimed to any platform in
particular. I expect some candidates will point me to their platform
page and others will prefer not comment. Either way, I hope this can
help open a healthy debate.

* As a DPL, what steps would you take (if any) towards reducing the
workload and breadth of activities the DPL is expected to engage in?

* Would you pursue delegating functions such as representing Debian (as
a spokesperson or otherwise), resolving differences in the project or
signing authority for expenditures, etc.?

* Do you anticipate anything in your platform would require an amendment
to the constitution or a foundation document, or to otherwise call a GR
within the next year? If so, what is it and how would you debate it?

* Do you believe in the concept of a DPL team? If so, do you plan to
implement such a concept in the next year? If so, how?

* Do you believe Debian is actively pursuing a vision for the next 5
years? If so, what is it? If not, do you think it should? And if so, how
do you expect to work with all the decision-making bodies?

Respectfully,
JMP

[0] https://www.debian.org/vote/2019/vote_001



signature.asc
Description: OpenPGP digital signature

Platforms.

[Debian Project Secretary - Kurt Roeckx]

Hi Wouter,
Hi Charles,

I'm still waiting for your platforms.  I would have liked to
publish them last Friday, and already postponed it to today.

If I don't receive them by tomorrow around this hour I will
start to publish the others that I did receive.

I'm also going to postpone the rebuttal and would like to
publish that at the 22nd.


Kurt Roeckx
Debian Project Secretary



signature.asc
Description: Digital signature

Debian Project Leader Elections 2007: Availability of platforms

[Debian Project Secretary]

Hi,

The platforms for andidates are now available, and linked in
 from the main vote page at: http://www.debian.org/vote/2007/vote_001

The plan is for the rebuttals to be posted on march 5th, to
 leave plenty of time for people to read about the candidates before
 the DPL candidate debate happens.

So, candidates, please send in your rebuttal text to
 [EMAIL PROTECTED] by the end of Sunday the 4th of March. (I
 already have one rebuttal sent in to me).

manoj
-- 
Troubles are like babies; they only grow by nursing.
Debian Project Secretary <[EMAIL PROTECTED]> <http://vote.debian.org/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpAsFv4vYgmj.pgp
Description: PGP signature

Platforms for the candidates published

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

The platforms for the candidates have been published, and are
 accessible from http://www.debian.org/vote/2003/vote_0001

I would like to keep to the schedule and publish the
 rebuttals this Friday 2003/02/21, as initially proposed (I am going
 to be away for a week long business trip next week, so there is
 little room for slippage).

I'd appreciate it if the candidates send me any rebuttals by
 the 21st. 

manoj
- -- 
A lack of leadership is no substitute for inaction.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iD8DBQE+U8vaIbrau78kQkwRAkIKAKCpcd2uRswpW4ThW4Sv8hDoqOv6FgCgnGU8
MCq4Xg+u1rPxw3y3yvCp1fc=
=qlFv
-END PGP SIGNATURE-

Platforms for the candidates published

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

The platforms for the candidates have been published, and are
 accessible from http://www.debian.org/vote/2003/vote_0001

I would like to keep to the schedule and publish the
 rebuttals this Friday 2003/02/21, as initially proposed (I am going
 to be away for a week long business trip next week, so there is
 little room for slippage).

I'd appreciate it if the candidates send me any rebuttals by
 the 21st. 

manoj
- -- 
A lack of leadership is no substitute for inaction.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iD8DBQE+U8vaIbrau78kQkwRAkIKAKCpcd2uRswpW4ThW4Sv8hDoqOv6FgCgnGU8
MCq4Xg+u1rPxw3y3yvCp1fc=
=qlFv
-END PGP SIGNATURE-


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

Re: Status on publishing platforms

[Branden Robinson]

On Tue, Feb 18, 2003 at 11:05:03AM -0500, Branden Robinson wrote:
> And now, I'm told, Manoj has three, leaving me the hold up.

...not anymore.

-- 
G. Branden Robinson| The Rehnquist Court has never
Debian GNU/Linux   | encountered a criminal statute it
[EMAIL PROTECTED] | did not like.
http://people.debian.org/~branden/ | -- John Dean


pgpPSKDlkVo9T.pgp
Description: PGP signature

Re: Status on publishing platforms

[Branden Robinson]

On Tue, Feb 18, 2003 at 11:05:03AM -0500, Branden Robinson wrote:
> And now, I'm told, Manoj has three, leaving me the hold up.

...not anymore.

-- 
G. Branden Robinson| The Rehnquist Court has never
Debian GNU/Linux   | encountered a criminal statute it
[EMAIL PROTECTED] | did not like.
http://people.debian.org/~branden/ | -- John Dean



msg02442/pgp0.pgp
Description: PGP signature

Re: Status on publishing platforms

[Branden Robinson]

On Sun, Feb 16, 2003 at 04:19:28PM -0600, Debian Project Secretary wrote:
>   I apologize for the delay in publishing the Project Leader
>  platforms. They have not yet been put up on vote.debian.org, since I
>  have received only two of the four candidate platforms to date. I
>  strongly urge the remaining candidates to please send me the
>  platforms asap.

And now, I'm told, Manoj has three, leaving me the hold up.

Here's the skinny:

 Manoj: sorry, I have been really busy, and am trying to roll
  out XFree86 4.2.1-6 at the moment
 Manoj: to fix a FTBFS
 which is holding up KDE 3.1
 Overfiend: use one of the old platform :))
 Overfiend: who cares?
 heh. took the words from my moth
 mouth
* Overfiend shrugs.  You're damned if you do and damned if you don't...
 Overfiend: some intimation would have been nice
 Overfiend: Do you have an ETA on the platform?
 Manoj: I've barely even been on IRC all weekend
 Manoj: I'll work on it when I get home this evening
 Manoj: that's approx 7pm GMT-0500
 Overfiend: Ok. I'll so inform -vote
 so I'll try to have you something mailed by 10pm GMT-0500
* Overfiend sighs.  Not nearly enough time to do serious analysis of the
  questionnaire result.  I guess I can go through and edits the comments for
  idiolect and then just post the raw results somewhere.
 Overfiend: Or you may inform -vote (since you could then provide the
  reaons better than I probably could)

(For those keeping score at home:

Overfiend   me, Branden Robinson
Manoj   Project Secretary Manoj Srivastava
doogie  Adam Heath
Joy Josip Rodin

Now you KDE 3.1 fans know who to flame.  ;-) )

So, there you have it.  The questionnaire results were extremely
interesting but it's not worth holding up my platform for any longer.  I
will therefore have to write my platform with only my gut reaction to
the questionnaire replies instead of a rigorous, methodical analysis
calculated to win me the maximum number of votes.  :)

Thus, hopefully within 12 hours or so you folks will have my platform.

So that you aren't completely in the dark, I will direct you to my
platform for last year.  There will be changes, of course, but there is
not much that I would actively throw out (the qmail on murphy issue,
which was near the bottom of the list anyway, has of course been
resolved in the past year).

  http://www.debian.org/vote/2002/platforms/branden

The most important thing I have learned from the questionnaire results
is that "THE DEBIAN PROJECT LEADER'S DELEGATES" should remain at the top
of my agenda.  It could be broadened in scope a little bit to imply more
attentive supervision of foundering infrastructure in general, but
ultimately the solution to Debian's infrastructure problems is going to
have to be a leader capable of appointing delegates, and *following up
on the progress of those delegations*.  I've been thinking about methods
to attain this goal, and if the questionnaire results are highly
representative of the electorate, than I expect this issue to see some
discussion during the campaign period.

Thanks for your attention and patience!

-- 
G. Branden Robinson|Men use thought only to justify
Debian GNU/Linux   |their wrong doings, and speech only
[EMAIL PROTECTED] |to conceal their thoughts.
http://people.debian.org/~branden/ |-- Voltaire


pgpdQ4oZfqya4.pgp
Description: PGP signature

Re: Status on publishing platforms

[Branden Robinson]

On Sun, Feb 16, 2003 at 04:19:28PM -0600, Debian Project Secretary wrote:
>   I apologize for the delay in publishing the Project Leader
>  platforms. They have not yet been put up on vote.debian.org, since I
>  have received only two of the four candidate platforms to date. I
>  strongly urge the remaining candidates to please send me the
>  platforms asap.

And now, I'm told, Manoj has three, leaving me the hold up.

Here's the skinny:

 Manoj: sorry, I have been really busy, and am trying to roll
  out XFree86 4.2.1-6 at the moment
 Manoj: to fix a FTBFS
 which is holding up KDE 3.1
 Overfiend: use one of the old platform :))
 Overfiend: who cares?
 heh. took the words from my moth
 mouth
* Overfiend shrugs.  You're damned if you do and damned if you don't...
 Overfiend: some intimation would have been nice
 Overfiend: Do you have an ETA on the platform?
 Manoj: I've barely even been on IRC all weekend
 Manoj: I'll work on it when I get home this evening
 Manoj: that's approx 7pm GMT-0500
 Overfiend: Ok. I'll so inform -vote
 so I'll try to have you something mailed by 10pm GMT-0500
* Overfiend sighs.  Not nearly enough time to do serious analysis of the
  questionnaire result.  I guess I can go through and edits the comments for
  idiolect and then just post the raw results somewhere.
 Overfiend: Or you may inform -vote (since you could then provide the
  reaons better than I probably could)

(For those keeping score at home:

Overfiend   me, Branden Robinson
Manoj   Project Secretary Manoj Srivastava
doogie  Adam Heath
Joy Josip Rodin

Now you KDE 3.1 fans know who to flame.  ;-) )

So, there you have it.  The questionnaire results were extremely
interesting but it's not worth holding up my platform for any longer.  I
will therefore have to write my platform with only my gut reaction to
the questionnaire replies instead of a rigorous, methodical analysis
calculated to win me the maximum number of votes.  :)

Thus, hopefully within 12 hours or so you folks will have my platform.

So that you aren't completely in the dark, I will direct you to my
platform for last year.  There will be changes, of course, but there is
not much that I would actively throw out (the qmail on murphy issue,
which was near the bottom of the list anyway, has of course been
resolved in the past year).

  http://www.debian.org/vote/2002/platforms/branden

The most important thing I have learned from the questionnaire results
is that "THE DEBIAN PROJECT LEADER'S DELEGATES" should remain at the top
of my agenda.  It could be broadened in scope a little bit to imply more
attentive supervision of foundering infrastructure in general, but
ultimately the solution to Debian's infrastructure problems is going to
have to be a leader capable of appointing delegates, and *following up
on the progress of those delegations*.  I've been thinking about methods
to attain this goal, and if the questionnaire results are highly
representative of the electorate, than I expect this issue to see some
discussion during the campaign period.

Thanks for your attention and patience!

-- 
G. Branden Robinson|Men use thought only to justify
Debian GNU/Linux   |their wrong doings, and speech only
[EMAIL PROTECTED] |to conceal their thoughts.
http://people.debian.org/~branden/ |-- Voltaire



msg02439/pgp0.pgp
Description: PGP signature

Status on publishing platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

I apologize for the delay in publishing the Project Leader
 platforms. They have not yet been put up on vote.debian.org, since I
 have received only two of the four candidate platforms to date. I
 strongly urge the remaining candidates to please send me the
 platforms asap.

manoj
- -- 
Burke's Postulates: Anything is possible if you don't know what you
are talking about. Don't create a problem for which you do not have
the answer.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iD8DBQE+UA5pIbrau78kQkwRAvg8AKCacN2TR12bcr8x1HoEJlPRt9tofgCffplD
cck2nNBpxctjqYBcxoUShbE=
=8h3T
-END PGP SIGNATURE-

Status on publishing platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

I apologize for the delay in publishing the Project Leader
 platforms. They have not yet been put up on vote.debian.org, since I
 have received only two of the four candidate platforms to date. I
 strongly urge the remaining candidates to please send me the
 platforms asap.

manoj
- -- 
Burke's Postulates: Anything is possible if you don't know what you
are talking about. Don't create a problem for which you do not have
the answer.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iD8DBQE+UA5pIbrau78kQkwRAvg8AKCacN2TR12bcr8x1HoEJlPRt9tofgCffplD
cck2nNBpxctjqYBcxoUShbE=
=8h3T
-END PGP SIGNATURE-


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

Re: Rebuttals appended to candidate platforms

[Anthony Towns]

On Thu, Mar 14, 2002 at 03:28:02PM -0500, Branden Robinson wrote:
> For the record, I'll note that I'm much, much more efficient writing
> emails than HTML. 

*cough*

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Debian: giving you the power to shoot yourself in each 
   toe individually.'' -- with kudos to Greg Lehey

Re: Rebuttals appended to candidate platforms

[Anthony Towns]

On Thu, Mar 14, 2002 at 03:28:02PM -0500, Branden Robinson wrote:
> For the record, I'll note that I'm much, much more efficient writing
> emails than HTML. 

*cough*

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Debian: giving you the power to shoot yourself in each 
   toe individually.'' -- with kudos to Greg Lehey


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

Re: Rebuttals appended to candidate platforms

[Branden Robinson]

On Thu, Mar 14, 2002 at 12:12:44AM -0600, Debian Project Secretary wrote:
>   5 days late, rebuttals have bee4n appended to the platforms of
>  candidates who submitted rebuttals. I apologize for the delay. 

Belatedly, here is mine:

http://people.debian.org/~branden/platform+rebuttal.html

Also MIME-attached.

-- 
G. Branden Robinson|   The only way to get rid of a
Debian GNU/Linux   |   temptation is to yield to it.
[EMAIL PROTECTED] |   -- Oscar Wilde
http://people.debian.org/~branden/ |
Title: Branden Robinson's Platform for Debian Project Leader -- 2002


  
  
Branden Robinson's Platform for Debian Project Leader -- 2002

Introduction and Biography

Greetings, fellow Debian developers.


The purpose of this message is to outline the reasons I am running for
Debian Project Leader (DPL), and to present an idea of some specific things
I would like to accomplish during my term, if elected.


First, a brief biographical introduction is in order.  My name is Branden
Robinson; I have been a Debian Developer since approximately January of
1998.  My most prominent work in Debian has been as maintainer of the
XFree86 packages, which I have done since March of 1998.  Since August of
last year, I have also been the Treasurer of Software in the Public
Interest, Inc., Debian's legal parent organization and manager of the
Debian Project's assets.  I am 27 years old, employed as a free software
developer, married, and have no children.


Some of this platform may be familiar to you if you have read from my DPL
Platform from last year.  This is because some of the issues I was
concerned about have not been addressed in ways that I'm completely happy
with.


I will also note that there are few specific courses of action in this
document to which I am wedded.  The purpose of this document is to identify
my guiding principles and priorities, not to draw a roadmap which I will
follow in excruciating detail.  Since I feel that a diagnosis of problems
is less valuable without proposed solutions, I'm suggesting possible
solutions.  I look forward to interested people stepping forward and
participating in the process of solving these problems.  To me, leadership
means listening, and then taking action on an informed basis.  If you feel
that some of my proposals suffer from a lack of information, I urge you to
waste no time in bringing me up to speed.


Unlike some, I firmly believe that Debian's democratic, constitutional
basis is a sound one.  I do not believe it retards our growth or viability
as a software project.  On the contrary, I think that by distributing the
lion's share of power among the Developers, rather than vesting it in the
Project Leader, the Debian Constitution ensures our Project's long-term
prosperity.  It protects our Project's identity and goals from being
excessively over-identified with a single individual.  In the Debian
Project, you shouldn't ever have to worry about what happens if developer X
"gets hit by a bus", or -- more likely -- resigns (whether formally or by
simply vanishing without a trace).


That said, the role of Project Leader is still an important one.  The DPL
must have an awareness of the challenges that face our Project which are
too large for any one Developer to surmount, and attempt to allocate
resources towards overcoming those challenges.  At the same time, the
Project Leader must maintain Debian as an environment that encourages
experimentation, novel problem-solving, and reinforcement and reward for
the volunteer spirit that is the backbone of our Project.   Debian is an
organization where one can simply leave if one is unhappy, so a Project
Leader must do more than simply give lip service to consensus-building.
The Debian Project does not have a captive membership; poor leadership will
lead to loss of people, loss of vitality, and loss of relevance.

Major Issues

The following is a list of items that will be high on my priority list.

I. THE DEBIAN PROJECT LEADER'S DELEGATES

The central -- and overriding -- issue to my mind about the role of DPL is
the process of delegation under the Constitution.  I think this is a great
mechanism (potentially) that has been underutilized to date.


First and foremost, I think we need more delegates from the Project Leader.
For the most part, Debian Developers have very narrow bounds within which
they can exercise their personal discretion.  This is, largely, the right
way to do things.  Since we are such a large body, and since we invariably
have such a large pool of varied opinions about how any particular thing
(technical or otherwise) should be done, this helps to keep Debian
harmonious.  In other words, we may argue, but there is a fairly clear
perimeter within which any individual developer can act with a legitimacy
recognized by the rest of the Project.  This perimeter is pretty much
conf

Re: Rebuttals appended to candidate platforms

[Branden Robinson]

On Thu, Mar 14, 2002 at 12:12:44AM -0600, Debian Project Secretary wrote:
>   5 days late, rebuttals have bee4n appended to the platforms of
>  candidates who submitted rebuttals. I apologize for the delay. 

Belatedly, here is mine:

http://people.debian.org/~branden/platform+rebuttal.html

Also MIME-attached.

-- 
G. Branden Robinson|   The only way to get rid of a
Debian GNU/Linux   |   temptation is to yield to it.
[EMAIL PROTECTED] |   -- Oscar Wilde
http://people.debian.org/~branden/ |

Title: Branden Robinson's Platform for Debian Project Leader -- 2002


  
  
Branden Robinson's Platform for Debian Project Leader -- 2002

Introduction and Biography

Greetings, fellow Debian developers.


The purpose of this message is to outline the reasons I am running for
Debian Project Leader (DPL), and to present an idea of some specific things
I would like to accomplish during my term, if elected.


First, a brief biographical introduction is in order.  My name is Branden
Robinson; I have been a Debian Developer since approximately January of
1998.  My most prominent work in Debian has been as maintainer of the
XFree86 packages, which I have done since March of 1998.  Since August of
last year, I have also been the Treasurer of Software in the Public
Interest, Inc., Debian's legal parent organization and manager of the
Debian Project's assets.  I am 27 years old, employed as a free software
developer, married, and have no children.


Some of this platform may be familiar to you if you have read from my DPL
Platform from last year.  This is because some of the issues I was
concerned about have not been addressed in ways that I'm completely happy
with.


I will also note that there are few specific courses of action in this
document to which I am wedded.  The purpose of this document is to identify
my guiding principles and priorities, not to draw a roadmap which I will
follow in excruciating detail.  Since I feel that a diagnosis of problems
is less valuable without proposed solutions, I'm suggesting possible
solutions.  I look forward to interested people stepping forward and
participating in the process of solving these problems.  To me, leadership
means listening, and then taking action on an informed basis.  If you feel
that some of my proposals suffer from a lack of information, I urge you to
waste no time in bringing me up to speed.


Unlike some, I firmly believe that Debian's democratic, constitutional
basis is a sound one.  I do not believe it retards our growth or viability
as a software project.  On the contrary, I think that by distributing the
lion's share of power among the Developers, rather than vesting it in the
Project Leader, the Debian Constitution ensures our Project's long-term
prosperity.  It protects our Project's identity and goals from being
excessively over-identified with a single individual.  In the Debian
Project, you shouldn't ever have to worry about what happens if developer X
"gets hit by a bus", or -- more likely -- resigns (whether formally or by
simply vanishing without a trace).


That said, the role of Project Leader is still an important one.  The DPL
must have an awareness of the challenges that face our Project which are
too large for any one Developer to surmount, and attempt to allocate
resources towards overcoming those challenges.  At the same time, the
Project Leader must maintain Debian as an environment that encourages
experimentation, novel problem-solving, and reinforcement and reward for
the volunteer spirit that is the backbone of our Project.   Debian is an
organization where one can simply leave if one is unhappy, so a Project
Leader must do more than simply give lip service to consensus-building.
The Debian Project does not have a captive membership; poor leadership will
lead to loss of people, loss of vitality, and loss of relevance.

Major Issues

The following is a list of items that will be high on my priority list.

I. THE DEBIAN PROJECT LEADER'S DELEGATES

The central -- and overriding -- issue to my mind about the role of DPL is
the process of delegation under the Constitution.  I think this is a great
mechanism (potentially) that has been underutilized to date.


First and foremost, I think we need more delegates from the Project Leader.
For the most part, Debian Developers have very narrow bounds within which
they can exercise their personal discretion.  This is, largely, the right
way to do things.  Since we are such a large body, and since we invariably
have such a large pool of varied opinions about how any particular thing
(technical or otherwise) should be done, this helps to keep Debian
harmonious.  In other words, we may argue, but there is a fairly clear
perimeter within which any individual developer can act with a legitimacy
recognized by the rest of the Project.  This perimeter is pretty much
conf

Re: Rebuttals appended to candidate platforms

[Branden Robinson]

On Thu, Mar 14, 2002 at 12:12:44AM -0600, Debian Project Secretary wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
>   5 days late, rebuttals have bee4n appended to the platforms of
>  candidates who submitted rebuttals. I apologize for the delay. 

Yes, I need to claim responsibility for this.  I wasn't able to finish
authoring my rebuttal because I've had my hands full with XFree86
4.1.0-15 and pgi 0.9.4.4 preparation.

My apologies to the other candidates.

For the record, I'll note that I'm much, much more efficient writing
emails than HTML.  Probably because I'm obsessed with making sure my
HTML validates correctly.  :)

-- 
G. Branden Robinson|I just wanted to see what it looked
Debian GNU/Linux   |like in a spotlight.
[EMAIL PROTECTED] |-- Jim Morrison
http://people.debian.org/~branden/ |


pgpVqnOBMg7Vx.pgp
Description: PGP signature

Re: Rebuttals appended to candidate platforms

[Branden Robinson]

On Thu, Mar 14, 2002 at 12:12:44AM -0600, Debian Project Secretary wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
>   5 days late, rebuttals have bee4n appended to the platforms of
>  candidates who submitted rebuttals. I apologize for the delay. 

Yes, I need to claim responsibility for this.  I wasn't able to finish
authoring my rebuttal because I've had my hands full with XFree86
4.1.0-15 and pgi 0.9.4.4 preparation.

My apologies to the other candidates.

For the record, I'll note that I'm much, much more efficient writing
emails than HTML.  Probably because I'm obsessed with making sure my
HTML validates correctly.  :)

-- 
G. Branden Robinson|I just wanted to see what it looked
Debian GNU/Linux   |like in a spotlight.
[EMAIL PROTECTED] |-- Jim Morrison
http://people.debian.org/~branden/ |



msg01507/pgp0.pgp
Description: PGP signature

Rebuttals appended to candidate platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

5 days late, rebuttals have bee4n appended to the platforms of
 candidates who submitted rebuttals. I apologize for the delay. 

manoj
- -- 
 Might as well be frank, monsieur. It would take a miracle to get you
 out of Casablanca.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iEYEARECAAYFAjyQPzcACgkQIbrau78kQkymZACg86jefloc0aB3n2IOj175UQzb
lxwAoI1/FhDbGJd62y5tn/00pLIuRMuL
=4JAU
-END PGP SIGNATURE-

Rebuttals appended to candidate platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

5 days late, rebuttals have bee4n appended to the platforms of
 candidates who submitted rebuttals. I apologize for the delay. 

manoj
- -- 
 Might as well be frank, monsieur. It would take a miracle to get you
 out of Casablanca.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iEYEARECAAYFAjyQPzcACgkQIbrau78kQkymZACg86jefloc0aB3n2IOj175UQzb
lxwAoI1/FhDbGJd62y5tn/00pLIuRMuL
=4JAU
-END PGP SIGNATURE-


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

Re: Debian Project Leader Election 2002: Platforms

[Martin Schulze]

Debian Project Secretary wrote:
> Hi Folks, 
> 
>   All the candidate platforms are now in, and have been uploaded
>  to my home dir on cvs.debian.org. Soon, some kindly folks from
>  debian-www shall take this tarball, unpack it into the correct place
>  in the wml tree, and it should propagate to the web site on the next
>  wml run.

Update estimated in five hours from now, counting backwards...

Regards,

Joey

-- 
Never trust an operating system you don't have source for!

Re: Debian Project Leader Election 2002: Platforms

[Martin Schulze]

Debian Project Secretary wrote:
> Hi Folks, 
> 
>   All the candidate platforms are now in, and have been uploaded
>  to my home dir on cvs.debian.org. Soon, some kindly folks from
>  debian-www shall take this tarball, unpack it into the correct place
>  in the wml tree, and it should propagate to the web site on the next
>  wml run.

Update estimated in five hours from now, counting backwards...

Regards,

Joey

-- 
Never trust an operating system you don't have source for!


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

Debian Project Leader Election 2002: Platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Folks, 

All the candidate platforms are now in, and have been uploaded
 to my home dir on cvs.debian.org. Soon, some kindly folks from
 debian-www shall take this tarball, unpack it into the correct place
 in the wml tree, and it should propagate to the web site on the next
 wml run.

manoj
- -- 
 Try the Moo Shu Pork.  It is especially good today.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iEYEARECAAYFAjyACeEACgkQIbrau78kQkxUYgCg13YfB1pNctefqwZ5QxfjvQtT
58gAn3woJv3ZsVK2jBku8k3M5sBt5/n1
=NZbg
-END PGP SIGNATURE-

Debian Project Leader Election 2002: Platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Folks, 

All the candidate platforms are now in, and have been uploaded
 to my home dir on cvs.debian.org. Soon, some kindly folks from
 debian-www shall take this tarball, unpack it into the correct place
 in the wml tree, and it should propagate to the web site on the next
 wml run.

manoj
- -- 
 Try the Moo Shu Pork.  It is especially good today.
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iEYEARECAAYFAjyACeEACgkQIbrau78kQkxUYgCg13YfB1pNctefqwZ5QxfjvQtT
58gAn3woJv3ZsVK2jBku8k3M5sBt5/n1
=NZbg
-END PGP SIGNATURE-


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

Debian Leader Election: Publishing platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Folks,

This is a notice to prospective candidates for the Debian
 Project Leader elections.  I intend to collect platform statements
 from the candidates, and publish them on a known location (somewhere
 under www.debian.org/vote) at the end of the nomination period and
 the beginning of the campaign, which makes it roughly the 27th of
 February, 2002.

I suggest that the candidates send the platform, preferably in
 HTML/SGML, to the secretary at least a couple of days before the
 publication date.

This should give the candidates enough time to craft their
 platforms, I should think. The format of the web page is open to
 discussion, but I suggest there be at least three sections:
  a) Introduction/Biography
  b) Major Goal/ Meat of the platform,
  c) Rebuttal. 

After the publication, there share be a one week period for
 each candidate to create a rebuttal, and the rebuttals shall be
 published on the 7th of march.

Voting shall start on the 21st of March, 2002, and shall last
 for 3 weeks, ending on the 10th of April.

Please send comments to the debian-vote@lists.debian.org
 mailing list.

manoj
- -- 
 "Bring the little ones unto me, and I will get a good price for
 them." Dr. Fegg
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iEYEARECAAYFAjxh3S4ACgkQIbrau78kQkxF5QCg2HXjTtOmwyPiPtatBNCIcrKm
8iQAoMis4FMtkf5JB3ANg25ibp5inYpc
=fP12
-END PGP SIGNATURE-

Debian Leader Election: Publishing platforms

[Debian Project Secretary]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Folks,

This is a notice to prospective candidates for the Debian
 Project Leader elections.  I intend to collect platform statements
 from the candidates, and publish them on a known location (somewhere
 under www.debian.org/vote) at the end of the nomination period and
 the beginning of the campaign, which makes it roughly the 27th of
 February, 2002.

I suggest that the candidates send the platform, preferably in
 HTML/SGML, to the secretary at least a couple of days before the
 publication date.

This should give the candidates enough time to craft their
 platforms, I should think. The format of the web page is open to
 discussion, but I suggest there be at least three sections:
  a) Introduction/Biography
  b) Major Goal/ Meat of the platform,
  c) Rebuttal. 

After the publication, there share be a one week period for
 each candidate to create a rebuttal, and the rebuttals shall be
 published on the 7th of march.

Voting shall start on the 21st of March, 2002, and shall last
 for 3 weeks, ending on the 10th of April.

Please send comments to the [EMAIL PROTECTED]
 mailing list.

manoj
- -- 
 "Bring the little ones unto me, and I will get a good price for
 them." Dr. Fegg
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iEYEARECAAYFAjxh3S4ACgkQIbrau78kQkxF5QCg2HXjTtOmwyPiPtatBNCIcrKm
8iQAoMis4FMtkf5JB3ANg25ibp5inYpc
=fP12
-END PGP SIGNATURE-


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