The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guidelines docs on ftp.debian.org.



[I'm bringing that back to debian-private where it started.]

  Dirk> * consistency as all our package names will look similar; this is
  Dirk> quite a goal for a distribution 

  Erick> But more visual than functional. 

Visual aspects do matter. Recognition is important.

Richard Kettlewell tried to fend this off by borrowing my argument that
inconsistency is already present in numbering schemes. Heck, we can't get
more circular in this discussion --- I want to reduce exactly this
inconsistency. 

We should have version numbers, upstram or intrinsic in the case of
Debian-only packages, followed by a revision field.

  Dirk>  * easier handling for parsing etc

  Erick> Having only a version field with a version and perhaps a hyphen
  Erick> followed by a revision part isn't that difficult to parse.

Thanks, that is *exactly* what is proposed, and what I am in favour of.

  Dirk> * safer design: I use -revision on debian-only packages because I
  Dirk> know how easy it it to screw in the package *management*, as opposed
  Dirk> to the package *content*. Why should I increase the version number if
  Dirk> the content hasn't changed but only the packaging?

  Erick> You shouldn't increase the version number if only the packaging
  Erick> changed, Specific debian only packages don't have much changes with
  Erick> the packaging 

Again, thanks. This is precisely why we need the revision field for.

  Dirk> I think that dpkg for example, even though it looks like a.b.c,
  Dirk> really numbers as a.b-revision. Whenever Ian overlooks something at
  Dirk> compile time (as opposed to a new major function, ie the jumps from
  Dirk> 0.93.x to 1.0.x to 1.1.x), he increases the last number which hence
  Dirk> is a *de facto revision field*.

  Erick> I don't look in the kitchen of Ian J that much but I think he is
  Erick> using the last field as a patch field. That is what it should be
  Erick> used for.

Exactly. It already *is* a revision field. So why is it so difficult to call
a revision field a revision field? 

--
Dirk Eddelb"uttel                              http://qed.econ.queensu.ca/~edd