Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Brian Gupta]

On Thu, Nov 14, 2019 at 7:09 PM Russ Allbery  wrote:

> Sam Hartman  writes:
>
> > I'd like to propose the following resolution.
>
> > Seconds are not required, but it would be valuable to get confirmation
> > that the three choices contained in this proposal are worth having on
> > the ballot.  So, rather than seconding the proposal it would be useful
> > if people would ack choices here they'd like to see on the ballot.
>
> I will vote all three of these options above further discussion and am
> comfortable with all three options from a Policy guidance standpoint.
>
> Thank you!
>

I would like to see an additional option to leave current policy unchanged.
Obviously if I am alone in wanting this option, please disregardt.

-Brian

Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Brian Gupta]

On Thu, Nov 14, 2019 at 9:13 PM Russ Allbery  wrote:

> Brian Gupta  writes:
>
> > I would like to see an additional option to leave current policy
> > unchanged.  Obviously if I am alone in wanting this option, please
> > disregardt.
>
> What does that mean to you?  I ask because Policy is a little incoherent
> and a lot incomplete.
>
> Are you specifically looking for an option that says that packages that
> support systemd are required to support sysvinit and that it's an RC bug
> if they don't?
>

Yes. That was my understanding of the tortured consensus from a few years
ago. Paraphrasing.. "Yes, we'll pick a sane default, but don't worry, We
won't be removing support for other systems."

-Brian

Re: Draft text on Init Systems GR

[Brian Gupta]

On Thu, Nov 14, 2019 at 7:51 PM Dmitry Bogatov  wrote:

>
> [2019-11-14 17:15] Ian Jackson 
> > Dmitry Bogatov writes ("Draft text on Init Systems GR"):
> > > Choice 1: Affirm Init Diversity
> > >
> > > Being able to run Debian systems with init systems other than
> > > systemd continues to be value for the project. Package not
> > > working with pid1 != systemd is RC bug, unless it was designed
> > > by upstream to work exclusively with systemd.
>
> > We should clearly have something very simple like this on the ballot.
> > I would strongly prefer this to some other plausible outcomes.
>
> > However, I very much doubt that would command majority support.  I
> > think we can find a way to give everyone something tolerable.
> > (elogind just migrated to testing.)
>
> What do you mean "something tolerable"? In my opinion, my wording,
> should it win, will protect 1300 daemons and their init scripts. I do
> not see how you can relax wording without endangering this goal.
> --
> Note, that I send and fetch email in batch, once in a few days.
> Please, mention in body of your reply when you add or remove recepients.
>

Do you think it's ok in any case to remove init scripts. Let's say an
upstream stops maintaining init scripts, and only ships unit files and
says, oh all the distros we care about use systemd, so we're not going to
bother to support init scripts any more. Assuming we already have an init
script that works fine, can/should we remove it if the upstream no longer
supports it? I guess my question is what does it mean to say "designed by
upstream to work exclusively with systemd"? Is that ambiguous, or clear to
everyone? I think we're going to hit grey areas, where upstreams may only
test with systemd, but that it can be made to work with any init system.

Thanks,
Brian

Re: Draft text on Init Systems GR

[Brian Gupta]

On Sun, Nov 17, 2019 at 12:00 PM Bastian Blank  wrote:

> Hi Brian
>
> On Fri, Nov 15, 2019 at 01:10:58AM -0500, Brian Gupta wrote:
> > Do you think it's ok in any case to remove init scripts. Let's say an
> > upstream stops maintaining init scripts,
>
> I would like to know if this is a real world problem.  Please provide an
> example of a package where the init script actually comes from upstream
> and is not maintained in debian/*.init and installed by dh_installinit.
>
> Init scripts are inherent incompatible between distributions.  One
> designed for RedHat or, worse, SUSE will not really work on a Debian
> system, due to differences in used tools.  LSB tried to standardize
> that, but this effort is dead as well.
>

I don't know if it is a real world problem. I know of at least one upstream
that maintains their own packages for the major distros, and maintained
both init scripts and unit files, and as best as I can tell they are now
only maintaining unit files, as the distros they actively support are all
defaulting to systemd. That said, I don't recall them saying they are
explicitly removing support for sysvinit. (It's a RedHat funded upstream
that surprisingly makes their own debs for Ubuntu and Debian.)

I guess when I gave that example, it was more of a hypothetical, as I'm not
aware of all the reasons that package maintainers would give to remove an
init script. I think the more important thing to understand what "designed
by upstream to work exclusively with systemd" means, and if we do adopt
that wording, make sure everyone judges this the same way (objectively vs
subjectively). That said, I'm leaning towards supporting Dmitriy's text
with Ian's tweak "and no support for running without systemd is available"
(Leaving the door open for the community to step up and provide support for
alternative init systems, and perhaps making this distinction less
important?)

-Brian

Regards,
> Bastian
>
> --
> Totally illogical, there was no chance.
> -- Spock, "The Galileo Seven", stardate 2822.3
>
>

Re: Proposal: Init Diversity

[Brian Gupta]

On Wed, Nov 20, 2019 at 7:41 AM Ian Jackson 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> (Kurt, you can skip to "FAO KURT".)
>
> Dmitry Bogatov writes ("Proposal: Init Diversity"):
> > Here I formally propose following option, withdrawing any previous
> > versions.
> ...
> >   Being able to run Debian systems with init systems other than
> >   systemd continues to be value for the project. Package MUST work
> >   with pid1 != systemd, unless it was designed by upstream to work
> >   exclusively with systemd and no support for running without
> >   systemd is available.
> >
> >   Software that uses systemd features non-conditionally should be
> >   considered as designed to work exclusively with systemd, but
> >   software that does just do not provide init.d should not.  In
> >   case of doubt, explicit statement of upstream is definitive.
>
> I have been having an email discussion with Dmitry about this.  I find
> this final paragraph unsatisfactory because it seems like it could
> contradict the first part.  As I wrote to Dmitry:
>
>   So, for example, suppose I find a daemon that unconditionally
>   expects the systemd daemon startup protocol.  I write a patch to
>   make it able to work differently, with perhaps a command line option
>   or something.  I submit it upstream, who say "no we are not
>   interested, this is designed to work exclusively with systemd".  Am
>   I now to give up ?  Debian need not take my patch.
>
> Dmitry replied that this was not his intent, and explained his intent
> to me.  He said he would welcome a proposed amendment.  I don't have
> permission to quote his email, but I think I can capture his intent.
>
> For now, I propose the following amendment: <=== FAO KURT
>
>   Delete the 2nd paragraph of Dmitry's proposal and replace with:
>
> Software is not to be considered to be designed by upstream to
> work exclusively with systemd, merely because upstream do not
> provide, and/or will not accept, an init script.
>
> I think the effect of this is:
>
>  * For software that merely needs an init script writing, an init
>script MUST be provided (by the Debian maintainer, if necessary).
>
>  * For software that needs other patches writing, it is up to the
>community to write patches for non-systemd support.  The maintainer
>does not need to write them but MUST accept them if they are
>provided, because then "support for running with systemd is
>available".
>
>  * Software that is inextricably tied to systemd is permitted,
>even though it only works with systemd as pid 1.
>
> Dmitry's wording is less specific than mine about what happens if
> non-systemd support patches are themselves RC-buggy but I think the
> effect is the same.  It would be unreasonable to say that "support for
> running without system is available" if the "support" is RC-buggy.
>
> I would appreciate it if others here would comment on my wording and
> maybe help improve it.  Dmitry's email latency means that he won't be
> able to participate in the drafting as fully as ideal, so I would like
> to make sure that he is offered the best possible wording.
>
> For the avoidance of doubt, I am not trying to hijack Dmitry's
> authority over his text.  Please do not second my amendment.  I am
> hoping Dmitry will accept it (or some other similar improvement).  If
> Dmitry does not accept it I will withdraw it.
>

For the record, I plan to second Dmitriy's amendment once he has finalized
it..

-Brian
-BEGIN PGP MESSAGE-

owEBpQJa/ZANAwAIAcD4hkzaPQNYActeYgBd1a+wRm9yIHRoZSByZWNvcmQsIEkg
cGxhbiB0byBzZWNvbmQgRG1pdHJpeSdzIGFtZW5kbWVudCBvbmNlIGhlIGhhcyBm
aW5hbGl6ZWQgaXQuLgoKLUJyaWFuCokCMwQAAQgAHRYhBK8RPdDsSYzYhL3LNsD4
hkzaPQNYBQJd1a+1AAoJEMD4hkzaPQNY/NUP/0XlgSxFlIKFBGoqKzfViyfaJGLW
OABbOisyAbl1G/ZlR4wIhXZkZu8exi//2bJ4CJyKua9YQ1aO15aSsiYk55p9xOIR
XiVpI9JRIp5wFrpfSQNzKfku4aGRsZUxaafkylT6bOST/73gQxIzXF2TfX93WDVl
/mD5mwlK893kzvGgo2NZ60e7puqgRuQH7gwX/u0RQFA26lDc1k9+O5lR1ngOkvbk
8izHbQDeoGOVtQPNmh82Xk5KLYqbl5tLfhDPbMmf1qFun1S4WncZJqBzLcyPKzRs
0IzQwPfjk5sMyfKGIB/ebNxXFXc1fjoKa2eaKVxXKf5pYJj99DOKRnwkKZ/sH+sa
5m9Ma8ZU5+7EOFPPgNBJmiini7gqCCHutzHvRrAutzdiD+POlcvuqkxHcJB9lwNO
lcAOtHDhJhr8lF5Pn/9Nn9COwkCc/fZMscmJnC/61yf7UfG3SweGiLwXNjserDlm
dhw1g9gttg0zCzP+mliV70Rrg4EJzifBomjJUpQUE5hVOzRUGN/fOCnEDEZa/Tlf
sHC4ZY6fvOfDGpHkFOoINfa5z6gqGKHXA4PlA1EUYpJlNniSMMcbdbwi4Sl2oIFf
qMZx638kPiscsMCKiQLHPXK89GdDFoqgdGEYOzR+X77NZOZJa/nN8lRkd9YtBMTD
CysseEuYth9rYJuL
=sx3I
-END PGP MESSAGE-


> Ian.
> -BEGIN PGP SIGNATURE-
>
> iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAl3VNC8gHGlqYWNrc29u
> QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTn3zAf/fy8Kdp1pWDmh
> vQD9cH+bAQpBrsUtzk/vhEdMD+I5D3X6XatxgTgJHQhbdhKXBFSKAEzWoqhAJvTy
> e+XoPQN+ftzMlg796YVioGiKntD8iw0gb693mDtrx80WcDGM6IUhe4WtDR4L9E2R
> 1vEU3qpON+W9GmnkE2gMINs8h1fpsIwFWiaGyGtGInoSraHtwZVjME7Sn8QXbhdr
> 6w4J01y52a2e+GQbCYCjAq7zDV5UD/QbKCrJHn5+jQQh0tH4g7+IN6uZc3UXP+3d
> nl+T1nfzAMKS2GtvlgeSJ

Re: Proposal: Init Diversity

[Brian Gupta]

On Wed, Nov 20, 2019 at 7:11 PM Dmitry Bogatov  wrote:

>
> Here I formally propose new version of my draft, and withdraw all
> previous versions of it.
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Being able to run Debian systems with init systems other than
> systemd continues to be value for the project. Package MUST work
> with pid1 != systemd, unless it was designed by upstream to work
> exclusively with systemd and no support for running without
> systemd is available.
>
> Software is not to be considered to be designed by upstream to
> work exclusively with systemd, merely because upstream do not
> provide, and/or will not accept, an init script.
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAl3V0u8ACgkQSBLY3qgm
> EeaOyA/8Cda8C+28KkOyby51V6vdThxuoK15qM/T6kBDwpvSHXxirlfeAXX+kBO9
> u6ktSDgbtzWzwTdbFWET+dc7LLhERMiJlTRUx8zfUmT0U9pFtxveF/xUsQscXyDK
> wKOJh4jC+9Dl9HhK2B0C8JIhRSFhZq4iB9OaSUXeaBepZCyjk8X/M890Zone4P0Q
> Dfs8vpEPn06QdknUWjYaIWd/5TLrny5GP26e8p7MdGkEf5DGAvsOQmUZn5mni/g2
> Y2KRmZWL1+UnGpkTjCYXyQOS2+X3hmoUO/yMfcKDTdEebV5Q80Z2JTC1vQChGQ5k
> aOQaB4H88EqzZ5QWECrw/309TSqmzSKBExwoFHsVZ12F9kOE0TxWIJT52NwtwJzh
> fM9AJCXVcKX0Y9Pt6O2QmzbxhWbmL0hp9dnYL0o6n2/4hu04+PiMTNCOMeZrxBVN
> gQgpC6hBoQPQoMHrmYITSqA7jrPCWzaPaMFSfk1aITwYtdSKnjE70P5z0i0MZL31
> JMLAabUpAajU6jLxGA52svaSBYm67I4kka10MWuyrOoPqMSxRipF+ir1U8H0M/80
> 9wRjXiraw5j2/VrqBK2W/n43DvlZB0y3/XCgtXvkyhG+fE65NOaH/UKrn6covcZW
> DB3NY8zifq2GzYlGDU5ZC5FLm2JfWzkWqmtz/CHUXWQqzA3F1Ro=
> =p2r/
> -END PGP SIGNATURE-
>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Being able to run Debian systems with init systems other than
systemd continues to be value for the project. Package MUST work
with pid1 != systemd, unless it was designed by upstream to work
exclusively with systemd and no support for running without
systemd is available.

Software is not to be considered to be designed by upstream to
work exclusively with systemd, merely because upstream do not
provide, and/or will not accept, an init script.

- ---

Please consider the above version, and all future variants that contain
nothing
but grammar/wording changes, seconded by me. (As opposed to meaning
changes.)

e.g. - Maybe change "upstream do not provide" to "upstream does not provide"
   (I'm considering upstream a singular noun.)

Cheers,
Brian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEErxE90OxJjNiEvcs2wPiGTNo9A1gFAl3WDfYACgkQwPiGTNo9
A1gE9g/+ODQyw0nhjep+HTf957NZ93aIINi2XOtc8iLAGDFTPadFHMTMup75l/fG
WxHzJ+gLB/I/zhbGcodisWIoqVXtJeqQoKPMmRxYzlp6RLY08Jp5SzuIlaUtbjiF
SJUw9W1vCtO1TGGOa7VVyJtPgG5FQQy+BSQtkNvB9gt/saVyMCzQm2LacxXLipUx
9J3KQEfBmbpnX8KZWALq8t+RjgWZd54kgm62j8aTUDa1f3qvJiV9m9xmhZdmELEe
qR5k7usJvt5g+qUygiSj/WSeNuhcXg+thXAadSQpnsZNd/D5gVpMwa6mIV0iAUof
xXlv2N/3CrTSlcspN86kQlUXoCms3MfFkf9iSX29DzjeCCP0m4E9FAIE/A+qahMV
nf2BVU8KiSmYjWYBdAGBqExdLv8bwjry0gqYFQ1Htv8hIilja1knd2U8JniXCoNa
C9W/EXIWncrRUxECLZYxFapXHlqXMEYTFtjE6EtboIix9ypQb9NTz59YAcutDFQM
nN1bl6LgEnP+sJDPvT4HYSHhDdQC1ZU0keYQhyFHoVxTITA+ysJGVb1RPC2pZE6Z
n+6L6yqrgOpp2w8PPOta7icJpCVdt0bUYCc2Erp/fIjGcuRBFqJlmXeHeklCS3Ta
atRnKwNfjtGwIz4xH08y+udyJKkDcwfjnckNuHAJDMr2vEm6sB4=
=2ZEK
-END PGP SIGNATURE-


> [2019-11-20 12:40] Ian Jackson 
> > Dmitry replied that this was not his intent, and explained his intent
> > to me.  He said he would welcome a proposed amendment.  I don't have
> > permission to quote his email, but I think I can capture his intent.
>
> FWIW, you have my permission to quote GR-related mails as needed. We are
> on tight schedule.
>
> > For now, I propose the following amendment:
> > [...]
>
> Thank you, Ian. I agree with your wording. Incorporated and formally
> proposed.
>
> > I think the effect of this is:
> >
> >  * For software that merely needs an init script writing, an init
> >script MUST be provided (by the Debian maintainer, if necessary).
> >
> >  * For software that needs other patches writing, it is up to the
> >community to write patches for non-systemd support.  The maintainer
> >does not need to write them but MUST accept them if they are
> >provided, because then "support for running with systemd is
> >available".
> >
> >  * Software that is inextricably tied to systemd is permitted,
> >even though it only works with systemd as pid 1.
>
> This. I hope updated wording can't be read other way.
> --
> Note, that I send and fetch email in batch, once in a few days.
> Please, mention in body of your reply when you add or remove recepients.
>

Re: Proposal: Init Diversity

[Brian Gupta]

On Thu, Nov 21, 2019 at 9:02 AM Kurt Roeckx  wrote:

> On Wed, Nov 20, 2019 at 11:10:13PM -0500, Brian Gupta wrote:
> >
> > Please consider the above version, and all future variants that contain
> > nothing
> > but grammar/wording changes, seconded by me. (As opposed to meaning
> > changes.)
>
> I was unable to verify your signature.
>

Trying again. If this doesn't work, I'll send as an attachment. (I didn't
change my text, even though there have been some changes to the wording of
the ammendment.)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Being able to run Debian systems with init systems other than
systemd continues to be value for the project. Package MUST work
with pid1 != systemd, unless it was designed by upstream to work
exclusively with systemd and no support for running without
systemd is available.

Software is not to be considered to be designed by upstream to
work exclusively with systemd, merely because upstream do not
provide, and/or will not accept, an init script.

- ---

Please consider the above version, and all future variants that contain
nothing
but grammar/wording changes, seconded by me. (As opposed to meaning
changes.)

e.g. - Maybe change "upstream do not provide" to "upstream does not provide"
   (I'm considering upstream a singular noun.)

Cheers,
Brian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEErxE90OxJjNiEvcs2wPiGTNo9A1gFAl3WzAwACgkQwPiGTNo9
A1iN4g/8CbDsiXUEqMH1eBKy9eGIBLDYg1MV9NjTz4IeNhLf5K9O2HxXwM/8q58g
Frdcz/0o5f/tnl5XNgoZ6urw9tPcxWklSquHx03UyYMod+B/6BH5QK/8+R/5RDkD
1eEpA0L0O6Vznn6fVzDGSjxsG1yI6cE6MDYvx2Ax+r2/lE2AZ1fmCirGVVPE+Ih+
MnS1QDMrZZirDfvdADID7JKSYnRl4jjgoQJgPptxphzPHHlxfeYdIIwf20xSGncf
s2yTdx1nocZbF42J9yVQenTrtOLd4u4r85Hk1Us8VjlXxeysn8xxgreftsL9AqTp
7mn2Zvlv90x8P8Gtr6XS6bmJJMzSiyNMxkmkG9VZZdeG2IH1b4HdnSLWygR0MGuG
bX8werISahAdM074Lynnmud3Kji78Gf6a4QkUwLI+Rv6jfW1vtb+pKx24y5uCg1U
r4XQKyf2I5qBaBQZ+mdg2hj2TwgEGyWj1VihDNJNJ8agGY0jYiEaBaNjaCI+s+HG
dkVVc3eVvv3801SinuBJD3C0GcVpY2k+S0rkY09GHrzqbNjJVd3EwvVkwVKWlX1V
VTp99joXuUze1zzeAk+a4W1gyX67xKKiP7WOEEesKHD5q2GcKVln5X10Phuh8V+t
1s6oLIFv204duZ0kpwyI3edFBGSJ7n6JZp1B9s11Ot1bgq10Fh8=
=4xRL
-END PGP SIGNATURE-

Re: Proposal: Init Diversity

[Brian Gupta]

On Thu, Nov 21, 2019 at 1:33 PM Kurt Roeckx  wrote:

> On Thu, Nov 21, 2019 at 12:49:47PM -0500, Brian Gupta wrote:
> > On Thu, Nov 21, 2019 at 9:02 AM Kurt Roeckx  wrote:
> >
> > > On Wed, Nov 20, 2019 at 11:10:13PM -0500, Brian Gupta wrote:
> > > >
> > > > Please consider the above version, and all future variants that
> contain
> > > > nothing
> > > > but grammar/wording changes, seconded by me. (As opposed to meaning
> > > > changes.)
> > >
> > > I was unable to verify your signature.
> > >
> >
> > Trying again. If this doesn't work, I'll send as an attachment. (I didn't
> > change my text, even though there have been some changes to the wording
> of
> > the ammendment.)
>
> I still get:
> *BAD* signature from: Brian Gupta 
>  aka: Brian Gupta 
>  aka: Brian Gupta 
>
>
> Kurt
>

Alright, thanks. Please try the attached. If it's still not working I'll
have to take some time to debug.


signed-second.asc
Description: Binary data

Re: Opposite of a Platform for DPL 2020

[Brian Gupta]

On Wed, Mar 4, 2020 at 2:32 PM Sam Hartman  wrote:

>
> TL;DR: Overall, being DPL has been incredibly rewarding.  I have
> enjoyed working with you all, and have enjoyed the opportunity to
> contribute to the Debian Project.  I hope to be DPL again some year,
> but 2020 is the wrong year for me and for the project.  So I will not
> nominate myself this year, but hope to do so some future year.
>
> I wanted to take some time to share my thoughts on my time as DPL, and
> some thoughts about the next year.  Over the past year, we've done
> some great work.  I'd like to start by acknowledging that and taking a
> moment to be proud of our accomplishments together.
>
> Consensus And Summaries: DH and Git
> ===
>
> In my platform I wrote:
>
> Debian is not fun when we face grueling, long, heated discussions.  It
> is not fun when we are unable to move a project forward because we cannot
> figure out how to get our ideas considered or how to contribute effectively.
>
> Much of my focus at DPL was on a couple of experiments in decision
> making.  Together I hoped we could show ourselves and the world that
> Debian can make decisions.  I wanted to explore the DPL's role in
> accomplishing that.
>
> We succeeded.  I facilitated a number of consensus-based discussions
> where we explored options and came to conclusions.  In my mind the
> major elements of these were:
>
> * Starting with a statement of the problem area and a set of
> questions/observations about the current state of the discussion.
>
> * Giving people an opportunity to give input.
>
> * Indicating areas where we appeared to have an answer and areas where
> additional input was required; trying to cut off threads that were starting
> to repeat themselves.
>
> * Providing a summary so others could check that we got to the same place.
>
> * Feeding results of the discussion to the appropriate parts of the
> project.
>
>
> I think we succeeded at this work a number of times.  From my
> standpoint, it was rewarding and energizing to see us actually make a
> decision and to get to a place where I thought we were not just
> repeating ourselves.  For me and a number of other contributors I've
> talked to, discussions are less draining when we reach conclusions.
>
> I think I demonstrated that the DPL can be valuable in facilitating
> these discussions.  I'm glad that I was able to explore more ways that
> the DPL could help the project.
>
> But what really made me happy is watching others copy this pattern.
> Yes, the DPL can facilitate, and for some project-level discussions
> that is the right answer.  But anyone can implement the above steps.
> I saw a number of people do so.  In particular, I think summaries at
> the end of discussions are incredibly important.  It was great to see
> others doing that.  It's great to see us learning together.
>
> This was an experiment.  While I think we demonstrated that we can use
> this procedure to make decisions, we also brought forward a number of
> things to think about for the future.  The biggest issue is that these
> discussions do take time and energy even when they eventually reach
> conclusions.  I think we need to think carefully about when we need to
> make decisions as a project, or when other approaches are better.
>
> Also, one or two people can cause a consensus discussion to drag on
> much longer.  As an example, it was obvious to me as a facilitator
> very early on in the Git Packaging discussion that we were not going
> to change our position on the use of Gitlab and other non-free
> services.  Hundreds of messages were spent on a sub-thread that was
> never going to reach consensus.  We need better tools for managing
> that use of our collective time while allowing each other to be heard.
>
> I think both of these are great areas to explore as we continue to
> improve Debian decision making.
>
> Facilitated GRs
> ===
>
> In my platform I talked about how I thought the DPL's power to propose
> general resolutions could be used as a tool for facilitating
> discussion when consensus cannot work.  We explored that together, and
> I think we did a great job of breaking a longstanding block in how we
> approach init systems.
>
> The traditional wisdom is that GRs should be proposed by a strong
> proponent of the option in question.
>
> I was dubious of this wisdom.  It starts the process out on a
> confrontational note, rather than as a cooperative exploration of what
> the project wants.  When consensus is impossible, there is inherent
> conflict.  However, we can (and did) work together cooperatively to
> enumerate the options.  I believe doing some ground work as a
> facilitator behind the scenes helped make that easier.
>
> There's another benefit though.  By working to facilitate, I was able
> to hear options in the middle expressed by people who had opinions,
> but who were not involved enough to dedicate their time to go put that
> option forward.  In 

Self-nomination, on a platform to create a Debian Foundation

[Brian Gupta]

Hi, I'm Brian Gupta, found online as bgupta.
 
I am running for DPL with a singular goal. The creation of Debian US and EU 
Foundations. I largely view my candidacy as a referendum on this goal and its 
details. During the campaigning period, I will share the details as part of my 
platform, and I will update my platform to incorporate feedback. If it's clear 
there isn't a rough consensus to move forward, I will likely withdraw my 
candidacy. (Perhaps for reworking and another day.)

-Brian


signature.asc
Description: PGP signature

Re: Question to Brian: Why do you need to be DPL to set up foundations?

[Brian Gupta]

On Mon, Mar 16, 2020 at 05:53:08PM -0400, Sam Hartman wrote:
> 
> 
> Dear Brian:
> 
> I've just read your platform.
> For reasons that are slightly different than the ones you state, I tend
> to agree that  setting up foundations sounds like a good idea.
> And I think you have a significant chunk of the background to lead that
> effort.
> 
> As an individual (read after my DPL term expires) I'd be very likely to
> sponsor a GR as a referendum on this idea and even include text
> delegating making it happen to you.
> 
> But I can't figure out why you'd need or want to be DPL to do that.

As you correctly noted, this work technically doesn't require one to be
DPL, but it would certainly help, and would at least require support from
the current DPL.

I chose this path for a number of reasons:

1) By making it my platform, it should be a much lighter-weight method
   for people to express their opinions than a GR. If this proves
   contentious, I can always withdraw my candidacy rather than push
   through a tough vote that splits the community. (In this case, I'd
   rather back off and take however long it takes to build a rough
   consensus.)

2) I don't believe a GR is needed, as my current plan doesn't require
   any changes to the constitution

3) As I alluded, it would really only be practical with the explicit
   support of the DPL.  Being DPL would guarantee that support.

4) It gives project members options on how they vote. If I am elected
   DPL, that would likely be a clear sign the project supports my
   proposal. If I was ranked below "None of the above", that's another
   clear message. Finally, if most people ranked me above "None of the
   above, even if I wasn't first choice, I'd assume that as a signal of
   support for the proposal and would try to work with the elected DPL
   to implement the proposal.
 
> How would you handle the aspects of being DPL that are not related to
> setting up a foundation?

I would try to be unsurprising when it comes to routine matters, like
appointing delegations and approving expenses. If I am unsure about the
best course, I will solicit advice both privately and, where warranted,
publically.

Where appropriate I would rely on delegates and other project members. 
e.g. - I'm not the greatest public speaker, and would leave technical
decisions to the folks working on the features they want to see, and 
if there are any unresolved disputes I trust the Technical Committee
and chair to resolve them.

> You talk about bringing back a DPL helpers team.
> What would that give us that we don't have today?

I found participating on Zack and Lucas's DPL-helpers teams rewarding,
and it gave me insight into some of Debian's big picture issues.

Although I have a technical background, my day-to-day work, is as a 
technical manager, so I found DPL-helpers an interesting path to
contribute that wasn't purely technical or overly specialized. I'd hope
to offer such a contribution path to others would might have similar
backgrounds.

If elected DPL, I would invite the other DPL candidates to join that
team as I do believe it provided good exposure for those considering
running for DPL.

> How would you lead over the next year in areas unrelated to  setting up
> the foundation?

Largely, I'd let people do what they do, and be there to help unblock
them if they need resources, or other support. I don't have a major
short term agenda, outside of the Foundations that could be accomplished
in a single term, and there are laundry lists of tasks/projects a DPL
might take on. For example, here's an old list, I collected as a 
DPL-helper. [1] 

I am fairly certain that working on the Foundations, and taking care
of routine matters, will keep me plenty busy. If I were to try and
expand the goals, they would likely prove unreachable.

> What do you think the big challenges that the DPL will face that are
> unrelated to the foundation/administrative matters will be in 2020?

All indications are that 2020 is going to be a trying year for
everyone. We'll all be dealing with existential challenges, and I'm
not sure how this will impact the project, but I'm certain it's won't
be negligible.

Everyone is anxious and I believe that that everyone in the project,
including and perhaps especially the DPL, will need to be especially
empathetic to our colleagues and friends in our Debian family.

[1] - https://wiki.debian.org/Teams/DPL/Ideas


signature.asc
Description: PGP signature

Re: Costs of running a Debian foundation

[Brian Gupta]

On Tue, Mar 17, 2020 at 8:20 AM Martin Michlmayr  wrote:
>
> [ I wasn't sure whether to comment on Brian's platform or stay out of
> this, but I think it's important to scrutinise the plan.  Please see
> my disclaimers at the end though. ]

Thank you Martin. You have a great amount of relevant experience. Your
feedback and questions are very much appreciated.

> Brian,
>
> * You write: "Debian Project Leaders should have more time to lead
> rather than be buried in the set of administrative tasks they
> currently face"
>
> It's not clear to that I follow this argument.  Right now, the DPL and
> treasurer team only have to maintain a relationship with a third party
> (the TO).  Isn't that *less* work than overseeing your own
> organization?

In the past, when we had a struggling TO, we'd have to engage volunteers
to help, and not just help for Debian, but help the overall TO, so we
needed to find volunteers that wanted to help a non-profit with a
wide mandate.

Speaaing only for myself, but one of the things that have held me back over the
years from volunteering for SPI, beyond the very narrowly-focused work I did to
establish Paypal accounts, were the requirements to support an ever-growing
number of non-Debian projects.

Also, it's not just maintaining a 3rd-party relationship. In SPI's case, half 
the
board is currently Debian members, which is why I initially couldn't understand
the reasoning behind the overall push to end special treatment for Debian.

I came to realize that as Free Software advocates, we have a commitment to
fairness and that is honorable.  Thinking about it from the mandate of SPI,
I can't find fault in the choices that SPI's board took to seek equality between
projects.

However, I also came to strongly believe that Debian needs dedicated-purpose
entities that are aligned with Debian's special needs.

> * You argue that "history has shown that volunteers alone aren’t
> enough" and that "difficult to find enough people to volunteer to do
> these things".
>
> I would agree with this.  And having done both volunteer and paid work
> in this area, I can attest that there's a limit on how much admin work
> someone will do as a volunteer.
>
> However, Debian has historically had a rather strained relationship
> with paid work.  One could argue that the current Debian / SPI
> relationship works because Debian is paying a service provider.  But
> if Debian were to have its own foundation, you could argue that the
> topic of Debian paying people will come up again.
>
> You make a good point that admin work is different.  But will everyone
> agree?  If Debian starts paying for admin work, why not pay for other
> activities where it's been hard to find work?
>
> Maybe some would agree that this is actually a good path to go, and
> that a Debian Foundation would lead to more paid opportunities in the
> future, but I think you could easily see this as a source of much
> disagreement.
>
> How would you address that?

You make a good point, and touch on the one main area that I think might
be controversial. However, I believe Debian has evolved over the years,
to where this might not be as controversial as it was in the past, especially
if we look at it in the narrow area of administrative work.

I believe out views have evolved for a few reasons:

1) We have now accepted 3rd-party paid help from SPI and it's definitely
improved service levels. It would be an artificial distinction to not
consider it for a Debian Foundation.
2) It's now largely uncontroversial that Debian funds are directed to "paid
work", in the form of Outreachy sponsorship.
3) It's been a long time. We've seen what works well with volunteer work, and 
what
doesn't.

I of course fully understand that having our own Foundation(s) could open up
future discussions about paid technical work, but that probably should be a
separate discussion, as that's not why I am advocating for this. (For the 
record,
I have mixed feelings about paid technical work, and only feel we should ever
consider it, where there is a strong consensus to do so.)

> Also, who is going to decide who to hire/contract?

The Foundation's board, which would include the DPL.

I'll say now that someone with your background would be near the top of my
list of candidates.

> * "the DPL is no longer a special member of SPI invited to all meetings":
>
> I have to give some context on this (BTW, I don't speak for SPI, but
> I'm a SPI member like anyone in Debian can become).  SPI used to have
> 2 board advisors: a representative from PostgreSQL and the current
> DPL.  At some point SPI said:
>
> * We haven't used these advisors in years
> * Why pick advisors from 2 big projects when SPI serves all associated 
> projects?
> * SPI's meetings are open: let's encourage everyone to participate
>
> So let me ask this: why hasn't the DPL (or a representative) attended
> the public SPI IRC meetings?  Registered guests are mentioned in the
> minutes and I don't see

Re: Question to all: Outreach

[Brian Gupta]

On Tue, Mar 17, 2020 at 12:32 PM Hector Oron  wrote:
>
> Hello,
>
>   First of all, thanks for nominating yourselves to Debian project leaders.
>
>   Debian Outreach looks like an awesome initiative to bring new blood
> into Debian and also people coming from minority groups, however, on
> the other hand, it has been a quite expensive to run for the real
> benefit provided to Debian project. Reading the delegation text:
> https://lists.debian.org/debian-devel-announce/2019/03/msg00011.html.
>   I find 2 out of 3 team coordinators are not Debian
> contributors/developers, and the other seems to be inactive.
>
>   Q: How do you feel on having non-Debian contributors/developers
> being DPL delegates?

While I'm perfectly happy with non-project members being members of
delegated Debian teams, the Constitution is pretty clear that delegations
must be to other Project Members.

   "The Leader may define an area of ongoing responsibility or a specific
   decision and hand it over to another Developer or to the Technical 
Committee."

I read this to mean that delegated teams must have at least one Debian Project
Member. (At least not without a change in the constitution which is a change I
would not support.)

In your specific example, I believe that we need to check in with the existing
delegate and see if they are in fact inactive and if they are inactive, we'd 
need
to create a new delegation.

>   Q: Do you see any flaws on the current Outreach setup? If so, how
> would you address them?

Other than your suggestion that the team Delegate may be inactive, I don't know
enough about the current Outreach setup, to know where there might be areas in
need of improvement. If I am elected to DPL, I'd be happy to have a discussion
with you and the team, and will certainly reach out to the Delegate. I will say
that I do generally support Debian's participation in this program, and have
helped fundraise for it in the past. I also believe that there is a fairly
strong project consensus to support internship programs like Outreach and GSoC.

Cheers,
Brian


> My best regards,
> --
>  Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.
>


signature.asc
Description: PGP signature

Re: Question to Brian: why not submit your plan for a Debian Foundation to a GR ?

[Brian Gupta]

On Tue, Mar 17, 2020 at 12:52 PM Louis-Philippe Véronneau  
wrote:
>
> Hi Brian,
>
> The idea of having a Debian Foundation sounds interesting, although I do
> share some of tbm's fears.
>
> From what I understand, you want this DPL election to be a referendum on
> the idea of a Debian Foundation.
>
> It would be really hard for me to vote for you without having a clearer
> idea of what that would entail for Debian, especially in terms of costs.
> It feels a bit like signing a blank check and hoping things go well.

The DPL is bound to operate under the constitution, and would still need to
follow 5.1.19, so you wouldn't be signing a "blank check".

   "In consultation with the developers, make decisions affecting property held 
in
   trust for purposes related to Debian. (See §9.). Such decisions are 
communicated
   to the members by the Project Leader or their Delegate(s). Major expenditures
   should be proposed and debated on the mailing list before funds are 
disbursed."

> I understand coming up with a solid business plan for a "Debian
> Foundation" is not something that can be done in a few weeks.

You are correct. It's going to take 6-12 months of work to create the 
foundation,
and that includes drafting by-laws.

> In another email you write:
>
> > 2) I don't believe a GR is needed, as my current plan doesn't require
> >   any changes to the constitution
>
> I'd be much more inclined to vote for you if you promised you would in
> fact propose a GR on this once elected.
>
> It would give you (and others who want to help) time to come up with a
> solid plan and let the Debian community be the final judge.

I'd like to understand this request more. We have three trusted organizations 
(two
of which have Debian in their names), and we didn't have a GR to form them or 
make
them TOs.

The GR to do what I am proposing already passed in 2006. [1] If it turns out 
that
additional constitutional changes are required, of course, I'd seek out a GR.

Would you be happy with the following commitments instead of a commitment to 
propose
a GR?

1) Share any proposed drafts for the organization's by-laws w/ debian-project 
for
   feedback, and consensus-building?
2) Consult with Project Members on a budget for hiring the administrative staff 
(As
   would be expected by the constitution)

I was trying to put my finger on what it is I don't love about GRs, and I think 
it's
the conflict between having a time-limited conversation and giving everyone a 
chance
to have their say. This can end up with everyone rushing to say what they want 
to
say, in a stressful compressed marathon sprint of discussion. I much prefer
open-ended discussions that either end in consensus or with an agreement that
consensus is unlikely to be reached. Of course some things require a GR, but I'd
hope that consensus was largely already built prior to starting the GR process.

Thanks,
Brian

[1] - https://www.debian.org/vote/2006/vote_003




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


signature.asc
Description: PGP signature

Re: Costs of running a Debian foundation

[Brian Gupta]

On Wed, Mar 18, 2020 at 1:37 AM Wouter Verhelst  wrote:
>
> On Wed, Mar 18, 2020 at 12:46:09PM +0800, Martin Michlmayr wrote:
> > So I'm more satisfied with the rationale of creating a Debian
> > foundation, although my concerns about the actual operations still
> > apply (i.e. how are you going to make sure you'll do a better job than
> > the TOs you're not happy with when there have been countless failures
> > of running non-profits in the past).
>
> I have to say that I share those concerns.
>
> Specifically, I believe that SPI was meant to be our foundation. That it
> grew into something more, and that it took several years for it to do
> what we needed it to do is unfortunate; but there is no reason to
> assume, from my point of view at least, that building another foundation
> to do what SPI couldn't do, will bring us more success.
>
> Brian, what's your view on that?

First off, I'd like to reiterate that I don't expect to end relationships with
our current TOs, including SPI. (I stated this in my platform, but there was
enough potential for misunderstanding that I want to reiterate.)

I also agree that when looking back at history, that SPI was meant to be the
Debian Foundation that I am advocating for now. However, the thought back then,
was that since Debian was doing all the work to set up a non-profit, that it
wouldn't be that much more work to provide the same services to other FLOSS
projects. At one point this expansion of scope threatened to overwhelm SPI, they
struggled for many years, but it appears they have found their stride now and
are successfully servicing over 40 projects today. This makes them one of the
largest homes for FLOSS projects today. It's a remarkable success story,
especially looking at how far SPI has come in not that long a time.

That said, when you are servicing over 40 projects, your priorities need to
change, and you MUST look at what you can do for ALL your projects, not just
your founding project.

In hindsight, it was a happy accident that SPI was created the way it was, and
grew into the multi-project home it did.

However, we - as a project - need to adapt as well. We realize that SPI has
grown into something great but cannot support the Debian project fully and to
the extent we need. We are large enough and have enough requirements in legal
and support services that it warrants founding our own foundations that will
permanently be aligned with the ever evolving goals of the Debian project.

What we do as a project isn't easy. We don't shy away from things because they
are hard, and have risk. We try to do things that we are right and worth doing.
In this case, I'll agree, it's not going to be easy. It will be a lot of work.
However, there are reasons to be optimistic.

1) Experience: We have Project Members that have a lot of experience running
   many different entities and know what has worked and what hasn't.
2) Depth: We are a large and well-respected project. Many people want to help,
   especially if they know it's going to help Debian.
3) Options: We aren't taking away anything we currently have. Our current TOs
   will remain there to support us, giving us time to do it right.

FreeBSD Foundation works, Postgres Foundation works, KDE e.V. works, Gnome
Foundation works, so we can make Debian Foundations work, too.

Cheers,
Brian


signature.asc
Description: PGP signature

Re: What are your thoughts on discourse?

[Brian Gupta]

On Wed, Mar 18, 2020 at 6:01 AM Raphael Hertzog  wrote:
>
> Hello dear DPL candidates,
>
> I would like all the candidates to reply to this question on discourse:
> https://discourse.debian.net/t/dear-dpl-candidates-what-are-your-thoughts-on-discourse/75
>
> Please create an account and answer there. At least it would give you a
> feeling of how it looks like to use it.
>
> The kind of discussions that we have in debian-vote is very much suited
> for something like discourse where we can +1 with like, etc.
>
> I would encourage others DD asking questions to try to use discourse and
> just use the mail to inform of the discussion started on discourse.

I registered. Thank you for setting that up. I agree with Jonathan that since
debian-vote is the official forum for election-related discussion, we should
keep the discussion here.

Some people will like discourse and some people don't, but I would welcome
experimentation, including a fully backed-up highly-available Debian instance
for those who wish to use it. Looking to the future, I would say we should only
make it the default if there is consensus to do so. At this time, I don't
believe there is a consensus to do so.

I think perhaps one approach towards building consensus, might be to look at
new lists going forward first. IE: Make it an option for those who might
otherwise request a list.

Cheers,
Brian


> Cheers,
> --
>   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
>   ⣾⠁⢠⠒⠀⣿⡁
>   ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
>   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>


signature.asc
Description: PGP signature

Re: Question to Brian: why not submit your plan for a Debian Foundation to a GR ?

[Brian Gupta]

On Wed, Mar 18, 2020 at 4:30 PM Neil McGovern  wrote:
>
> On Thu, Mar 19, 2020 at 12:57:55AM +0800, Martin Michlmayr wrote:
> > * Louis-Philippe Véronneau  [2020-03-18 12:52]:
> > > Would you care to elaborate on what "the Yorba determination" is? I
> > > couldn't find anything online about this...
> >
> > There was a time when the IRS didn't approve any new 501(c)(3)
> > applications for open source related organizations and basically put
> > them on ice.
> >
> > I thought this got resolved though in the meantime (years ago).
> >
> > https://blogs.gnome.org/jnelson/2014/06/30/the-new-501c3-and-the-future-of-free-software-in-the-united-states/
> > https://opensource.org/node/840
> >
>
> The two links from Martin are probably the best background reading. the
> tldr versions is: making FOSS is not enough to gain 501c3 status by
> itself.

Applications for non-profit status need to be done carefully as they are
scrutinized in most jurisdictions. Looking at the BOLO, it seems the IRS is
particularly on the lookout for commercially developed Open Source Software.

   "The members of the organizations are usually the for-profit business or
for-profit support technicians of the software." 

I think Debian has a very good case here, and at least to my eyes doesn't fit
that description. I think it's worth the effort to try. As they say "nothing
ventured, nothing gained."

Cheers,
Brian


signature.asc
Description: PGP signature

Re: Question for all candidates: Sam's non-platform: Delegates

[Brian Gupta]

On Wed, Mar 18, 2020 at 1:35 PM Sean Whitton  wrote:
>
> Hello,
>
> In his non-platform, Sam wrote
>
> If I were running as DPL, figuring out how to do a better job of
> managing delegations, respecting both the current delegates and the
> needs of the project, would be my priority for the next year.  I
> hope that the candidates who step forward take on this challenge.
>
> Do you agree?  If so, how do you propose to take on the challenge?

If I am elected DPL, one of the first things I will do, is a check-in with all
delegated teams, and ask them what support and time they might need from me over
the coming year, and ask them for a sense of how they feel things are going. I
would make plans accordingly.

Of course, if it was brought to my attention that someone was unhappy with a
team's service, I'd remind them that we are all volunteers, but I'd look into
the expressed concerns and discuss them with the team in question. I would see
if the team understands where the concerns are coming from and if they feel
there is anything we could do to help the situation.

Cheers,
Brian


signature.asc
Description: PGP signature

Re: Question to Brian: why not submit your plan for a Debian Foundation to a GR ?

[Brian Gupta]

On Wed, Mar 18, 2020 at 6:55 PM Scott Kitterman  wrote:
>
> On Wednesday, March 18, 2020 6:41:42 PM EDT Brian Gupta wrote:
> > On Wed, Mar 18, 2020 at 4:30 PM Neil McGovern  wrote:
> > > On Thu, Mar 19, 2020 at 12:57:55AM +0800, Martin Michlmayr wrote:
> > > > * Louis-Philippe Véronneau  [2020-03-18 12:52]:
> > > > > Would you care to elaborate on what "the Yorba determination" is? I
> > > > > couldn't find anything online about this...
> > > >
> > > > There was a time when the IRS didn't approve any new 501(c)(3)
> > > > applications for open source related organizations and basically put
> > > > them on ice.
> > > >
> > > > I thought this got resolved though in the meantime (years ago).
> > > >
> > > > https://blogs.gnome.org/jnelson/2014/06/30/the-new-501c3-and-the-future->
> > > >  > > of-free-software-in-the-united-states/ 
> > > > https://opensource.org/node/840
> > >
> > > The two links from Martin are probably the best background reading. the
> > > tldr versions is: making FOSS is not enough to gain 501c3 status by
> > > itself.
> >
> > Applications for non-profit status need to be done carefully as they are
> > scrutinized in most jurisdictions. Looking at the BOLO, it seems the IRS is
> > particularly on the lookout for commercially developed Open Source Software.
> >
> >"The members of the organizations are usually the for-profit business or
> > for-profit support technicians of the software."
> >
> > I think Debian has a very good case here, and at least to my eyes doesn't
> > fit that description. I think it's worth the effort to try. As they say
> > "nothing ventured, nothing gained."
> >
> > Cheers,
> > Brian
>
> Well, I think there's a down side risk here too.  If Debian were to apply to
> create it's own foundation in the US (certainly in the US, possibly anywhere),
> that would be a very clear signal to SPI that we were planning to replace
> them.  So we file for the new non-profit and spend possibly years without an
> alternative to SPI while we've already told them they are going to be
> replaced.
>
> That probably isn't motivating for a high level of service.  Then if we get
> turned down, we get to go back to them and say "That thing where we were going
> to fire you?  Can we pretend that never happened?".  Not a great position to 
> be
> in.

Many Debian Project Members, myself included, are contributing members of SPI,
and I for one, certainly plan to remain one, regardless of any plans to
establish Debian Foundations.

I also consider the Debian Project Members on SPI's board kindred spirits and
even friends who have similar interests. I very much hope for their continued
success.

Remember that over half of the SPI board are also Debian Project Members, and
are sure to understand our needs. We are NOT abandoning the relationship, and
we will certainly continue working with SPI whether or not we decide to pursue
our own Foundations. 

At the end of the day, SPI is a professionally run organization, that would
not punish one of their member projects for seeking the tailored services and
organizational structure it needs.

Thanks,
Brian

> I'd suggest we need to be far more certain that such a change is both needed
> and likely to be successful.  "Meh, let's give it a shot" isn't really a great
> plan.
>
> Scott K


signature.asc
Description: PGP signature

Re: Question to Brian: Why do you need to be DPL to set up foundations?

[Brian Gupta]

On Thu, Mar 19, 2020 at 9:43 AM Thomas Goirand  wrote:

> On 3/17/20 4:10 AM, Brian Gupta wrote:
> > 1) By making it my platform, it should be a much lighter-weight method
> >for people to express their opinions than a GR. If this proves
> >contentious, I can always withdraw my candidacy rather than push
> >through a tough vote that splits the community. (In this case, I'd
> >rather back off and take however long it takes to build a rough
> >consensus.)
> > 
> > 2) I don't believe a GR is needed, as my current plan doesn't require
> >any changes to the constitution
> > 
> > 3) As I alluded, it would really only be practical with the explicit
> >support of the DPL.  Being DPL would guarantee that support.
> > 
> > 4) It gives project members options on how they vote. If I am elected
> >DPL, that would likely be a clear sign the project supports my
> >proposal. If I was ranked below "None of the above", that's another
> >clear message. Finally, if most people ranked me above "None of the
> >above, even if I wasn't first choice, I'd assume that as a signal of
> >support for the proposal and would try to work with the elected DPL
> >to implement the proposal.
>
> Brian,
>
> Thanks for bringing the topic of a Debian foundation, and highlighting
> the past problems with SPI (I kind of was shocked to read about the
> paypal account, I somehow missed what happened...).
>

If I wrote it in a way that you found shocking, I did not intend for it to 
be. SPI raised a valid concern when looked at from the point of view of an 
organization that is home for over 40 projects. They wouldn't be doing 
their jobs if they continued to allow a single project special-treatment. 

When I first heard about their concerns, I couldn't understand why SPI felt 
the need to make the change, considering the long history between Debian 
and SPI. As time passed, I came to understand SPI's point of view and came
to agree, and expect that if I had been in their role, I would have ended up
with the same thoughts.

I regret, that to some, this appears to be an SPI vs Debian debate. It is 
not. I expect the relationship between SPI to continue into the indefinite
future.

This is about the fact that Debian has needs that require "special-casing",
that will be difficult to fulfill from an organization that isn't singularly
focused on Debian.

> Sorry for this, but I very much don't think it's a good idea to mix a a
> DPL election, and assume that people's votes will reflect their will to
> setup a foundation or not. Maybe a lot of people will prefer candidate X
> or Y before you, but will still would like to move ahead with the
> foundation idea. The same way, some may like you, but may not like the
> foundation thing.
>
> Moreover, as this is the main thing if your platform, we don't have a
> clue about the rest of your intentions, and how you see the DPL job.
>
> I would have very much prefer if you had discuss this as a separate
> topic, and made sure that the next future DPL would support you, or if
> you nominated yourself for the DPL election, and voiced your intend to
> make a GR about creating a foundation (but not make it the only topic of
> your platform).
>
> Anyway, thanks for this topic again, and I really hope you make the
> foundation thing happen, being the DPL or not. :)
>

I will reiterate this before the election, but people do have choices when 
voting. 

1) If you want Foundations, and want me as DPL, please rank me the highest.

2) If you want Foundations, but don't want me as DPL, please just put your 
favorite candidate(s) above me, but please do place me above "None of the 
Above".

3) If you don't want Debian Foundations rank me below "None of the Above". 

The only option I am asking people not to consider is electing me as DPL 
without a mandate to work on the Foundations. If you are opposed to the
formation of Debian Formations, I'd ask that you please rank me below
"None of the Above".

Cheers,
Brian
On Thu, Mar 19, 2020 at 9:43 AM Thomas Goirand <z...@debian.org> wrote:On 3/17/20 4:10 AM, Brian Gupta wrote:
> 1) By making it my platform, it should be a much lighter-weight method
>    for people to express their opinions than a GR. If this proves
>    contentious, I can always withdraw my candidacy rather than push
>    through a tough vote that splits the community. (In this case, I'd
>    rather back off and take however long it takes to build a rough
>    consensus.)
> 
> 2) I don't believe a GR is needed, as my current plan doesn't require
>    any changes to the constitutio

Re: Question to all: Outreach

[Brian Gupta]

On Thu, Mar 19, 2020 at 8:12 PM Paul Wise  wrote:

> On Thu, Mar 19, 2020 at 3:30 PM Jonathan Carter wrote:
>
> > ...
>
> Thanks for the info, those details are interesting.
>
> > Non-uploading DD's existed at the time, I just had no interest in
> > becoming a non-uploading DD when it was already my intent to become an
> > uploading DD.
>
> I don't think any one membership state should be perceived as "final",
> people gain and relinquish both upload privileges and membership
> (going from non-member to uploading DD and then non-uploading DD etc).
> Also, I assume that non-member -> uploading DD and non-member ->
> non-uploading DD -> uploading DD are basically the same amount of
> time/work. I suppose the latter even has the advantage of splitting up
> that time/work over time. I think I like the idea of de-coupling the
> membership from upload privileges even more somehow.
>

I 100% concur, and I'm very happy you pointed this out. I'd love to work 
with you (and whomever else would like to help) to figure out how to do as 
you say and decouple membership from upload privileges even more.

> I was involved when the DPL and DebConf people talked about it,
> > they simply agreed that it's not an issue and that you don't have to be
> > a DD in order to be on the DebConf committee.
>
> It sounds like the DPL (and others) at the time wasn't aware of the
> constitutional issue brought up earlier in the thread.
>
> > TBH I'm having trouble following your line of questioning and exactly
> > what you're concerned about, if I missed something, please ask again and
> > keep it to one question per paragraph.
>
> I'm simply probing why we get into the situation where we get people
> who are not yet members but we want them to be more central to the
> Debian organisation than most members are. My motivation is that this
> situation has always seemed strange to me so I want to understand it
> better. This is getting off-topic so this will be my last mail in the
> thread.

I wasn't aware of how widespread this has become. I've found at least 
2-3 teams that have this case. I think we can resolve this, as most
of the teams in question don't just consist of non-members, so the 
simple short term fix for the next DPL might be to make it clear that
non-members are listed as team members but not delegates, and long term
work with the teams to encourage those folks who feel they share the
project's values, to work towoards membership. If elected to DPL I
commit to this path.

> -- 
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>
On Thu, Mar 19, 2020 at 8:12 PM Paul Wise  wrote:On Thu, Mar 19, 2020 at 3:30 PM Jonathan Carter wrote:

> ...

Thanks for the info, those details are interesting.

> Non-uploading DD's existed at the time, I just had no interest in
> becoming a non-uploading DD when it was already my intent to become an
> uploading DD.

I don't think any one membership state should be perceived as "final",
people gain and relinquish both upload privileges and membership
(going from non-member to uploading DD and then non-uploading DD etc).
Also, I assume that non-member -> uploading DD and non-member ->
non-uploading DD -> uploading DD are basically the same amount of
time/work. I suppose the latter even has the advantage of splitting up
that time/work over time. I think I like the idea of de-coupling the
membership from upload privileges even more somehow.I 100% concur, and I'm very happy you pointed this out. I'd love to work with you (and whomever else would like to help) to figure out how to do as you say and decouple membership from upload privileges even more.
> I was involved when the DPL and DebConf people talked about it,
> they simply agreed that it's not an issue and that you don't have to be
> a DD in order to be on the DebConf committee.

It sounds like the DPL (and others) at the time wasn't aware of the
constitutional issue brought up earlier in the thread.

> TBH I'm having trouble following your line of questioning and exactly
> what you're concerned about, if I missed something, please ask again and
> keep it to one question per paragraph.

I'm simply probing why we get into the situation where we get people
who are not yet members but we want them to be more central to the
Debian organisation than most members are. My motivation is that this
situation has always seemed strange to me so I want to understand it
better. This is getting off-topic so this will be my last mail in the
thread.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: PGP signature

Re: Question to Brian: Why multiple foundations?

[Brian Gupta]

On Fri, Mar 20, 2020 at 5:09 AM Christian Kastner  wrote:
>
> Brian,
>
> I very much support your plan to establish a Debian foundation. Looking
> back over even just the last few months, I saw numerous challenges that
> would have greatly simplified if there were a legal entity representing
> the Debian Project.
>
> Having various Project-wide issues, but representation within these
> matters, and especially liability for them, boiling down to individuals,
> is IMO no longer a way to run a project of this size and significance.
>
> Furthermore,
>
> > The Foundation's board would be elected by the Debian Project Members, and 
> > the DPL would automatically be a full member of the Foundation's board.
>
> is just fantastic. It gives my the direct power to influence the
> foundation with my (digital) vote, and limits the influence to just
> Debian Project Members.
>
> My question though, is: Why three foundations (US, FR, CH)? I get that
> being directly represented in these jurisdictions would have its
> advantages, but overall, wouldn't the downsides over-weigh?

To be clear, Debian France and Debian.CH exist today but are not foundations.
They were established to support local Debian activities in their respective
countries and are not run centrally by the project. Their boards are made up of
people local to that region. You can think of them as friendly entities that
we've granted a license to use the Debian name.

My proposal is to create two Foundations in the US and Europe. I am proposing
these two jurisdictions because the majority of our Project Members are in
these two regions, and many of our sponsors are as well.

Some deliberate redundancy also seems advisable as we cannot trust each
jurisdiction to not cause problems for us some time into the future. Being able
to conduct the needed transactions via the other foundation is a safety net
then. Also, government grants or other types of support may require a legal
entity within the economic zone and we may expect such grants to be offered
once we have legal entities that could receive them.

> For example, in case of a trademark, which entity would legally own it,
> and how would the other entities represent it in their respective
> jurisdictions?

Because the trademarks are currently owned by a US entity, we'd likely transfer
them to the US foundation as that is slightly simpler and currently I do not
know of a compelling reason to transfer our trademarks outside of the United
States. Any other entities would be using the Debian name under license, just
like we have gives usage rights to the Debian name to a few entities already.

   https://www.debian.org/trademark.en.html#licenses 

But as said above for protection of trademarks or enforcement of licenses (or
lack thereof) we could use the entity in the better legal position. The same
obviously for safekeeping of our assets. And these can be transferred between
the foundations where needed, just like we transfer funds from one TO to
another at times now.

> Legally, of course there are solutions, and probably not even that hard
> to figure out. However, I have the impression that the
> overhead/bureaucracy this would add would be noticeable.
>
> Christian


signature.asc
Description: PGP signature

Re: Question to Brian: Why do you need to be DPL to set up foundations?

[Brian Gupta]

On Fri, Mar 20, 2020 at 7:45 AM Steve McIntyre  wrote:
>
> On Fri, Mar 20, 2020 at 09:41:33AM +0100, Enrico Zini wrote:
> >
> >As an example of a voting options that I am considering ad that does not
> >fit with your proposals above, I would very likely vote for you above
> >NOTA for a pure DPL election, and I would very likely vote in favour of
> >a GR option to create a Debian Foundation. I would however rank you
> >below NOTA if you insisted in conflating the two, as I cannot endorse
> >what I see as a misuse of our voting system. You would however
> >incorrectly interpret my vote as a vote against the idea of a Debian
> >Foundation, underestimating support for something you care about.
>
> I hate to just say "me too" on a thread like this, but Enrico has
> totally captured my thinking here.
>
> "Me too".

Thank you both. I appreciate the feedback and understand that you will vote for
what you believe is best for the project. I am largely running to start setting
up Debian Foundations as a DPL. If you can support that, please vote for me. If
you don't want me to work on establishing these Foundations, or don't want me
to be DPL, rank others above me. I'll totally understand. DPL elections are
what they are.

Cheers,
Brian

> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
> "Further comment on how I feel about IBM will appear once I've worked out
>  whether they're being malicious or incompetent. Capital letters are 
> forecast."
>  Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
>


signature.asc
Description: PGP signature

Response to jcc's rebuttal

[Brian Gupta]

I certainly don’t think it will be possible to create both Foundations in one
term, and it may not be possible to even finish creating the US Foundation in
one DPL term, but a lot of progress can be made. In my platform, I estimated
6-12 months, but there are things that are out of our control. These things
include waiting for approvals from municipalities, working on the details, and
time spent building consensus on the details.

I commit that if I am elected DPL, that I will run for a second term, and
finish the creation of the US Foundation if it hasn’t already been completed,
whether or not I am re-elected as DPL. In my first term, I will also begin
working with European developers to create the European Foundation but have no
expectation of completing that during the first-term.

Speaking of a second-term, I believe that because the DPL job involves a large
learning curve that can take over half of a DPL’s first term, prospective DPLs
should be open to the idea of serving two consecutive terms. In the past, I’ve
wondered if we should go as far as considering two-year DPL terms. Since then I
have come to value the status quo and the annual project-wide discussions that
the election stimulates. Also, annual elections give us regular opportunities
to assess our progress and priorities so we can decide whether we want a change
of direction.

Staffing-wise, as I said in my platform, I’m projecting a half-time (20 hours a
week) paid staff member to aid the DPL and related teams. If someone doesn’t
believe it’s appropriate to hire a part-time admin to aid with bureaucratic
tasks like finance and legal paperwork, they should not vote for me. Again,
before hiring anyone, I would consult with Project Members, as is required by
the Debian Constitution for all major expenditures.

Funding-wise, Debian has managed to have an overall positive cash flow for many
years, without any active non-purpose-driven fundraising. IE: We’ve raised funds
for conferences, and for specific goals like funding interns, but we’ve never
really done project-wide fundraising because we’ve never really needed to.
Despite no active fundraising for the general fund, we have more than enough
funds to hire a part-time admin. [1]

I am curious, what was meant by “yet another Debian mess”? In my eyes, the
biggest Debian “messes”, are the endless bikeshedding sessions that end up going
nowhere.

As I’ve stated earlier, I’m not a fan of unnecessary GRs.  If we can find a way
to assess the project’s will without them, we should, just as I thought Jonathan
believed, based on his 2019 DPL campaign rebuttal [2].:

  "I think that GRs should remain a last resort and that there are better ways
  to gauge the community's stance on a topic when you need it. If a poll is
  needed, it's better to do a proper poll than to use a GR as a generic tool."

I will say that during the development work to create the Foundations, if we
discover legal reasons that would require us to change the Constitution, I would
have no issue seeking a GR, and working to build consensus to make the necessary
changes.

Cheers,
Brian

[1] - https://www.spi-inc.org/corporate/annual-reports/2018.pdf
[2] - https://www.debian.org/vote/2019/platforms/jcc


signature.asc
Description: PGP signature

Re: Question to Brian: Why do you need to be DPL to set up foundations?

[Brian Gupta]

On Wed, Mar 25, 2020 at 02:10:00PM +0100, Margarita Manterola wrote:
> Hi,
> 
> On Fri, Mar 20, 2020 at 11:47 PM Brian Gupta 
> wrote:
> 
> > On Fri, Mar 20, 2020 at 7:45 AM Steve McIntyre  wrote:
> > > On Fri, Mar 20, 2020 at 09:41:33AM +0100, Enrico Zini wrote:
> > > >As an example of a voting options that I am considering ad that does not
> > > >fit with your proposals above, I would very likely vote for you above
> > > >NOTA for a pure DPL election, and I would very likely vote in favour of
> > > >a GR option to create a Debian Foundation. I would however rank you
> > > >below NOTA if you insisted in conflating the two, as I cannot endorse
> > > >what I see as a misuse of our voting system. You would however
> > > >incorrectly interpret my vote as a vote against the idea of a Debian
> > > >Foundation, underestimating support for something you care about.
> > >
> > > I hate to just say "me too" on a thread like this, but Enrico has
> > > totally captured my thinking here.
> > >
> > > "Me too".
> >
> 
> I'll add my "Me too" here as well. I think I'm in favour of the Debian
> Foundation (although I'd like to be more informed about this). But I'm
> definitely NOT in favor of co-opting the DPL election to vote for it,
> because you dislike GRs.  I intend to vote for you below NOTA because of
> this reason, not because I don't think exploring the Debian Foundation idea
> is worth the time.
> 
> 
> > Thank you both. I appreciate the feedback and understand that you will
> > vote for
> > what you believe is best for the project. I am largely running to start
> > setting
> > up Debian Foundations as a DPL. If you can support that, please vote for
> > me. If
> > you don't want me to work on establishing these Foundations, or don't want
> > me
> > to be DPL, rank others above me. I'll totally understand. DPL elections are
> > what they are.
> >
> 
> How can we tell you that we do want to explore the Foundation idea, but we
> don't want to have a DPL that's not taking care of the rest of the DPL
> responsibilities? I want a DPL that sets a vision for the project, that
> helps developers find a common cause for collaborating and moving the
> project ahead. It doesn't seem that this is your goal and so I don't feel
> comfortable voting for you above NOTA.
> 
> -- 
> Besos,
> Marga

Marga,

My vision is that Debian needs a functional legal and procedural framework that
goes beyond issue-by-issue sorting out things with SPI or external support.

From my viewpoint working on Treasurer and Trademark teams, giving the DPL
access to a part-time admin, and the flexibility to engage paid legal and
financial help would be the most valuable thing I can provide to the project,
and I'd be in a much better position to do this as DPL.

This does not differ from historical platforms, where other DPL candidates made
detailed promises as part of their platforms. Unfortunately, when elected, they
often fail to achieve their stated goals, as they end up getting bogged down in
the day to day administrative tasks required of being DPL. This is a problem I
am aiming to fix, by creating these foundations.  This will give future DPLs
more freedom to work on the things they put in their platforms.

Part of your concern seems to rest in the fact that I didn't detail out the
standard tasks that are expected of a DPL as things I would do. Of course,
anyone running for DPL would be expected to do these tasks. I never said I
won't do them. I just said that I have a specific goal beyond the day-to-day
business and that is moving toward setting up Debian Foundations.

To be explicit, as DPL, I will perform the following duties that would be
expected of any DPL.

- Generating and publishing monthly reports. Bits from the DPL has become an
  essential source of news for Project Members, and I am excited to continue
  this tradition.
- Review and authorize delegations
- I plan to immediately reach out to all delegated teams to schedule
  availability during the following year. So if teams need extra DPL attention
  at certain times, I'll have reserved it for those teams.
- Make decisions regarding property held in trust for Debian (mostly reviewing
  and approving expenses and budgets in a timely fashion)
- Supporting the TC in appointing new members
- Add or remove organizations from the list of trusted organizations. At this
  time I have no pressing actions on this front, other than work to create the
  new Foundations.
- Solicit advice both privately and, publicly
- Be available to all Developers who need help

In addition, I commit to the 

Re: Q to all candidates: NEW queue

[Brian Gupta]

On Thu, Mar 26, 2020 at 3:34 AM Lucas Nussbaum  wrote:
>
> Hi,
>
> For as long as I can remember, there has been complaints about the
> delays caused by NEW processing (and
> https://ftp-master.debian.org/stat.html shows that we constantly have
> 250-300 packages waiting to be processed).
>
> What is your diagnostic of this issue?
> What solutions do you envision about this issue? Is that just something
> that we have to live with?
>
> Specifically, Jonathan writes that he would like to "Reduce bottlenecks
> that affect our contributors.". That sounds like a good example.
>
>
> Personnally, I wonder if we are being overly cautious about NEW. I
> wonder if we could move to checking a posteriori (accept the package in
> unstable; maybe don't let it migrate to testing until it is reviewed).
>
> Lucas

I believe package count by itself lacks context. I would encourage FTPmasters
to add another metric to their graphs that include the average age of packages
in NEW, rather than just a count.

In addition to recruiting additional team members, which they are already
working on, I think FTPmasters needs to figure a way to get their heads out of
the weeds of the overwhelming work, and find a way to accept help, without
lowering quality.

Cheers,
Brian


signature.asc
Description: PGP signature

Re: Question to Jonathan & Brian: Diversity in Debian

[Brian Gupta]

On Sun, Mar 29, 2020 at 2:39 PM Sruthi Chandran  wrote:
>
> Hello Jonathan and Brian,
>
> I have a couple of questions for both of you.
>
> - What are your thoughts on diversity in Debian?

Debian has evolved a great deal over the past 20+ years to the point that we
now have a commitment to diversity, with a Code of Conduct [1] and Diversity
Statement [2] being two manifestations of that commitment. We now have a
standing Diversity Team and have made active strides towards encouraging
inclusive behavior on our communication forums and during our events. We
actively discourage harassment, which is a prerequisite for creating a welcoming
community.

> - Are we diverse enough?

No. However, answering this question is the easy part.

The hard part is knowing how we can change to become more diverse. Low diversity
is a challenge that faces most of the free software world, as well as technical
careers in general (but to a lesser degree). The biggest challenge, I think, is
that we tend to socialize with and recruit people that are similar to us.

I believe we have taken the necessary prerequisites of recognizing that this is
something we wish to promote, but there is a lot of work to be done to promote
it. The Diversity Team is only about a year old. The first steps of making it
known that Debian cares and working towards becoming an ever more safe and
welcoming community have been taken, but we have a long road ahead of us.

Continually trying to find new ways to be more welcoming, like participating in
Outreach is important. As was the recent creation of the community Team, the
Diversity Team and Statement. Continuing to support activities in regions other
than Europe and the Americas will definitely help.

Overall, I think Debian should be proud of the progress we have made, but still
be cognizant of the fact that we have barely begun the journey.

-Brian

[1] - https://www.debian.org/code_of_conduct
[2] - https://www.debian.org/intro/diversity


signature.asc
Description: PGP signature

All DPL candidates: DPL Term lengths and limits?

[Brian Gupta]

I know this has been raised in elections past, but any thoughts on the
current one-year DPL terms, and unlimited terms allowed? If thoughts
are geared toward change do you have any plans to actively try to
change the status quo?

I ask because it seems that a lot of energy is devoted to the election
every year that might be directed towards other parts of the project.

One idea that I thought showed promise was the idea of two year terms,
but at the ~10.5 month mark the standing DPL had to confirm they were
serving the second half of their term, or an election would
automatically be triggered.

Obviously any changes discussed/proposed would not impact this election.

-Brian


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACFaiRxE+xfWjzhR2ART_8iSOZgyfJeYAL4BBXjV=esxnwz...@mail.gmail.com

Re: Maximum term for tech ctte members

[Brian Gupta]

On Mon, Nov 3, 2014 at 9:16 PM, Sam Hartman  wrote:
>> "Don" == Don Armstrong  writes:
>
> >> Personally, I agree that having multiple active discussion/second
> >> periods on debian-vote is problematic.
>
> Don> Right; that's what we seemed to agree on as well.
>
> Don> I think that we can all agree that we'd like a decision on this
> Don> amendment significantly before January 1st, which presumably
> Don> means having it formally proposed well before December 3rd.
>
> OK.  So there is some time pressure.
> I personally  don't see any problem with that going on while the CFV for
> the previous resolution is in place.
> So, I think my comment about acting in a week or so seems about right.
>
> I'd find arguments of the form "I personally would find it confusing/bad
> to have both going on because ..."  more compelling than arguments of
> the form "it would generally be confusing/bad."  What I'm saying is that
> I'd be a lot more sympathetic to delay more than a week or so if people
> come forward and say they personally would like to delay more than if
> they say that some nebulous we/it would be a good idea to delay more.
>
>
> --Sam

I'll say that I agree with the TC members who have spoken up.. I am a
subscriber to -vote, and am still trying to sort out how I'm going to
vote, but I am just burnt from all the email traffic.

Starting another GR process right now, would almost definitely push me
into that camp of DDs that tends to ignores voting.

IMHO, the lists definitely do need a cool down period, and am grateful
the TC members aren't pushing this right now.

-Brian


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cacfairzw8fkrx6sbyw6qavhcseyg_siajc9m+5thhossvah...@mail.gmail.com