from:"Roberto C . Sánchez"

On Thu, Dec 26, 2019 at 06:01:40PM +0100, Jonas Smedegaard wrote:
> Quoting Roberto C. Sánchez (2019-12-26 17:29:52)
> > On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote:
> > > On Thu, 26 Dec 2019, Roberto C. Sánchez wrote:
> > > >So, what does the FTP team consider that we, as the wider 
> > > >community of Debian Developers, can do to help?
> [...]
> > > When there is a REJECT and the maintainer used a tool like 
> > > licensecheck, file a bug and let the tools become better.
> > 
> > One interesting thing about this is that I have often wondered if it 
> > would be beneficial to have checks on debian/copyright during the life 
> > of a package.
> 
> lintian does some continuous checks.
> 
> Doing it more aggressively requires (I guess¹) more work than is 
> currently available with licensecheck and related tools.
> 
> 
> > Checking only once when a package first enters the Debian archive 
> > seems to leave open the rather likely possibility that some change in 
> > a future upstream release changes or adds some component license that 
> > should be documented in debian/copyright.  I try to be diligent in 
> > this regard and even at times have found that I overlook things.
> 
> Keeping debian/copyright up-to-date is certainly an important and 
> *required* part of package maintenance!
> 
> Some use cme for automating this, I currently use licensecheck2dep5 - 
> again, please look at https://wiki.debian.org/CopyrightReviewTools for 
> options, and anyone having experience with other approaches please add 
> them to that wiki page!
> 
> 
> > In any event, a tool that can scan a source tree and produce a base 
> > debian/copyright file that I as a maintianer could edit would be a 
> > marvelous thing.  Would be possible to make the licensecheck tool dual 
> > use in that way?
> 
> You mean this?:
> 
>   licensecheck --recursive --deb-machine *
> 
> Other tools listed at https://wiki.debian.org/CopyrightReviewTools can 
> do similar/related tasks - in particular cme and licensecheck2dep5.
> 
> 

Thanks for the pointers.  I clearly need to update my knowledge
regarding the available options.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote:
> 
> 
> On Thu, 26 Dec 2019, Roberto C. Sánchez wrote:
> >So, what does the FTP team consider that we, as the wider community
> >of Debian Developers, can do to help?
> 
> What about being more careful when creating the debian/copyright for a
> package?
> I know it is boring, but writing a REJECT-mail is not much fun as well.
> Seeing a copy error once is ok, but seeing that in a bunch of
> packages, makes me wonder.
> Don't neglect fonts, pictures, sound files.
> 
I agree that this is a terribly boring thing to do when packaging new
software.  I cannot imagine how much more boring it would be for the
person performing the verification on the FTP team.

> When there is a REJECT and the maintainer used a tool like licensecheck,
> file a bug and let the tools become better.

One interesting thing about this is that I have often wondered if it
would be beneficial to have checks on debian/copyright during the life
of a package.  Checking only once when a package first enters the Debian
archive seems to leave open the rather likely possibility that some
change in a future upstream release changes or adds some component
license that should be documented in debian/copyright.  I try to be
diligent in this regard and even at times have found that I overlook
things.

In any event, a tool that can scan a source tree and produce a base
debian/copyright file that I as a maintianer could edit would be a
marvelous thing.  Would be possible to make the licensecheck tool dual
use in that way?  The FTP team could use it when validating and
developers could use it for creating the initial debian/copyright.

Then it might also serve as the basis for a lintian check (when the
quality is sufficiently high), or some other process whereby ongoing
checks of debian/copyright could be performed.

> (I tested some commercial tools a while ago and they were extremely bad in
> detecting correct licenses.)
> 
> Make the machine-readable copyright file mandatory.
> It is much easier to "parse" than just a bunch of copyright information.
> 
Yes.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

On Thu, Dec 26, 2019 at 08:53:43AM -0500, Roberto C. Sánchez wrote:
> 
> So, what can we, as the wider community of Debian Developers, do to
> help?

Replying to myself.

I recognize that this thread contains varying suggestions as to how to
improve the situation.  My question should have perhaps been phrased
more definitively:

So, what does the FTP team consider that we, as the wider community
of Debian Developers, can do to help?

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

On Thu, Dec 26, 2019 at 04:05:20AM +, Mo Zhou wrote:
> However, accelerating the recruitment process of ftp team looks quite
> difficult to all participants, including the ftp-masters and the trainees:
> 
> ftp-master:
>  * time and energy is limited. doesn't have enough resource to provide
>too much feedbacks to the trainee
>  * wants to make sure every new member will be qualified enough to take
>this important role.
> 
> trainee:
>  * limited time and energy. generally not able to produce a large amount
>of reviews to the NEW packages in a short period of time
>  * lacks feed back. they don't know how are they actually doing in
>reviewing the NEW packages.
> 
> So accelerating the recruitment process is not easy, given that we will
> not lower our quality standards.
> 
An application of the principle that "adding more programmers to a late
project makes it later" (from _The Mythical Man-month_) to this
situation leaves us with possible ways forward:

1. maintain the status quo and accept that FTP master tasks will
necessarily include a very large built-in delay in completion time

2. accept a further reduction in responsiveness/slow down now and for
some, perhaps indeterminate, period of time to allow for dedicating a
certain amount of effort to train extra team members (which seems to
require a high degree of close collaboration and supervision with lots
of feedback); after some time the team's productivity should increase
and surpass its current level

Speaking as someone who has had uploads processed through NEW in a
matter of days (and been very pleasantly surprised) and also still with
a package that is approaching a year in NEW (and being a bit
disappointed with that), the second of the above scenarios seems to be
by far the more sustainable and productive approach from the long-term
perspective.

So, what can we, as the wider community of Debian Developers, do to
help?

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Some thoughts about Diversity and the CoC

2019-12-18 Thread Roberto C . Sánchez

On Wed, Dec 18, 2019 at 02:36:41PM +, Matthew Vernon wrote:
> Gerardo Ballabio  writes:
> 
> > I had thought that there was room for a dissenting opinion, but
> > clearly there isn't.
> 
> You can think what you like - the requirement is that you treat people
> in Debian with respect, 

Such a requirement, if it does in fact exist, is certainly not equally
applied.

> which means (in this case) that if you use
> pronouns to refer to them, you endeavour to use their preferred
> pronouns.
> 
Should we also endeavour to be respectful to those who hold policital
views, religious beliefs, or even general opinions with which we
disagree?  The trend I have observed within Debian seems to be more
toward disrespectful treatment rather than respectful treatment.

> The CoC is about behaviour.
> 
If anything, "behaviour" seems to be worse now than it was before.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Cultural differences and how to handle them

2019-07-04 Thread Roberto C . Sánchez

On Thu, Jul 04, 2019 at 10:18:18AM +0200, Raphael Hertzog wrote:
> On Wed, 03 Jul 2019, Roberto C. Sánchez wrote:
> > On Wed, Jul 03, 2019 at 05:33:25PM +0200, Ole Streicher wrote:
> > > Being german, I think that Debian should honor discriminated minorities,
> > 
> > Being a discriminated against minority, I think Debian should *not*.
> 
> And since Debian is do-ocracy, it's not your call. You can disagree with
> the publicity team, but it's their call and a call they made while trying
> to put our diversity statement into application.
> 
My position is not one of disagreement without basis.  I have found,
through my own experience, that diversity efforts (including those like
the pride month logo Debian logo change) end up doing more harm than
good.  By that I do not mean that they hurt the feelings of majority
groups (though that may be an associated affect), but rather that in
the end such efforts often further marginalize those for whom the "help"
is meant.

The point of Debian being a do-ocracy is not lost on me.  In fact, when
it comes to technical matters, it is the superior approach.  Even in
difficult technical matters (like the init system debate) where the
choices amount to "do this" and "do nothing" there is a technical
committee which can act as arbiter.  However, when it comes to
non-technical matters, esepcially when one potential course of action is
"do nothing," there is no such possibility.

Those who wish to "help" marginalized groups by displays such as the
pride month support have an avenue to "do" what they believe is best in
this do-ocracy of ours.  What course is available to me and those like
me who believe we should "do nothing"?  It would seem that public
discussions that attempt to address that are met with great resistance
and with many attacks against the character, motivations, and
demographics of those who hold that position.

> Can we stop this discussion now, please?
> 
Since it seems like on this occassion and at least one prior occassion
my expression of my position/opinion on what Debian as a project should
or should not do based on my own experience with discrimination and
supposed diversity efforts has been met with multiple responses of the
general sentiment "be quiet, your opinion is not wanted here, let the
others speak," I can only conclude that I have not been sufficiently
oppressed to have my opinions count.

> Unless you really want to revert their decision via a general
> resolution... but even in that case, the discussion here doesn't help to
> go forward with this.
> 
Perhaps you feel like this discussion doesn't help because nobody has
ever tried to "help" you by targeting a diversity effort at you.

-- 
Roberto C. Sánchez

Re: Cultural differences and how to handle them

2019-07-03 Thread Roberto C . Sánchez

On Wed, Jul 03, 2019 at 05:33:25PM +0200, Ole Streicher wrote:
> 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,

Being a discriminated against minority, I think Debian should *not*.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Debian supports pridemonth?

2019-06-28 Thread Roberto C . Sánchez

On Fri, Jun 28, 2019 at 11:59:36AM -0700, Russ Allbery wrote:
> Roberto C. Sánchez  writes:
> 
> > Hispanic Heritage Month is coming in a few months (at least in the US,
> > not sure about international observances).  Perhaps Debian could make a
> > public show of support for those of Hispanic origin (who tend to be
> > drastically underrepresented in the community).  We already missed Black
> > Heritage Month this year in the US, but it is coming in October for
> > Europe and will come round again in February in the US.  Blacks, or
> > African-Americans, are similarly underrepresented in the community.
> 
> > Perhaps we could also show support for Jews and those of Jewish origin
> > during one of the principal festivals (Passover, Weeks, or Tabernacles).
> 
> I think this would be great.  Explicitly saying to our various communities
> on days of significance to that community that they are welcome and
> supported in Debian seems like a warm-hearted and open gesture, and I
> fully support it.  My employer does this for four or five of the events
> that are the most significant to company employees, and it's always very
> welcome.
> 
> The criteria I'd use (because we do have to draw some sort of line
> somewhere, since there are more days or months like this than there are
> days and months in the year if you look hard enough) is to let the
> relevant community in Debian take the lead.  That also avoids the
> occasional issues where there is some supposed recognition of a group that
> is controversial or unwanted within that group, which happens from time to
> time because humans are complicated.
> 
> So, we should look to our LGBTQ project members to decide what Debian
> should do for Pride, to our Hispanic members to decide what Debian should
> do for Hispanic Heritage Month, and so forth, since they're the experts on
> what they would find the most meaningful within the Debian context.
> 
That's very reasonable.

-- 
Roberto C. Sánchez

Re: Debian supports pridemonth?

2019-06-28 Thread Roberto C . Sánchez

On Fri, Jun 28, 2019 at 08:56:03AM -0400, Sam Hartman wrote:
> Hi.
> Responding only to one thing at this time, and apologies if it has
> already been covered.
> 
> This was discussed by the debian publicity team who is delegated to do
> this sort of thing.  In particular, they are charged by the project and
> DPL to promote Debian consistent with its policies and their choices.
> Like most of our teams they have significant latitude.  In this
> instance, they are guided by the constitution which encourages delegates
> to respect project consensus/policies/positions.  So, they are guided by
> the GR approving the diversity statement.
> 
> This action was discussed on their public list.
> 
Hmm.  That's interesting.

The thread began with a message bearing the subject line "Small actions
and large impacts" on 2nd June.  The final message in the thread, dated
more than three weeks after the initial message and 19 days after the
most recent prior message, changed the subject to "Debian Diversity logo
in webpage, please update translations".  It included the following
text:

"We have changed the main website logo too (visible in every webpage
under www.debian.org), and published a micronews:;

That indicates that the change had already been made at that point.

It does not seem that anything was done with the intent to conceal the
action, nor do I mean to imply such.  However, the start of the thread
was practically invisible (especially for someone monitoring many
Debian-related mailing lists).  I would be surprised if more than a very
small handful people even knew such a change was in the works.

Perhaps there should be an effort to better highlight such highly
visible things before they take effect?

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Debian supports pridemonth?

2019-06-28 Thread Roberto C . Sánchez

On Fri, Jun 28, 2019 at 12:29:55PM +0200, Jonathan Carter wrote:
> On 2019/06/28 11:48, Gerardo Ballabio wrote:
> > I do not think that this is appropriate. Welcoming diversity is one
> > thing, supporting pridemonth is another thing. Pridemonth is a set of
> > events with a definite political connotation. I don't think that
> > Debian should take sides on any specific political issues (except of
> > course issues that have a relation to free software), especially if
> > that hasn't been discussed at large among project members and there
> > isn't a clear consensus.
> > 
I personally think that a public statement such as this should at least
have been discussed among the project members prior to being made
public.

> > Is it just me (and am I being blatantly wrong, if so please enlighten
> > me) or do others share my concern?
> 
> Probably a bit of a stretch to call it political.

In other discussions Russ Allbery has articulated the entanglement
between Debian's objectives as a project and "politics" in various forms
(i.e., is Debian and/or free software inherently political?).  He did a
far better job explaining it than I ever could so I will not try to
replicate the discussion here, but my recollection is that he concluded
that in some ways being political cannot be avoided.

> As far as I
> understand, all that it's about is a shared stance against bigotry and
> letting people know that it's ok to be different and that we accept
> people from a wide variety of walks of life. Seems in line with our
> current policies so I don't really see much of an issue there.
> 
I understand it to be generally the same as well.

Looking at the history of vote.debian.org there have been GRs for far
less consequential matters.  To say that this one did not at least merit
a "by the way fellow Debian community members, next week the project
plans to announce blah blah blah" is perhaps not consistent with the
principle and goal of transparency that we uphold.

If this really is such a minor issue, I would like to offer some
suggestions for ways in which we can further strengthen our "shared
stance against bigotry and letting people know that it's ok to be
different and that we accept people from a wide variety of walks of
life."

Hispanic Heritage Month is coming in a few months (at least in the US,
not sure about international observances).  Perhaps Debian could make a
public show of support for those of Hispanic origin (who tend to be
drastically underrepresented in the community).  We already missed Black
Heritage Month this year in the US, but it is coming in October for
Europe and will come round again in February in the US.  Blacks, or
African-Americans, are similarly underrepresented in the community.

Perhaps we could also show support for Jews and those of Jewish origin
during one of the principal festivals (Passover, Weeks, or Tabernacles).

In addition to being underrepresensted, all of those groups have at
times in history experienced bigotry and persecution comparable to (if
not exceeding) that which became the genesis of pride observances within
the LGBT community.

> Debian isn't aligning itself with any specific political movement here
> so I think in that context, it's really a non-issue. Even if it were,
> there are going to be places where you're going to have to pick sides
> when protecting basic freedoms become political. This one is very
> uncomplicated though.
> 

Agreed.  This is as uncomplicated as the suggestions I made above for
Debian to show solidarity with similarly affected groups.  I hope that
we can do that with the same enthusiasm as in this instance.  There are
sure to be other groups which I have overlooked and hope that additional
suggestions are forthcoming from others.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: permissions

2019-06-05 Thread Roberto C . Sánchez

On Wed, Jun 05, 2019 at 02:34:30PM +0100, Ian Jackson wrote:
> Roberto C. Sánchez writes ("Re: permissions"):
> > On Wed, Jun 05, 2019 at 01:40:49PM +0200, nourdebian2...@tutanota.com wrote:
> > >Hi
> > >We thank you very much for your efforts and great achievements.
> > >I have a problem I want to solve.
> > >I have created another group and want to prevent it from connecting to 
> > > the
> > >whole machine except for one program either through the firewall or
> > >through the permissions.
> > > 
> > >I tried using chmod and removed the execute from the others but the 
> > > result
> > >was as if I removed the execution from the user who is me.
> > >What is the solution ?
> > >Is there a firewall solution at the software level? what is it ?
> > >Is there a solution using permissions?
> > >Thank you
> > 
> > To do what you describe requires a mandatory access control system
> > (SELinux and AppArmor are two popular choices).
> 
> I don't think this is correct.  For traffic originating with local
> processes, iptables rules can select on uid and gid.  

I interpreted "connecting to the whole machine" as including users
logged in locally.

> But this
> question belongs on -user.
> 

It certainly does.  My apologies for not redirecting appropriately.  It
seems that I have -user and -project mail going into the same folder and
I failed to take note of it previously.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: permissions

2019-06-05 Thread Roberto C . Sánchez

On Wed, Jun 05, 2019 at 01:40:49PM +0200, nourdebian2...@tutanota.com wrote:
>Hi
>We thank you very much for your efforts and great achievements.
>I have a problem I want to solve.
>I have created another group and want to prevent it from connecting to the
>whole machine except for one program either through the firewall or
>through the permissions.
> 
>I tried using chmod and removed the execute from the others but the result
>was as if I removed the execution from the user who is me.
>What is the solution ?
>Is there a firewall solution at the software level? what is it ?
>Is there a solution using permissions?
>Thank you

To do what you describe requires a mandatory access control system
(SELinux and AppArmor are two popular choices).

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: metaphors and feminism

2019-03-29 Thread Roberto C . Sánchez

On Fri, Mar 29, 2019 at 08:42:30AM +0100, Stacey Lee wrote:
[SNIP]
>If you want to be so picky, there is no way Molly can call herself
>a developer. Where is her code?

What is the basis for the assumption that a "developer" must show code
for his or her work?

It is interesting to me because while producing code is perhaps the most
traditional and visible way for a developer to be recognized as a
developer, during the years that I taught CS/CE at university I had many
students who considered themselves weak programmers.  I specifically
counseled every single one of them that writing code was only a small
part of being a developer.  For example, bug reports need to be written,
reviewed, triaged, reproduced, etc.  Test plans need to be written and
executed.  Team resources need to be managed, etc.  I saw how this idea
encouraged students who considered themselves weak programmers to find
that there are other aspects of being a developer that might be as
appealing to them as writing code is to others.

I do not know about Molly specifically, but to say that someone cannot
be considerd a developer without having written code demonstrates a
fundamental misunderstanding about what being a developer is in general.

[SNIP]
>Do the rest of us women have to give up coding and run around putting
>labels on men to become developers in this community?

Not at all.  There are many ways to contribute to Debian and writing
code is only one way.  If that is your preferred method of contribution,
then by all means jump right in.

>For me, being
>a feminist and being a developer don't mean the same things that they mean
>for Molly. Please don't let these women with their yellow vests,
>lanyards and whistles take that away from me.

The actions of another only take away what you allow them to take away.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Censorship in Debian

2019-01-04 Thread Roberto C . Sánchez

On Fri, Jan 04, 2019 at 10:47:05AM -0800, Russ Allbery wrote:
> Roberto C. Sánchez  writes:
> > On Fri, Jan 04, 2019 at 10:17:56AM -0800, Russ Allbery wrote:
> >> Scott Kitterman  writes:
> 
> >>> If censorship isn't the right word (and at best, it's not ideal), what's
> >>> the right word for the chilling effect on willingness to speak in public
> >>> due to the risk of being ejected from an organization like Debian?
> 
> >> Being an adult.
> 
> > That was uncalled for and inconsistent with the high bar you have set
> > for yourself in so many other discussions.
> 
> How was it uncalled for?  It says exactly what I meant.  I'm not saying
> anything at all about Scott's behavior; it's the very simple answer to his
> question.
> 
> I apologize for apparently giving you the impression that it was an attack
> on Scott.  I probably should have unpacked it a lot more.  But having to
> mediate your behavior to follow standards that you may not agree with or
> face consequences around what organizations will have you as a member is
> *exactly* being an adult.  This is how the world works.
> 
> You have to watch what you say at work, or you might be fired.  You have
> to be careful of what you say among groups, or that group may eject you.
> You have to follow the standards of an organization of which you're a
> member, or that organization will expel you.
> 
> This is just ordinary, perfectly normal adult behavior.  Everyone watches
> their behavior and their wording all the time.
> 
This explanation puts your earlier comment in a differnet light.  Thank
you for elaborating.

> The idea that there is any forum in which people interact as adults where
> there is no chilling effect on one's unfettered speech and where no one
> has to watch their language, tone, or presentation is pure fantasy
> nonsense.  Even 4chan has social norms and consequences for going against
> them.
> 
> People seem to feel they're unreasonably put-upon by having to think about
> what they're saying *at all*, but this is absurd.  Everyone else in the
> world is doing this all the time.
> 
I think that perhaps the source of Scott's concern (and to an extent my
own) is that it is not necessarily obvious where the boundary is when it
comes to Debian.  The uncertainty here is the problem.  I deal with it
by trying to remain well away from the boundary.  However, I can see how
some who view Debian as a forum for social interaction in addition to
technical interaction are rightly concerned.

Russel Stuart's earlier message on "Expulsions Policy" got me thinking
that it would be enormously helpful if there were a way to codify a
community standard the way that we have codified package policies.  At
least that would be more clear and less ambiguous than what we have now,
in the same way that writing down package policies does for the quality
of packages in the archive.

Sadly, I don't think that is in the realm of the possible.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Censorship in Debian

2019-01-04 Thread Roberto C . Sánchez

On Fri, Jan 04, 2019 at 10:17:56AM -0800, Russ Allbery wrote:
> Scott Kitterman  writes:
> 
> > If censorship isn't the right word (and at best, it's not ideal), what's
> > the right word for the chilling effect on willingness to speak in public
> > due to the risk of being ejected from an organization like Debian?
> 
> Being an adult.
> 
Russ,

That was uncalled for and inconsistent with the high bar you have set
for yourself in so many other discussions.

The word Scott is trying to find is most likely 'boycott':

  Boycott \Boy"cott\, n.
 The process, fact, or pressure of boycotting; a combining to
 withhold or prevent dealing or social intercourse with a
 tradesman, employer, etc.; social and business interdiction
 for the purpose of coercion.
 [1913 Webster]

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Planet Debian revisions

On Thu, Jan 03, 2019 at 05:50:03PM +0100, Joerg Jaspert wrote:
> On 15271 March 1977, Roberto C. Sánchez wrote:
> 
> > > And I sometimes remove blogs for them just going 5xx. A commit msg
> > > is fine.
> > I still think an email to the author would be a good thing in that case.
> > I have had parts of my site stop functioning and known of it for some
> > time.  An email from someone telling me that it is broken is something I
> > consider to be helpful.
> 
> In principle I agree. Now tell me, for a good chunk of the planet blogs,
> which email? Without investing lots of time to find out.
> 
I see your point.  My invalid assumption and my ignorance regarding the
implementation of Planet did not allow me to see that there was a
potential obstacle there.

> > > And who says a commi message is short? Write a novel, if you want.
> > > :)
> > I think we have enough flamewars ongoing at the moment that I am not
> > going to take the bait to start a philosophical/religious discussion on
> > the merits of short/concise commit messages :-)
> 
> But but, I was short, I only used 4242 words why I added a comma at that
> position!
> 
Just be sure to keep the first line to a maximum of 72 characters
followed by a hard line break and a blank line so 'git log --oneline'
looks sane.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Planet Debian revisions

I have built up quite a backlog of email, so I did not see that the
discussion had effectively concluded when I wrote my message.

On Thu, Jan 03, 2019 at 04:25:14PM +0100, Joerg Jaspert wrote:
> On 15271 March 1977, Roberto C. Sánchez wrote:
> 
> > Probably better to say something like, "When a blog is removed, the
> > committer should send a direct email message to the author of the
> > removed content explaining the reason for the removal."
> 
> Ah please not.
> 
> > That keeps potentially loaded statements from being recorded in commit
> > message forever.  It also allows the author something perhaps more
> > complete than a short sentence fragment in a commit message upon which
> > to base a decision on how to proceed.
> 
> And I sometimes remove blogs for them just going 5xx. A commit msg is fine.
> 
I still think an email to the author would be a good thing in that case.
I have had parts of my site stop functioning and known of it for some
time.  An email from someone telling me that it is broken is something I
consider to be helpful.

In any event, I don't think it is particularly important enough to
warrant changing something for which consensus has already been
established.

> And who says a commi message is short? Write a novel, if you want. :)
> 
I think we have enough flamewars ongoing at the moment that I am not
going to take the bait to start a philosophical/religious discussion on
the merits of short/concise commit messages :-)

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Planet Debian revisions

On Thu, Jan 03, 2019 at 02:47:00PM +, Ulrike Uhlig wrote:
> Hi!
> 
> Jonathan Carter:
> > On 2019/01/03 00:26, Joerg Jaspert wrote:
> 
> > Full text: https://wiki.debian.org/PlanetDebian/ProposedChanges
> 
> Looks good! I like it.
> 
> One tiny thingy based on a remark: I've looked up 'slur' in the
> dictionary and 'slander' and 'libel' seem to be synonyms that might be
> more widely known. Maybe a native speaker could confirm this.
> 
A slander or libel is something that attacks an individual's character,
like falsely accusing someone of corruption.  A slur, on the other hand,
might attack someone's race, ethnicity, gender, etc.

"Disparaging statement" might work better, as it would cover both.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Planet Debian revisions

On Wed, Jan 02, 2019 at 05:39:58PM +0200, Jonathan Carter wrote:
> 
> On #6 I was tempted to add "When a blog is removed, the committer should
> add a comment listing the posts that resulted in it being removed", but
> not sure if that's overloading it a bit too much.
> 
Probably better to say something like, "When a blog is removed, the
committer should send a direct email message to the author of the
removed content explaining the reason for the removal."

That keeps potentially loaded statements from being recorded in commit
message forever.  It also allows the author something perhaps more
complete than a short sentence fragment in a commit message upon which
to base a decision on how to proceed.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Debian's Code of Conduct, and our technical excellence

2018-12-29 Thread Roberto C . Sánchez

On Sun, Dec 30, 2018 at 12:51:19AM +0100, Martin Steigerwald wrote:
> Hello Roberto.
> 
> Roberto C. Sánchez - 29.12.18, 18:12:
> > Suppose for a moment that a project member [… hypothetical case …]
> […]
> > The reason I use the above example is because it is a difficult case
> > to handle.  The cases where harm is clearly intended are
> > comparitavely very easy to deal with.  Those in which harm may or may
> > not have been intended but in which harm may be perceived are more
> > challenging.
> 
> I wonder about what the point would be to discuss hypothetical cases 
> like the one you mentioned.
> 
> If there have been practical issues with the handling of code of 
> conduct, the behavior of the anti harassment team or the Debian account 
> manager team… as there appears to be from what I gathered from what I 
> read in recent threads about that, then by all means it is good to find a 
> solution.
> 
> But I see no point in discussing difficult, completely made up 
> hypothetical cases.
> 
OK.  Withdrawn.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Debian's Code of Conduct, and our technical excellence

2018-12-29 Thread Roberto C . Sánchez

On Sat, Dec 29, 2018 at 04:23:02PM +, Matthew Vernon wrote:
> Hi,
> 
> There have a few posts in recent discussions by people suggesting (or, at
> least, appearing to suggest) that there is a conflict between technical
> excellence and our Code of Conduct (or aiming to increase the diversity of
> our membership, or similar).
> 
Yet, situations will arise in which the two goals may incidentally come
into conflict.

> I think there is no such conflict, and that the idea that there is is in
> itself harmful.
> 
I think that the idea that there is not or cannot be such a conflict is
rather more harmful.

> In particular, "X does excellent technical work, so we should turn a blind
> eye when their violate our CoC otherwise the technical excellence of the
> project will suffer" is both wrong and harmful. If we want to achieve
> technical excellence, we will do so by having many talented people working
> together. If we restrict our talent pool to "people who are prepared to
> tolerate a toxic environment", then we are harming that goal.
> 
Your statement right here is a clear prioritization of the two goals in
a situation where they may come into conflict.  Only, you said a moment
ago that there is no such conflict.

> Our Code of Conduct is not an onerous restriction on behaviour, it's a tool
> to help us build the sort of environment in which excellent technical people
> will be able to do their best work.
> 

I agree with this objective, just as I agree with objectives of the
Social Contract and the DFSG.  It doesn't take much searching to find
instances where Debian as a project has had to prioritize one objective
over another.

In fact, one which arises frequently is the matter of freeness of a
piece of software.  The Debian project seeks to create the best possible
operating system and collection of software.  To that end, people
contribute what they believe to be the best possible components.  Yet,
if a particular package, regardless of how technically excellent it is,
does not meet the DFSG then it is not accepted.

I will give another concrete example which I believe illustrates the
potential for a conflict of the objectives.

[note that the foregoing is a made up scenario, if this resembles
anybody's real life experience, it is only by coincidence]

Suppose for a moment that a project member has been sexually abused at
some point by a Catholic clergyman and so finds things related to the
Catholic church to be unpleasant because they call to mind many
traumatic memories.  Suppose that another project member has a new child
and posts pictures of the christening taking place in a Catholic church
or perhaps marries and posts pictures of the wedding ceremony in a
Catholic church Some questions:

- If the first member were to request removal of the offending post,
  would that request be acceptable to make?
- Would it make a difference if the request included information
  regarding the past traumatic experience?
- If the first member were to say nothing but a third party were to make
  the request (whether on behalf of the first member or not), would that
  request be acceptable to make?
- If the second member refuses to take action (after all, they are just
  pictures of a baby christening or a wedding), then is that wrong?
- How should the second member be penalized or what corrective action
  should be taken?
- Would it be wrong or right to ask the first member to be more
  accepting?

The point is that here I have presented a situation that is not too
dissimilar from real situations that are likley to occur in the project
in which two or more individuals with a shared common of technical
excellence relating to Debian have encountered a conflict in the goal of
inclusiveness.  The first member is likely to feel excluded of they make
the aforementioned request and no action is taken, while the second
member is likely to feel excluded if they are requested to censor their
speech.  At no point is it necessary or even right to consider, "how
much is this person's technical contribution worth?"  Yet, the two
objectives are still found in conflict in the situation because either
path is the potential to result in diminished technical contribution to
Debian as a whole.

The reason I use the above example is because it is a difficult case to
handle.  The cases where harm is clearly intended are comparitavely very
easy to deal with.  Those in which harm may or may not have been
intended but in which harm may be perceived are more challenging.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Debian Sarge ARM-Version

2010-01-26 Thread Roberto C . Sánchez

On Wed, Jan 27, 2010 at 12:20:55AM +0100, protector wrote:
 Hello Debian team.
 
 I've got even a very specific question for you.
 
 Is it possible to download somewhere in the ARM version of Debian
 Sarge? I am aware that this version is very old, but I need exactly
 this.
 
http://www.debian.org/releases/sarge/

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: NEW queue

2008-10-24 Thread Roberto C . Sánchez

On Fri, Oct 24, 2008 at 05:49:25PM +0200, Joerg Jaspert wrote:
 
 What you saw is most probably a change in the code behind NEW which,
 since some time, gives precedence to packages that only add new binary
 components to the archive, not full source uploads. The idea being that
 those need way less time to process, which usually works pretty well.
 
I am wondering if this code change resulted in the random requeuing of
libtzinfo-ruby after it had already spent 2 weeks in NEW.  I uploaded it
and libmemcache-client-ruby at the same time.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: NEW queue

2008-10-24 Thread Roberto C . Sánchez

On Sat, Oct 25, 2008 at 12:42:34AM +0200, Joerg Jaspert wrote:
 
  What you saw is most probably a change in the code behind NEW which,
  since some time, gives precedence to packages that only add new binary
  components to the archive, not full source uploads. The idea being that
  those need way less time to process, which usually works pretty well.
  I am wondering if this code change resulted in the random requeuing of
  libtzinfo-ruby after it had already spent 2 weeks in NEW.  I uploaded it
  and libmemcache-client-ruby at the same time.
 
 This affects every package that only adds a new binary component.
 
Both were brand new source packages.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Developer Status

2008-10-23 Thread Roberto C . Sánchez

On Thu, Oct 23, 2008 at 03:51:47PM +0200, Pierre Habouzit wrote:
 On Thu, Oct 23, 2008 at 01:28:44PM +, Manoj Srivastava wrote:
  
  Can you comment on your motivations, please?
 
 Huh, I'd like to understand why all these people in Cc: have thought
 such a policy was so important it couldn't go through the usual Debian
 way of consensus, and was it looks like it's imposed to us without prior
 discussion. I assume it's because there is a very good reason to that,
 and I'm seeking it, so that I can judge the proposal on its (hidden to
 me right now) merits.

Actually, the merits of the plan are not hidden to you.  They are stated
and/or derived from the original post to d-d-a.  What is hidden (and
what you are apparently seeking) is the motivations.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: DEP1: Non Maintainer Uploads (final call for review)

2008-08-12 Thread Roberto C . Sánchez

On Tue, Aug 12, 2008 at 08:16:56PM -0300, Lucas Nussbaum wrote:
 
 The whole developers-reference is written in a non-gender-neutral
 manner. If there's consensus that it's a good idea, I would prefer if
 the whole devref was converted at once, instead of converting only this
 part.
 
Any particular reason why it must be gender neutral?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Social Contract ten years on July 5 -- celebration?

2007-06-26 Thread Roberto C . Sánchez

On Tue, Jun 26, 2007 at 05:12:51PM -0700, Steve Langasek wrote:
 On Tue, Jun 26, 2007 at 08:54:51PM +, Lars Wirzenius wrote:
  The Debian Social Contract 1.0 was ratified on July 5, 1997. That's ten
  years ago, about ten days from now. Anybody else interested in
  celebrating this a bit? What would be an appropriate way?
 
 By spending the day arguing about whether users or free software are the
 more important priority? ;)
 
If we lived in the matrix, the users could *be* free software.  That
would simplify things a bit.  :-)

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: A bit of history

2007-06-12 Thread Roberto C . Sánchez

On Tue, Jun 12, 2007 at 08:12:21AM -0500, John Goerzen wrote:
 Hi folks,
 
 I am trying to find out exactly when I joined Debian.
 
 This is not as easy as it might seem.
 
 There seem to be three possible dates:
 
 1) The date of my first upload
 
 2) The date my account was created on master
 
 3) The date my key was added to the keyring
 
I guess that depends on what you consider joined.  You might also
consider your first posting to a Debian mailing list.  Or possible, your
first contribution (e.g., bug submission or patch submission).

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Proposed name change for DWN

2007-05-01 Thread Roberto C . Sánchez

Hello,

I notice that Debian Weekly News is still called Debian Weekly News,
even though it is not published weekly.  Perhaps we should consider
changing the name to something like the Debian Newsletter?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: notable Debian contributions in 2006

Please forgive me for feeding the troll. 

On Sat, Mar 24, 2007 at 03:20:31PM +0100, Joerg Schilling wrote:
 
 Distors are often viewed as mere packagers, but they tend to drive
 upstream development in variety of ways. Here's just a few of Debian's
 contributions to the world of FLOSS during 2006:
 
 * creation of cdrkit, a fork of cdrtools, due to a change of licence
 which happened to be DFSG-incompatible
 
 You are not talking about a notable contribution but about a notable
 damage to FLOSS caused by people who are unwilling to cooperate in a useful 
 way. 
 
Joerg, as a piece of friendly advice, I think it would be wise to drop
it.  You continue to do your reputation harm by going around making this
claim.  Does Debian's fork somehow harm you?  Does it harm your
software?  The question to both of those is probably no.  Why not just
ignore it?

 Note that there was a licence change with cdrtools but this was a change 
 towards more freedom and the current official cdrtools are of course still
 accepted free software and do not have any license problem.
 
The question is not about free vs non-free.  It is a question of
compatibility.  For example, the original (4-clause) BSD license is
arguably more free than the GPL (depending on whether you look from the
perspective of developer or the user).  However, it is still
incompatible with the GPL.  Nobody argues this point.  I believe that
this point has been explained to you multiple times.  Additionally, both
the FSF and Sun have agreed that while the CDDL is in fact free, it is
*not* compatible with the GPL.

 Note that the license change was definitely not the reason for the fork (the 
 fork would have been done in a different way if the license change was the 
 reason). The reason for the change rather was the unability/unwillingness
 of Mr. Eduard Bloch in cooperating. You need to blame him for causing damage
 to Debian users...
 
Of course, you seem to continue with the personal attacks, so it is
quite obvious that you care little, if at all, for the technical/legal
aspects of the situation.

 If you like to vote for _useful_ contributions, the unneeded fork named
 cdrkit is not the right choice. Note that while the original software 
 does include a lot of enhancements and usability emendations since the last 
 year, there have been only speudo changes and new bugs in the Debian fork.
 
I believe that Eduard already refuted this argument, pointing out that
many of the changes were just cosmetic and that many of the problems
you claimed existed in the Debian version were not problems or were not
relevant to Debian.  In fact, here is Eduard's reply:

http://lists.debian.org/debian-user/2007/03/msg02863.html

Of course, you never did reply to his counter-claim, which makes me
think that he was right and you were wrong.  In fact, nearly everything
that you have said on Debian lists in relation to this matter strikes as
angry hand waving and nothing more.

 If you do not like to suffer from the problems that have been introduced in 
 the
 fork, just use the free original software from:
 
 ftp://ftp.berlios.de/pub/cdrecord/alpha/
 
Again, Eduard refuted every single one of your claims of problems in
the Debian cdrkit.  Please feel free to prove him wrong (with a
technical argument, not a personal attack).

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: notable Debian contributions in 2006

On Sat, Mar 24, 2007 at 04:40:34PM +0100, Joerg Schilling wrote:
 Roberto C. Sánchez [EMAIL PROTECTED] wrote:
 
  Joerg, as a piece of friendly advice, I think it would be wise to drop
  it.  You continue to do your reputation harm by going around making this
  claim.  Does Debian's fork somehow harm you?  Does it harm your
  software?  The question to both of those is probably no.  Why not just
  ignore it?
 
 Shouldn't the people in the Debian project be interested in preventing the 
 loss
 of reputation caused by this unneeded fork?
 
 This fork harms the users of Debian in at least two ways:
 
 - the fork does not work decently and thus annoyes them
 
 - the fact that other Debian maintainers does not try to 
   find a workaround for the problems caused by some outcasts
   causes damage to the reputation of the Debian project.
 
I guess you missed Aurelien's mail [0]?  What about the other distros?
They clearly see a problem as well, as Aurelien pointed out.

  this point has been explained to you multiple times.  Additionally, both
  the FSF and Sun have agreed that while the CDDL is in fact free, it is
  *not* compatible with the GPL.
 
 Missquoting Sun and the FSF is not the way to deal with problems caused by
 unproven accusations.
 

I would hardly call it misquoting:

  [1]  Common Development and Distribution License (CDDL)

  This is a free software license which is not a strong copyleft; it
  has some complex restrictions that make it incompatible with the
  GNU GPL. It requires that all attribution notices be maintained,
  while the GPL only requires certain types of notices. Also, it
  terminates in retaliation for certain aggressive uses of patents.
  So, a module covered by the GPL and a module covered by the CDDL
  cannot legally be linked together. We urge you not to use the CDDL
  for this reason.

  Also unfortunate in the CDDL is its use of the term intellectual
  property.

  [2] Common reasons for incompatibility

  When checking licences for compatibilty, here are some specific
  issues to look for that would make a licence incompatible with
  GPLv3 (as of draft 2).

  * Requirements about attorney fees
  * Waiver of the right to trial by jury
  * Jurisdiction requirements (disputes must be settled in a
certain country or in accordance with the laws of a certain
country) 

  Licences which are incompatible with GPLv3 (as of draft 2) for the
  above reasons include the MPL, CDDL, CPL, EPL, academic free
  license, open software license. 

Even Sun says so [3]:

  We have carefully reviewed the existing OSI approved licenses and
  found none of them to meet our needs, and thus have reluctantly
  drafted a new open source license based on the Mozilla Public License,
  version 1.1 (MPL). We do appreciate the issue of license
  proliferation, however, and have worked hard to make the Common
  Development and Distribution License (CDDL) as reusable as possible.
  Additionally, we have attempted to address the problems we perceived
  in existing open source licenses that led us to conclude that reusing
  those existing licenses was impractical.

  We chose to use the MPL as a base ...

Now, the MPL has been around for a long time.  It has also been known
for a long time that the MPL is not GPL compatible.

 unproven accusations. Note that I am waiting for an explanation for the
 pretended problems since January 2006.

 Note that what I like to see is a cleanly written list of problems
 and a clean list of quotes from the GPL and probably the OSI rules
 that prove the claims. What I've read so far was a list od incorrect 
 (modified)
 quotes from the GPL...
 
 As long as nobody is able to prove the claims made by Mr. Bloch and friends,
 we could carefully asume that they are void.
 
Have I provided enough for you above?  I don't get why you persist in
your argument when both sides have via *public* means stated the exact
opposite of what you are claiming.

 
 Also note that I am not attacking people but only trying to inform about the 
 truth while Mr. Bloch is constantly publishing personal attacks.
 
 
  Again, Eduard refuted every single one of your claims of problems in
  the Debian cdrkit.  Please feel free to prove him wrong (with a
  technical argument, not a personal attack).
 
 You should try to inform yourself with facts instead of believing claims
 from Mr. Bloch. I am sure you did never try out the original and compare it
 with the fork 
 
So, in other words, you are not able to refute his claims?

Regards,

-Roberto


[0] http://lists.debian.org/debian-project/2007/03/msg00188.html
[1] http://www.fsf.org/licensing/licenses/
[2] http://gplv3.fsf.org/wiki/index.php/Compatible_licenses
[3] http://www.sun.com/cddl/CDDL_why_details.html

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: notable Debian contributions in 2006

On Sat, Mar 24, 2007 at 06:53:43PM +0100, Joerg Schilling wrote:
 Roberto C. Sánchez [EMAIL PROTECTED] wrote:
 
   - the fact that other Debian maintainers does not try to 
 find a workaround for the problems caused by some outcasts
 causes damage to the reputation of the Debian project.
   
  I guess you missed Aurelien's mail [0]?  What about the other distros?
 
  Mail not addressed to me is send py people who are not interested
 in an answer from me.
 
The Code of Conduct for the Debian lists indicates that CCs are to be
avoided unless explicitly requested.  Since you did not request one, I
imagine Aurelien did not send you one.  Of course, you are
participicating in list discussion and so should be subscribed to the
list.

  They clearly see a problem as well, as Aurelien pointed out.
 
 If other distros did see a license problem, it wuld be obvious that they ask 
 me
 before changing to a fork that is definitely worse than the original.

I do not know what relationship other distros have with you.  So if they
have or have not contacted you, I don't know.  Of course, you keep
making the claim that the fork is definitely worse than the original.
However, you haven't produced any actual evidence that such is the case.

 Not a single mail from another distro has been send to me, so we may 
 safely asume that other distros have just been overpowered but not
 convinced by Mr. Bloch...
 
Wow.  I am sure that Eduard would like to think that he holds so much
sway and power that he was able to cow Canonical *and* Novell into
including an inferior product into their distributions.  However, I
think that you are just making things up now.

this point has been explained to you multiple times.  Additionally, both
the FSF and Sun have agreed that while the CDDL is in fact free, it is
*not* compatible with the GPL.
   
   Missquoting Sun and the FSF is not the way to deal with problems caused by
   unproven accusations.
   
 
  I would hardly call it misquoting:
 
 [ missunderstood text removed, see my other mail ]
 
I see.  So the opinions of Sun *and* the FSF on the GPL and CDDL are
misunderstood?  Who, pray tell, are we supposed to seek for a
non-misunderstood opinion?  Yourself?

   As long as nobody is able to prove the claims made by Mr. Bloch and 
   friends,
   we could carefully asume that they are void.
   
  Have I provided enough for you above?  I don't get why you persist in
  your argument when both sides have via *public* means stated the exact
  opposite of what you are claiming.
 
 You did not provide anything relevent, sorry.
 
Only because you choose to ignore it.

 I did however explain many times in the public why there is no problem.

So, if there is no problem, then why are you all up in arms over a fork?
If there is no problem, a fork should not bother you, because nobody
will use it as it is unnecessary.  But I think that this is not the case
and you fear becoming irrelevant.

By the way, did you miss the whole XFree86/X.Org fiasco?  If you choose
to change licenses (which you are more than free to do as the owner of
the code) to a license which the majority of your users see as
problematic (rightly or wrongly) you are asking for many of them to seek
an alternative.  It appears that is what has happened here.  Perhaps you
should have considered your choice more carefully.

 I recommend you to read this and reply again _after_ you found a way to send 
 arguments that are based on real things that happen inside cdrtools and do not
 repeat global unrelated statements from other people.
 
I'm sorry, but the issue has *specifically* to do with license
incompatibility.  The statements that I quoted were *directly* related
to that.

 
   You should try to inform yourself with facts instead of believing claims
   from Mr. Bloch. I am sure you did never try out the original and compare 
   it
   with the fork 
   
  So, in other words, you are not able to refute his claims?
 
 There is no need to refute obviously wrong claims from Mr. Bloch. 

Well, his claims are not so obivously wrong to quite a large number of
people.

 If you believe his wrong claims, it seems that I cannot help you anyway.

I believe his *technical* claims.  You have yet to make a *technical*
counter-claim.  However, you have engaged in quite a bit of vigorious
hand waving while *avoiding* technical arguments.

 If you are openminded enough, you may try out e.g. the latest Knoppix DVD and
 discover that wodim and other libscg based programs published by Mr. Bloch
 simply do not work at all (I did try this at Cebit last week on my laptop).
 
 The original cdrtoools however are known to work.
 
I don't understand what you mean.  How could cdrkit or cdrtools or any
other burning application work with a disc already in the drive.  What
my real interest is where you think the problems are with the code.
Perhaps you could post a diff between your superior cdrtools and the
inferior cdrkit and describe where

Re: notable Debian contributions in 2006

On Sat, Mar 24, 2007 at 08:23:33PM +0100, Nico Golde wrote:
 
 C'mon, you and almost everyone who replied to this thread 
 Cc'ed Joerg so this should not be the point.

I (and I imagine others) have CC'd Joerg since he has done so.  To me,
if someone CC's people it indicates that he wants a CC himself.  Now,
maybe Aurelien did not see it.  Or maybe he decided not to CC for
whatever reason.

Either way, Joerg's claim that because the mail was not addressed
specifically to him, and so he cannot be expected to have seen it, is
lame.  He is participating in a list discussion.  He should be
subscribed to the list.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: notable Debian contributions in 2006

On Sat, Mar 24, 2007 at 09:00:20PM +0100, Joerg Schilling wrote:
Roberto C. Sánchez [EMAIL PROTECTED] wrote:

I guess you missed Aurelien's mail [0]? What about the other distros?

Mail not addressed to me is send py people who are not interested
in an answer from me.

The Code of Conduct for the Debian lists indicates that CCs are to be
avoided unless explicitly requested. Since you did not request one, I
imagine Aurelien did not send you one. Of course, you are
participicating in list discussion and so should be subscribed to the
list.

If you like to ignore the nettiquette, this is your choice
The nettiquette requires not to remove recipients from a list.

They are not my guidelines. I imagine that the list guidelines and code
of conduct were thouroughly vetted. However, I have not been around
long enough to know. Perhaps someone who has been around longer can say
for sure.

I do not know what relationship other distros have with you. So if they
have or have not contacted you, I don't know. Of course, you keep
making the claim that the fork is definitely worse than the original.
However, you haven't produced any actual evidence that such is the case.

I did but you ignore it... Let me give again some hints on problems with
Mr. Blochs fork:

- dozens of unfixed bugs in mkisofs.

Right. People keep asking you to specify *which* bugs. You provided a
few: http://lists.debian.org/debian-user/2007/03/msg02703.html

Eduard's response: http://lists.debian.org/debian-user/2007/03/msg02863.html

So, it looks like in your entire list, the only one that might
legitimately be considered a problem is that Debian's cdrkit might not
work correctly with deeply nested directories. That is out of your list
of 12 charges on which Debian's cdrkit has problems. I'd say that
Debian is doing an excellent job then of fixing the problems.

- no useful DVD support.

As Eduard pointed out in his response to your charges, this is not
really a problem. Debian has other tools which support DVDs just fine.

- The tools do not work at all on Knoppix

Exactly how is this Debian's problem? I don't know how if at all
Knoppix modifies cdrkit, if at all. However, I'd look at the Debian
version *in Debian* before making unbased charges against it.

There are more

Really? Like what?

Not a single mail from another distro has been send to me, so we may
safely asume that other distros have just been overpowered but not
convinced by Mr. Bloch...

Wow. I am sure that Eduard would like to think that he holds so much
sway and power that he was able to cow Canonical *and* Novell into
including an inferior product into their distributions. However, I
think that you are just making things up now.

Distros who did not ask me are obviously overpowered by Mr. Bloch because
they did never try to find out whether his claims are correct.

I find this really hard to believe. Do you have any evidence of this?
Or is this another of your baseless claims?

I would hardly call it misquoting:

[ missunderstood text removed, see my other mail ]

I see. So the opinions of Sun *and* the FSF on the GPL and CDDL are
misunderstood? Who, pray tell, are we supposed to seek for a
non-misunderstood opinion? Yourself?

Are you really unable to understand the problem?

It makes no sense to quote text that is not related to what's done inside
cdrtools. If you like to be taken for serious, you should not quote text that
only applies to non-GPL code that has been derived from GPLd code.

Really? I fail to see how it makes any difference if the GPL code
sprang out of nothing or was derived from some other code? That is like
saying that GPL code that is someone's original creation is treated
differently than GPL code which is derived from the Public Domain. How
can that be?

You did not provide anything relevent, sorry.

Only because you choose to ignore it.

In contryry: I read it and commented it but you do not seem to understand
licensing issues.

I am struggling to see how the source of the derivation makes any
impact. Either something is GPL or is not. Either something is
GPL-compatible or it is not.

By the way, did you miss the whole XFree86/X.Org fiasco? If you choose

You again demonstrate that you did missunderstood things.
Xfree did get into problems because it changed it's license to something less
free and completely unclear. Xorg did come up again because Sun did contribute
more money and human resources to Xorg, starting a few weeks before the Xfree
desaster.

I don't buy it. The license change to XFree86 was committed on 13
February 2004:

http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml.diff?r1=1.23r2=1.24hideattic=0
http://www.mail-archive.com/cvs-commit@xfree86.org/msg03271.html

The X.Org Foundation was formed on 22 January 2004. The XFree86

Re: notable Debian contributions in 2006

On Sat, Mar 24, 2007 at 10:51:04PM +0100, Joerg Schilling wrote:
Roberto C. Sánchez [EMAIL PROTECTED] wrote:

I do not have the unlimited time to waste with useless speudo
discussions. I am sorry, but this will be the last response to you
unless you start to open your mind to the reality.

For the same reason. this reply is shortened.

- dozens of unfixed bugs in mkisofs.

Right. People keep asking you to specify *which* bugs. You provided a
few: http://lists.debian.org/debian-user/2007/03/msg02703.html

Eduard's response: http://lists.debian.org/debian-user/2007/03/msg02863.html

Are void.

How so?

The GPL is known to be asymmetric (which is a problem) and even the founder
of Debian does not follow your strange ideas on interpreting the GPL.

http://ianmurdock.com/?p=278

(see 3rd paragraph)

Umm, Ian Murdock had a problem with the overreaction since it involved
two distinct and separate pieces of software (dpkg and libc). With
cdrtools, it is *one* piece of software. In fact the issue is not even
that you can't do what you have. As the copyright holder, you can do as
you please. It is just that your choice has made it impossible for
others to legally redistribute.

By the way, did you miss the whole XFree86/X.Org fiasco? If you choose

You again demonstrate that you did missunderstood things.
Xfree did get into problems because it changed it's license to something
less
free and completely unclear. Xorg did come up again because Sun did
contribute
more money and human resources to Xorg, starting a few weeks before the
Xfree
desaster.

I don't buy it. The license change to XFree86 was committed on 13
February 2004:

http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml.diff?r1=1.23r2=1.24hideattic=0
http://www.mail-archive.com/cvs-commit@xfree86.org/msg03271.html

The X.Org Foundation was formed on 22 January 2004. The XFree86
disaster started long before either of those events.

You still ignore facts!

What facts?

I was quoting one of the leading X.org members who is obviously better
informed than you.

Really? Who? Where is the press release or public statement containing
that quote?

Do you really believe that it was posible to obtain a single letter
top level domain name in 2004?

No. I said the X.Org *Foundation* was formed in 2004:

In early 2004 various people from X.Org and freedesktop.org formed
the X.Org Foundation, and the Open Group gave it control of the
x.org domain name.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

signature.asc
Description: Digital signature

Re: notable Debian contributions in 2006