Re: How do you manage debian mails on your mailbox?

[Ole Streicher]

Hi Nilesh,

Nilesh Patra  writes:
> - - Do you use your primary email address for debian stuff as well,
> or is it a different one?

I use a separate mail account for Debian, separated from my personal and
from my work one.

> - - Do you have any sensible way to cope up with so many mails from
> different mailing lists and not potentially miss out on something important?

My way is to use an nntp gateway (sn) and read the mail with a news
reader (emacs gnus in my case). That makes it very easy to go through
them quickly and to not miss one.

Works nicely for me since I started with Debian ~10 years ago, with only
very few small drawbacks.

Cheers

Ole

Re: Welcome new Debian Developer: tar

[Ole Streicher]

Dear Gürkan,

I am happy to hear this! Congratulations!

Cheers

Ole

Jonathan Carter  writes:
> Greetings!
>
> Congratulations and welcome to Gürkan Myczko , who has completed
> the NM process and is now a full
> project member and an uploading Debian Developer.
>
> Thank you for your contributions to Debian!
>
> -Jonathan, Debian Project Leader

Re: Salsa as authentication provider for Debian

[Ole Streicher]

Ulrike Uhlig  writes:
> On 08.04.20 13:50, Shengjing Zhu wrote:
>> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank  wrote:
>
>> 1. Can you still keep the "-guest" enforcement, so it's still easy to
>> recognize who is DD or not on salsa?
>
> Could you explain a bit better why you think that this is needed?
>
> I understand you want to recognize DDs from other contributors, but why?
> Does it help you with permissions, does it help understand who someone
> is, or is it a habit that has been there since Alioth?

I don't know the exact proposed rules here, but I could imagine that
without these rules anyone cann fill the namespace of nice Debian user
names. And there is the danger that someone hijacks the user name of a
Debian user who is still not on Salsa. Or an emeritus name or so.

I would also like to have a visible distinction between "trusted" names
(where the owner is verified via key) and random names, in one way or
the other.

Cheers

Ole

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Ole Streicher]

Scott Kitterman  writes:
> On December 28, 2019 2:30:54 PM UTC, Sean Whitton
>>For packages with simple copyright and licensing, there are useful
>>things you can do with a freeform copyright file which you can't do
>>with a machine-readable file.  See for example the contribution
>>information in the copyright files of src:dgit and src:mailscripts.
>
> Also, please consider the impact on new contributors.  This list of
> somewhat arcane policies and procedures that new contributors need to
> learn us already long.  Adding to it raises barriers to contributing.

Trying to get people involved into Debian, I see this completely
different: It is much simpler to tell people to basically fill out a
sheet with fields like "Files", "License", "Copyright" then to tell them
that they should "somehow" merge all licenses together into a single
copyright.

The machine readable form guides people to look into all individual
files and to document the copyright. The actual pain is not the format
but the need to *do* the review.

Best regards

Ole

Re: Debian and Non-Free Services

[Ole Streicher]

Thomas Goirand  writes:
>> No, it just means "This is the canonical location for the packaging
>> repository." Nothing more. There is no information about the workflow
>> preferred by the maintainer.
>
> So, if someone is not using Github's "advanced" features, like pull
> requests and so on, why that person would care about using Github more
> than using Salsa?

Maybe they has already a Github account and does not want to create
another one as long as this is not really necessary. Maybe they is more
familar with the Github user interface than with the Gitlab one. Maybe
they thinks that the repository is better visible if on Github. Maybe
they does the job for an institution which requires to have the
repositories in the institutional organization. Maybe the primary
packaging is done for another distribution (or a special repository).

Sure: most of these are not really strong reasons, and I would always
try to convince people to move to Salsa. And for Debian Astro (as for
many other teams), the requirement is to have the repository on Salsa,
and I am fully behind that.

But that still does not mean that I see reasons why people use Github
for Debian packages and (to come back to the original discussion) having
a repository on Github does *not* automatically mean a preference in the
workflow. So, if someone has the repository there, you can still expect
that BTS patches are welcome. You stated the opposite, that that was all.

>> And, BTW, sometimes contributing to a Debian package requires
>> communication with upstream (creating a bug report or discussing a
>> patch); in this case you cannot avoid the use of non-free services
>> anyway, since you are then bound to their choice of services.
>
> This is bound to the choice of each package maintainer, and has nothing
> to do with the rules for packaging within Debian. In other words: what
> you are discussing is IMO off-topic.

Your (?) argument was: contributing to a Debian package shall not
require to use non-free services. My counter-argument is: contributing
to a Debian package often requires communication with upstream (provide
patches, look for fixes from upstream etc.), where non-free service may
be involved. So, the goal of not requiring non-free services cannot be
reached anyway.

Nevertheless, I see many good reasons why we should enforce people to
use Salse. Homogenizing the packaging a bit makes team maintenance a lot
easier, allows better QA, non-discriminating access (didn't Github
exclude Iran developers a while ago?) etc. But "not enforce people to
use a non-free service when contributing to Debian" is IMO not
convincing.

Cheers

Ole

Re: Debian and Non-Free Services

[Ole Streicher]

Hi Thomas,

Thomas Goirand  writes:
> On 9/13/19 2:35 AM, Scott Kitterman wrote:
>> It's based on a false premise.  No one is forced to use any VCS to
>> maintain Debian packages.  If you don't want to talk to GitHub, send
>> a patch to the BTS.
>
> If one slenderizes about a particular VCS URL, it means it is where he
> wishes to have pull/merge requests from. Otherwise, what's the point?

No, it just means "This is the canonical location for the packaging
repository." Nothing more. There is no information about the workflow
preferred by the maintainer.

You may guess that people using github accept pull requests, but you
even can't see whether they actually like them -- there are many reasons
why people use github, and PRs may not necessarily the specific reason
for the repository.

On the other hand, you *know* that BTS patches are accepted, so I do not
see why they would not be the preferred way when in doubt.

And, BTW, sometimes contributing to a Debian package requires
communication with upstream (creating a bug report or discussing a
patch); in this case you cannot avoid the use of non-free services
anyway, since you are then bound to their choice of services.

Best regards

Ole

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Ole Streicher]

Mo Zhou  writes:
> Is the recommendation working well under most circumstances?
> I mean, different teams have already made their conventions
> at these point, such as go team, rust team, nvidia team, etc.
> These team designed "local" recommendations always adapt
> well with special property of their corresponding ecosystems.
> Designing a convincing "global" recommendation that works
> nearly everywhere is difficult.

Is there an overview how many teams deviate from the proposed
recommendations, and how much? Maybe first these teams should be
convinced; this would already give a big impact.

(I have no idea here; the teams where I am contribute to seem to be all
more or less in line)

Cheers

Ole

Re: Upstream metadata to help our users contribute back to projects we redistribute.

[Ole Streicher]

Felipe Sateler  writes:
> Are there tools that are actively using this information? Unfortunately, 
> the links you quote below do not provide much information about where 
> this information is used (other than bibref table in UDD).

For the (science) Pure Blends, this information is displayed in the
tasks pages:

https://blends.debian.org/astro/tasks/iraf#iraf

Best

Ole

Re: Cultural differences and how to handle them

[Ole Streicher]

Marc Haber  writes:
> On Wed, Jul 03, 2019 at 10:32:04AM -0600, Jason Crain wrote:
>> On Wed, Jul 03, 2019 at 05:40:54PM +0300, Adrian Bunk wrote:
>> > In this gay pride month discussion what is politically correct for 
>> > people in the US is considered offensive by people in Germany, and
>> > what would be considered politically correct by Germans would be 
>> > considered offensive by people in the US.
>> 
>> I have a hard time believing that German culture prevents you (or
>> Debian) from supporting gay pride,
>
> That is not what Adrian tried to say. Don't try turning his words around
> against him. No German company would change its logo for a pride month,
> and if they did, other minorities would sue for their own logo month on
> basis of discrimination.

It is not a company, but the Berlin government (text in german):

https://www.rbb24.de/panorama/beitrag/2019/07/pride-berlin-csd-lesbisch-schwul-stadtfest.html

Caption: "Pride weeks start: Berlin town hall hoist the rainbow flag"

And if I remember correctly, Travis CI, which *is* a german company
(Rigaer Straße 8, 10247 Berlin, Germany, just in my neighborhood) had a
gay pride logo last year on their web page.

As I said: this is not an anglo-german cultural conflict.

Best reards

Ole

Re: Cultural differences and how to handle them

[Ole Streicher]

Adrian Bunk  writes:
> In this discussion here we have two pretty distinct groups of people:
>
> The first group has the opinion that Debian should honor various 
> minorities, and that Debian in general should have also a political 
> mission.
>
> The second group is unhappy with people being honored by Debian for 
> non-technical reasons, and wants Debian in general to be a non-political 
> technical project.
>
> Easy to miss, but obvious once you are aware of it:
> The people with English as native language are in the first group.
> The people with German as native language are in the second group.

Sorry, but can we stop this a bit?

Being german, I think that Debian should honor discriminated minorities,
and I also think that it is impossible to encapsulate the politics from
a technical project. And I am sure that I am not the only one. At least
my professional and personal environment goes into the same direction.

If you like, you can even derivate that from the german history.

People are not only formed by their national culture. They are as well
formed by their professional contacts, by their friends, by the way they
get information and so on.

The conflict that we have here is not an anglo-german (or other)
cultural one. It is one of the specific people involved in Debian, who
are only a very small, absolutely non-representative portion of the
population of any country.

Best regards

Ole

Re: Debian supports pridemonth?

[Ole Streicher]

Marc Haber  writes:
> Why dont we just welcome people based on the technology they care for?

To bring an example from my own professional work (astrophysics):
At the 233th conference of the American Astronomical Society (AAS), Jan
2019, there was a plenary talk by Caitlin Casey, Assistant Professor at
University of Texas. One of the undoubtly well-respected members of our
community.

The talk was about an astronomical topic (high redshift universe), but
*each* of her transparencies had a small footnote describing sexual
discrimination or harassment that she experienced.

For me, this shows: minority people, even women in "civilized"
countries, in higly educated environments, in the present have to cope
with bad experiences that are at least rare for white male US or
european citizens. We can't just ignore these experiences, and they make
a difference.

Ofcourse, we welcome everyone. But it is important to explicitly state
that we welcome those who are traditionally discriminated or bulled, and
that we ensure an atmosphere which does not tolerate discrimination,
harassment, or bullying behaviour.

Best regards

Ole

Re: Publicly-readable list for only DDs and DMs to post to

[Ole Streicher]

Scott Kitterman  writes:
> I do think the example of Ubuntu splitting ubuntu-devel into ubuntu-devel and 
> ubuntu-devel-discuss may be a relevant data point.  As an active participant 
> in Ubuntu development both before and after the split I paid attention to it 
> (and remained subscribed to ubuntu-devel-discuss long after most other 
> developers had unsubscribed).

I would in opposition think that having ubuntu-devel and
ubuntu-devel-discuss was a bad decision.

As a Debian Developer, I from time to time have a question about how
things are working in the Ubuntu Development. But since I am not an
Ubuntu developer, I can only use the -discuss mailing list. Since, as
you describe, many developers just unsubscribe there, my questions
always have a good chance to remain unanswered, which is at the end bad
for Ubuntu as well -- since I may solve someting non-optimal for Ubuntu,
or even frustated unsubscribe as well there.

The big Plus on Debian is that we have a -devel list that is reachable
for everybody, and the threshold to participate is low. When I try to
get people involved in Debian, I always mention that they can discuss
their issues with the development there when they see a need. Having
the discussion exclusively for the DDs (and DMs) would break our
openness. 

So, I would vote against such a mailing list. If one sees the need for a
filtered one, he could just setup a filter and let only @debian.org
addresses pass.

Maybe, one could provide some statistics in how big the noise is
actually in debian-devel?

Best regards

Ole

Re: third-party packages adding apt sources

[Ole Streicher]

Vincent Bernat  writes:
>  ❦ 19 mai 2016 18:04 +0100, Ian Jackson  :
>>> b) many upstreams appear frustrated about getting their package
>>> officially supported in Debian.  Sometimes there is good reason their
>>> package doesn't belong in Debian but sometimes it is more about inertia
>>> in Debian or the upstream isn't aware about backports and thinks their
>>> package will be stuck at a particular version forever
>>
>> Providing a proper Debian source package is also a lot more work than
>> writing some kind of ad-hoc build system that spits out a .deb or
>> three.
>
> Totally agree. Our standards are far too high for many upstreams.

which is a Good Thing.

I usually put quite much effort to bring the packages to the Debian
level, and at the end many upstreams are convinced that our standards
help them as well on the long run.

Best

Ole

Re: third-party packages adding apt sources

[Ole Streicher]

Antonio Terceiro  writes:
> On Fri, May 20, 2016 at 07:26:28AM +0200, Vincent Bernat wrote:
>>  2. packages can disappear at any time
>
> If they are broken. In my book that a feature and not a bug.

>From the user's perspective, they are also often *not* broken. Just take
the "pandas" package as an example. The package was removed from testing
due to some RC bugs, which are now resolved. However, now the packages
do not build on many platforms, so the migration to testing fails.

For an amd64 machine (which most of the users have), the package works
fine, and from an user's view the package is just not broken. It
disappeared and he can (as long as he has no good knowledge about the
package management) not solve this. The situation gets even more
complicated when the user is not using "python3-pandas" directly, but as
a dependency of another package.

This behavious may be useful for a development platform, but for an end
user this is just inacceptable. Just think if this happens with the only
email program or web browser the user knows about.

Best regards

Ole

Re: does Debian help detect gravitational waves?

[Ole Streicher]

Yaroslav Halchenko  writes:
> We could continue this discussion and my replies would be like
> - NeuroDebian is not a derivative, all our work targets stock Debian
>   distribution (sooner or later). We are more of an extension ;) (aren't
>   blends are as well?)

In my opinion, that is the point: NeuroDebian does not look any
different to me than f.e. DebiChem or Debian Astro, or DebianMed. It has
some interesting developments however (the extensive backports solution,
f.e.)

Therefore I don't see a reason why it is not listed on
.

Best

Ole

Re: does Debian help detect gravitational waves?

[Ole Streicher]

Hi Yaroslav,

thank you for your answer! I has many ideas how to improve things for
Debian-Astro. BTW, is there a reason why NeuroDebian is not a Debian
Pure Blend? Is it part of DebianMed?

Yaroslav Halchenko  writes:
> FWIW, as some might not know, in NeuroDebian project
> (http://neuro.debian.net) we are consciously trying to package any of
> software we maintain so backport builds can be done automagically
> without major additional investment of time with a helper script, see
> for that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660208 and
> up-to-date version is always available from e.g.
> http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/backport-dsc

This looks like a useful tool! Wouldn't it make sense to put it into the
devscripts package?

>> Data analysis is here probably different from storage clusters or web
>> servers.
>
> ;)  I would say that "it is easier", since usually those (analysis
> suites) are leaf packages and thus there is fewer of dependents, so
> providing a new backported version is of lower risk to brake anything.

Sure. Well, almost. We have some packages which are really basic for
others (cfitsio, wcslib, astropy), and some of them are in a rapid
development.

> What I would encourage though is to enable build-time unit-testing.  It
> was of paramount importance/help to us at least, since then we
> catch possible incompatibilities at build time and never ship a backport
> which we know wouldn't work on older system.

Right. I also find the CI tests important, and it would be great to
extend them to backports, experimental and such.

Best regards

Ole

Re: does Debian help detect gravitational waves?

[Ole Streicher]

Adam Borowski <kilob...@angband.pl> writes:
> On Sun, Feb 14, 2016 at 02:31:34PM +0100, Ole Streicher wrote:
>> There are some problems why Debian is not soo widely used in the science
>> analysis (yet): One is that due to our long freeze many important
>> packages are already outdated when the stable release comes out.
>
> Well, they're using oldoldstable and old^3stable, so it doesn't appears as
> if they rely on newest versions of packaged tools.

It probably varies with the group. I discussed about the inclusion of
the analysis suite, and there the argument was that it would be outdated
in stable already when it comes out.

Data analysis is here probably different from storage clusters or web
servers.

Best regards

Ole

Re: does Debian help detect gravitational waves?

[Ole Streicher]

Yaroslav Halchenko  writes:
> So I guess Debian was of some notable help, and I am really glad that our work
> at least tiny bit contributed to this event.  But that is it.  Somewhat
> twisting while overall agreeing with the point of Aurelien's reply --
> Debian was probably used somewhere along the way of any recent sizeable
> research endeavor simply because it is used in so many scenarios and places.

In the past I had a bit contact to LIGO people -- BTW, the healpy
package has a LIGO employee as uploader -- in order to convince them to
contribute to Debian Astro.

There are some problems why Debian is not soo widely used in the science
analysis (yet): One is that due to our long freeze many important
packages are already outdated when the stable release comes out. This
may be solved by backporting -- however I still never did that and I am
afraid that I will not have the time to do it on the long run. So, if
anyone wants to volunteer backporting some important astronomy (or
science) packages, go ahead. This will increase our impact in that area.

The other problems are not so simple to solve: licensing (not everything
is DFSG compatible), poor software quality, local patches to standard
packages.

However, if we could take the gravitational waves to boost our efforts
in science: that would be great!

Cheers

Ole