Re: [RFC] Extending project standards to services linked through Vcs-*

[David Bremner]

Diederik de Haas  writes:

> I would really like that all packaging is *available* on Salsa, even if it is 
> just in readonly 'mode'. Some don't have any Vcs repo listed and that makes 
> contributing much harder then needed.
>
> I'm fine if maintainers don't want to deal with Salsa MRs, even though I find 
> it 
> convenient. But knowing *how* contributions can be made would be welcome.
> So something like  a "Patch-submission" field (in debian/control) seems 
> useful.

I have a project currently hosted off salsa. I'm willing to have
read-only mirror, but I'm not willing to put much effort in to it.
Maybe someone(TM) should take on the task of mirroring, in some way that
makes it clear this is not a place to send MRs. In a small way, that
could be a technical (partial) solution to a social problem. It could
even be automated based on Vcs-Git urls.

Re: ppc64el porterbox replacement: plummer.d.o -> platti.d.o

[David Bremner]

Aurelien Jarno  writes:

> Dear all,
>
> We lost access to the Power9 machine hosted at Unicamp, which was
> hosting the ppc64el porterbox called plummer.d.o. A new porterbox called
> platti.d.o has been setup as a replacement.
>
> Regards,
> Aurelien


It would be nifty if someone (TM) would update where
ppc64el-porterbox.debian.net points to.

ta

David

Re: (Lack of) GDPR compliance in Debian

[David Bremner]

Russ Allbery  writes:

> (If you do open source work outside of the auspices of an organization
> that carries insurance and you have assets to protect, it's worth
> considering a personal umbrella policy.)

Obviously it's not Russ's fault, but...

I hate that we live in such a world.

d

Re: Do we want to try to find consensus before a GR?

[David Bremner]

Sam Hartman  writes:

> Folks here, would you rather me try and find out how far we can get on
> debian-devel using methodology similar to the debhelper discussions, or
> would you rather Thomas draft GR text and look for seconds?

I think we ought to try _something_ before a GR, and the methodology
used for the dh discussion seems worth a try. If nothing else, it could
serve to help clarify whether we need a GR on the topic, but may also
have some more (IMHO) positive outcomes.

d

Re: Replace the TC power to depose maintainers

[David Bremner]

Sheetal Shalini  writes:

> Hi
>
> How do I unsubscribe from Debian Project mailing list?
>

see the instructions on

https://lists.debian.org/debian-project/

Re: Planned changes to Debian Maintainer uploads

[David Bremner]

Jon Dowland j...@debian.org writes:

 Have any of these issues been a problem practically, yet? Or are they
 just potential problems for the future?


I'm not sure if this counts as a practical problem in your view, but it
is rather common for DMs to set the DMUA flag in an initial request for
sponsorship. In my view this goes against the spirit of the DM system,
since it is unlikely for a sponsor to be confident in the ability of a
given person to handle a given package on the first upload.

d


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762aycdi9.fsf@zancas.localnet

Report from the debconf11 sponsoring/mentors BoF.

[David Bremner]

This report started as a summary from the sponsorship BoF held during
Debconf 11 in Banja Luka.  The full video stream is available on [0].
These were the major points, as interpreted by Arno Töll and David
Bremner.  As it was being written up, a few relevant things happened
with debexpo (mentors.debian.net) and/or were discussed on the list,
so we added some pointers to those as well.

Q: Why does Debian sponsor uploads?
- ---

Many present agreed that the main reason to sponsor uploads is
training.  New contributors need experience and training to get
packages in shape. Therefore the mentoring process can be seen as
incubator to develop new (uploading) Debian developers. One impression
to support this is that as new contributors tend to package software
for a fairly narrow target group.

On the other hand, several people outlined the technical benefit of
sponsoring packages, which is to get new software (typically that the
sponsors themselves consider useful or interesting) into Debian.
Similarly sponsors upload packages which have been orphaned by the former
maintainer.

Debian has several teams, at least some of which are highly effective
at mentoring, and all of which have more specialized expertise than
the debian-mentors mailing list.  In principle the mentoring process
should generally endorse people to join existing teams. This is
mutually beneficial, as new contributors learn best practices and
workflows while helping with the workload of teams.  Unfortunately
apparently [1] only 20% of all RFS requests appear to be related to
the work of existing teams.

Q: How are we doing, what could we improve?
- ---

Several problems were identified with mentoring process (or with the
experience of mentees). Broadly speaking these are in the (overlapping)
areas of making connections with sponsors, getting feedback, and
variability/fairness.

There was some discussion about how people have succeeded in finding
sponsors, and how sponsors like to be found. One or two people
mentioned only succeeding because of a pre-existing social
relationship. Most, but not all, sponsors preferred email over IRC as
a contact point.

Lack of feedback in the mentors process is a problem for several
reasons.  The current mentors process has a fairly large degree of
uncertainty.  Often it is unknown to sponsorees how they are doing as
there is no (visible) progress or feedback at all. This is
discouraging for new contributors.  In fact the mentors FAQ already
gives some ideas about what to do in this case (ask on IRC, ask again,
and so on). It isn't clear how much people read this FAQ, maybe some
automatic messages could be generated from mentors.debian.net with
hints about future steps.

Another, quite different problem with the mentors process is that it
seems based on the false assumption that every package belongs to
Debian.  Many packages are either too immature or don't add anything
really new to Debian.  We should be willing to tell people this,
rather than politely ignoring packages and hoping they go away.

Debian is supposed to be Do-ocracy, in particular as many decisions
as possible are left to the individual developer. From the sponsoree
perspective the result is a bit chaotic: they hear different stories
about what is mandatory and what is suggested. There is also the
element of developer taste, which varies widely in terms of what
software they find interesting and worthwhile.  This can result in a
high quality package providing software for special interests gets
lost, while a less good package but targeting a more popular area of
interest is sponsored. There was no concensus about whether it was
possible (or desirable) to change these subjective aspects, but see
below for a technical proposal about matching packages and sponsors.

Recently, Michael Gilbert asked to switch the reviewing part of the
mentoring process to the Debian Bug Tracking Systems (BTS) [2]. If you
are sponsoring packages or being a sponsored maintainer, please tell
us your opinion here, as there are possible improvements over the
current procedure observable, as well as concerns. Help us to find
the best solution.

Q: Should there be a mentors team, or some other structure?
- ---

The discussion, whether there should be a mentors team can be seen
From two perspectives. First, one could see it as team which looks for
lost and lonely packages, and sees as last resort, whether it could
be uploaded to Debian. Generally this idea did not seem to attract many
persons in the audience.

Alternatively, this could be seen as collaborative maintenance team,
similar to the QA team (including its drawbacks), where sponsors and
maintainers get together to collectively improve packages. Some people
casted doubts on this idea as well, mentioning the QA team as refer-
ence, where everyone but effectively nobody feels responsible

dep5 appendix wording

[David Bremner]

Hi All;

Liw suggested I direct this comment on DEP5 to this list.

In the appendix of the DEP5 candidate, it is written: 

,
| The Debian Policy (§12.5) demands that each package is accompanied by a
| file, debian/copyright in source packages and
| /usr/share/doc/package/copyright in binary packages, that contains a
| verbatim copy of its copyright and distribution license. In addition, it
| requires that copyrights must be extractable by mechanical means.
`

In the context of DEP-5, I read that last sentence as suggesting that
machine interpretable copyright files are mandated by policy.  I would
suggest s/copyrights/copyright files/ to prevent others being confused
by this.  Probably something similar should be done to policy 12.5,
where the wording was borrowed from, since copyrights alone is
ambigious there as well.

d


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5aha46g.fsf@zancas.localnet