Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Johannes Schauer]

Quoting James Clarke (2017-05-22 16:25:38)
> But I notice that for the sbuild path, schroot is completely missing,

Maybe I should also point out that schroot is just the *default* sbuild chroot
backend.  It also supports the "sudo" mode (which essentially just uses "sudo
chroot") and the autopkgtest mode which allows sbuild to build packages in any
environment that autopkgtest provides like lxc, lxd, qemu, ssh...

And then there is also a patch for adding a backend using Linux user namespaces
which is a lightweight replacement of lxc-usernsexec and unshare that allows to
easily do unprivileged package builds without the need of an suid binary like
schroot:

https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?h=user/josch/uchroot=8c40e83a63195983dadad7616b7b916e084cf7e4

And then there is also the effort to add this as a backend to autopkgtest:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844459

Work on all of this stalled a bit because of lack of time. I don't want to drag
this thread further into this direction, so if you are interested in any of
this, just get in touch with me off-list.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Ben Finney]

Ian Jackson  writes:

> Use [dgit] to publish your git history, by doing your uploads with
> dgit push.
>
> The root goal is this: Debian should publish the source for all our
> packages, as git branches, in a format that is directly useable by
> ordinary people.

Thanks. That is what I think anyone reading the package description
needs to know; it's context that simply isn't there.

> I would be very happy to hear suggestions for improving the
> descriptions.  Ideally without making them longer.

Making it longer is unavoidable, I think, since the issue as I see it is
the context is missing. So I hope you'll be convinced to add that
context to the package description.

Adding a paragraph like the above one about “the root goal” would be an
excellent start.

-- 
 \ “Why doesn't Python warn that it's not 100% perfect? Are people |
  `\ just supposed to “know” this, magically?” —Mitya Sirenef, |
_o__) comp.lang.python, 2012-12-27 |
Ben Finney

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Philipp Kern]

On 22.05.2017 16:25, James Clarke wrote:
> You say that, but this is incredibly biased. Even he admits that in the
> colour choice. Disclaimer: as the cowbuilder maintainer (which comes
> from the cow*dancer* source package, for historical reasons, despite
> what the diagram may tell you) I am of course also biased. But I notice
> that for the sbuild path, schroot is completely missing, which is
> implemented in C++ and therefore probably deserves a bright red colour
> just like cowbuilder in his second picture (or maybe even something
> worse, depending on your views of C++). Then there's the extremely
> unhelfpul, hostile comment at the end:

schroot is in theory just a tool in the toolbox, even if it came from
the same developer. The same is in theory true for cowdancer, but it
inherently requires cooperation from the chroot as well. At the same
time it won't properly work for programs that do not use the C library's
file interface (e.g. if they use syscalls directly like Go).

So cowdancer is in a way a very cute hack of which you might need to
know the semantics whereas schroot aimed to be a fancy chroot done
right. The aim of one tool was to speed-up the build (hence cowdancer
and cowbuilder being built from the same source) and of the other other
to get a chroot tool that can be used by unpriviledged users, in a way
that allows reuse of chroot templates.

I somewhat doubt that you end up hacking on a C++ setuid binary as part
of Debian packaging work. And the same is likely true for cowdancer
itself - although it's theoretically more brittle - with the twist that
for some reason pbuilder does not have native support for it.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Ian Jackson]

Ben Finney writes ("Re: infinite number of Debian workflows (Re: Moving away 
from (unsupportable) FusionForge on Alioth?)"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > I want every maintainer who is using git to be able to use dgit.
> 
> Use it to do what, though? The package description is currently:

Use it to publish your git history, by doing your uploads with
dgit push.

The root goal is this: Debian should publish the source for all our
packages, as git branches, in a format that is directly useable by
ordinary people.

A user should not have to be an expert on Debian source formats to
clone the source to a program on your computer, git-cherry-pick a
patch from upstream (or develop their own patch to the upstream code),
and rebuild and install it.  Debian should provide a sensible git
branch, for every package, that a user can use this way.

> git interoperability with the Debian archive
>  dgit (with the associated infrastructure) makes it possible to
>  treat the Debian archive as a git repository.
>  .
>  dgit push constructs uploads from git commits
>  .
>  dgit clone and dgit fetch construct git commits from uploads.
> 
> That sounds to me like it isn't a tool for maintainers, but rather a
> tool for “interoperability with the Debian archive” which AFAICT is
> already provided by the tools I am using.

You have only one-way interoperability, and only from a nonstandard
git layout.

> If the package does something that should be of interest to package
> maintainers in general, I'd expect the description to be a lot clearer
> what that is and why it's of interest.

I would be very happy to hear suggestions for improving the
descriptions.  Ideally without making them longer.


It's awkward, because dgit is different things to different people.

1. For a user or a downstream, dgit is a way to get Debian source code
   as directly useable git branches in a standard format.

2. For a maintainer, dgit is a way to publish and share your actual
   git branch with users, downstreams and other contributors.  It
   can also be a way to handle an NMU without needing to ever deal
   with a source package.

3. For sponsors/sponsees, etc., it is a way to replace the
   soruce-package-based sponsorship workflow with one based on git
   branches.  The sponsee publishes their git branch, and the sponsor
   (when satisfied) invokes dgit to upload it.

4. In the abstract, much of the functionality is a bidirectional
   converter between git trees and source packages [4]; but it's also
   a client (read and write) for a standardised git publication
   infrastructure.


We have other tools that do these things.  So let me address the
competition:

1. Obtaining Debian package source code as a git branch.  The
   principal competition here is the Vcs-Git dsc header.  One big
   problem with Vcs-Git is that the git tree you find there is largely
   unstandardised:
  - The git tree might be patches-unapplied.  Usually it is.  Such
trees are useable only by people who are already Debian
experts, and have many weird properties.
  - The git tree might not have the upstream code at all.
  - There might be other arbitrary weirdnesses; perhaps
some script needs to be run to make it buildable, for
example.

   (It can also sometimes be a problem to find the git commit
   corresponding to a particular Debian package.  Luckily we have
   DEP-14 tags which are largely used now; even git-dpm, whose author
   rejects the DEP-14 tag encoding, creates similar enough tags out of
   most versions.)

   There are other potential problems: the git branch you find might
   not be fast-forwarding; or there might not be a suitable DEP-14
   tag; or the last upload might have been done `out of maintainer
   workflow' for some reason and not be reflected in the git
   repository.  This means that the Vcs-Git repository might lack
   important security patches.  The repository might have moved.

   And of course it may not exist at all.  A user wants a single tool,
   not to be told to flail about trying various options.   

2. For working within Debian maintainer teams, our existing git
   workflows mostly work.  However, they have the problem that they do
   not, generally, produce externally-useable git branches.  See (1).

   Some workflows (eg git-dpm) do produce extenally-useable git
   branches; but before dgit there was no way to publish your git
   branch along with a promise that it was directly useable.  And
   there was no fallback for packages that didn't have a useable git
   branch.

   In a sense I am hoping that maintainers, who do not suffer from the
   lack of a solution to (1), are willing to do a bit of work to make
   everyone else's lives easier.

   There are some advantages for the maintainer of course: if a
   maintainer and an NMUer both use dgit, then the

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Holger Levsen]

On Tue, May 23, 2017 at 06:34:09PM +0100, Sean Whitton wrote:
> On Tue, May 23, 2017 at 06:38:29PM +0200, Emilio Pozuelo Monfort wrote:
> > I have to deal with packages in svn, git-bp and plain git, and have started 
> > to
> > write a set of (ugly) scripts that perform common actions in each of those
> > formats, and a generic wrapper that calls the right one depending on which 
> > repo
> > I'm on, so that I can just do e.g. 'deb update; dch; deb commit; deb build; 
> > deb
> > release; deb tag' and not having to remember all the different command line
> > switches and options and so on (I have a bad memory and am lazy). This 
> > shouldn't
> > be necessary in the first place; at least a bit of homogenization would make
> > sense imho.
> This is pretty much exactly the point of dgit.

I actually thought that Emilio reinvented mr (but then realized it's mr plus
yet another release-wrapper ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Ben Finney]

Ian Jackson  writes:

> I want every maintainer who is using git to be able to use dgit.

Use it to do what, though? The package description is currently:

git interoperability with the Debian archive
 dgit (with the associated infrastructure) makes it possible to
 treat the Debian archive as a git repository.
 .
 dgit push constructs uploads from git commits
 .
 dgit clone and dgit fetch construct git commits from uploads.

That sounds to me like it isn't a tool for maintainers, but rather a
tool for “interoperability with the Debian archive” which AFAICT is
already provided by the tools I am using.

If the package does something that should be of interest to package
maintainers in general, I'd expect the description to be a lot clearer
what that is and why it's of interest.


My apologies for publicly pointing to a package description for
criticism, but it seems relevant to the claim that the package is for
“every maintainer who uses git” that the description should explain why
that is.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, but |
  `\  where will we find an open tattoo parlor at this time of |
_o__)   night?” —_Pinky and The Brain_ |
Ben Finney

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Sean Whitton]

On Tue, May 23, 2017 at 06:38:29PM +0200, Emilio Pozuelo Monfort wrote:
> I have to deal with packages in svn, git-bp and plain git, and have started to
> write a set of (ugly) scripts that perform common actions in each of those
> formats, and a generic wrapper that calls the right one depending on which 
> repo
> I'm on, so that I can just do e.g. 'deb update; dch; deb commit; deb build; 
> deb
> release; deb tag' and not having to remember all the different command line
> switches and options and so on (I have a bad memory and am lazy). This 
> shouldn't
> be necessary in the first place; at least a bit of homogenization would make
> sense imho.

This is pretty much exactly the point of dgit.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Sean Whitton]

On Tue, May 23, 2017 at 10:21:27AM +0100, Jonathan Dowland wrote:
> On Mon, May 22, 2017 at 10:07:20PM +0100, James Clarke wrote:
> > There already effectively is a semi-"primary" implementation given that
> > sbuild is used on the buildds.
> 
> Yes that is a very strong fact in favour of sbuild.

If by "in favour" you mean in favour of using sbuild instead of pbuilder
on your own machine, I think James' point was that the fact that sbuild
is run on the buildds is a reason *not* to run it locally.

Your package will be built using sbuild on the buildds anyway, so
testing with pbuilder locally could expose bugs.

(disclaimer: I use sbuild)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Russ Allbery]

Jonathan Dowland  writes:

> Fair enough, cowbuilder was one of the ones in my hazy peripheral vision
> as "another", along with some tools to use things like docker that I am
> aware of but couldn't remember the names. None of them have the same
> traction as pbuilder or sbuild. I've only used pbuilder myself
> personally.

If you're using git-buildpackage, using cowbuilder is indistinguishable
from using pbuilder (in fact, someone may well be using cowbuilder and not
know it if they used the default recommendations in git-buildpackage).
cowbuilder is nearly identical to pbuilder; it just constructs the work
directory for the build differently, in a way that at least used to be way
faster.

-- 
Russ Allbery (r...@debian.org)   

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Ian Jackson]

Emilio Pozuelo Monfort writes ("Re: infinite number of Debian workflows (Re: 
Moving away from (unsupportable) FusionForge on Alioth?)"):
> Besides, the sbuild/pbuilder duplicity is the least of your problems
> in terms of multiple workflows, because once you choose one of those
> and set it up, you can build all packages, and don't have to set the
> other one up or learn it.

Right!

> Compare that to hacking on a package which may use
>  - debhelper, dh, cdbs or no helper at all (!) for debian/rules
>  - quilt, dpatch, simple-patchsys, single-debian-patch for patch management
>  - format 1.0, 3.0, native, non-native, multiple tarballs... for the source
>  - git-buildpackage, git-dpm, other git repo structure with no helper tools,
> svn, bzr, etc for the repository
>  - ...

Of these, debhelper/dh/cdbs/raw is difficult to deal with with better
tooling because it's inherint in the source code.  However:
  * dh $@ is a more automatic way of doing dehelper
  * cdbs is on the way out
  * no helper at all is definitely on the way out
So at least the last two are a form of technical debt.

> Some of those are easy to learn, and some you don't have to deal
> with if you are doing an NMU (e.g. the repository). It's still a
> pretty complicated picture and a steep learning curve if you want to
> start contributing, or want to join a team that has a completely
> different setup.

Yes.

> I have to deal with packages in svn, git-bp and plain git, and have
> started to write a set of (ugly) scripts that perform common actions
> in each of those formats, and a generic wrapper that calls the right
> one depending on which repo I'm on, so that I can just do e.g. 'deb
> update; dch; deb commit; deb build; deb release; deb tag' and not
> having to remember all the different command line switches and
> options and so on (I have a bad memory and am lazy). This shouldn't
> be necessary in the first place; at least a bit of homogenization
> would make sense imho.

Part of the problem is that many of the workflows have been pretty
poor: at least, they all have flaws that some people regard as
important.

Ian.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Emilio Pozuelo Monfort]

On 22/05/17 16:25, James Clarke wrote:
> On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
>> On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote:
>>> Someone else already had this idea:
>>>
>>> https://people.debian.org/~stapelberg//2016/11/25/build-tools.html
>>
>> Excellent, this is a great start, and seeing "Michael Stapelberg" for me is 
>> an
>> indication of quality.
> 
> You say that, but this is incredibly biased. Even he admits that in the
> colour choice. Disclaimer: as the cowbuilder maintainer (which comes
> from the cow*dancer* source package, for historical reasons, despite
> what the diagram may tell you) I am of course also biased. But I notice
> that for the sbuild path, schroot is completely missing, which is
> implemented in C++ and therefore probably deserves a bright red colour
> just like cowbuilder in his second picture (or maybe even something
> worse, depending on your views of C++). Then there's the extremely
> unhelfpul, hostile comment at the end:
> 
>> I propose to eliminate complexity in Debian by deprecating the
>> pbuilder toolchain in favor of sbuild.
> 
> Now, I am not necessarily against simplifying workflows, but choosing
> one to rule the all arbitrarily because you prefer the language it's
> written in is not the way to go about it. There are also benefits to
> having a variety of implementations; they behave slightly differently,
> sometimes not implementing policy in the same way, and this can be a
> good thing, allowing policy to be clarified, or finding mistakes in the
> other builder, or just exposing flaws in your package. For example,
> pbuilder will by default use a new isolated network namespace for the
> build, whereas sbuild won't, so if you just use sbuild you may not be
> aware of violating policy (4.9). I'm not trying to sell pbuilder over
> sbuild here though; there are also many ways in which sbuild is better
> than pbuilder.

Besides, the sbuild/pbuilder duplicity is the least of your problems in terms of
multiple workflows, because once you choose one of those and set it up, you can
build all packages, and don't have to set the other one up or learn it.

Compare that to hacking on a package which may use
 - debhelper, dh, cdbs or no helper at all (!) for debian/rules
 - quilt, dpatch, simple-patchsys, single-debian-patch for patch management
 - format 1.0, 3.0, native, non-native, multiple tarballs... for the source
 - git-buildpackage, git-dpm, other git repo structure with no helper tools,
svn, bzr, etc for the repository
 - ...

Some of those are easy to learn, and some you don't have to deal with if you are
doing an NMU (e.g. the repository). It's still a pretty complicated picture and
a steep learning curve if you want to start contributing, or want to join a team
that has a completely different setup.

I have to deal with packages in svn, git-bp and plain git, and have started to
write a set of (ugly) scripts that perform common actions in each of those
formats, and a generic wrapper that calls the right one depending on which repo
I'm on, so that I can just do e.g. 'deb update; dch; deb commit; deb build; deb
release; deb tag' and not having to remember all the different command line
switches and options and so on (I have a bad memory and am lazy). This shouldn't
be necessary in the first place; at least a bit of homogenization would make
sense imho.

Cheers,
Emilio

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Ian Jackson]

Sean Whitton writes ("Re: infinite number of Debian workflows (Re: Moving away 
from (unsupportable) FusionForge on Alioth?)"):
> A way to set the version during the build, as you suggest, would be
> sufficient to cover this.  It is hard to see how we could relieve the
> user of the need to understand how to choose a version number for a .deb
> for testing.  An option to set the version in the build command line
> would remove the need for Debian source package knowledge.

It would be best if the user would just pass an option to say `pls
pick version number' and some tool would make a reasonable stab at it.

> >  * Pull request workflow for submitting changes.  This should
> >eventually turn into a bug submission to the Debian BTS.
> >This sounds to me like it probabl needs to be a web service, but
> >perhaps some local client utility that looked enough like a web
> >page would do.
> 
> We basically already have all the pieces:
> 
> - git-request-pull(1)
> - reportbug(1)
> - git hosting on alioth / our shiny pagure git hosting (coming soon)
> 
> dgit could ship a script that ties these together.  (The reason I suggest
> using our own git hosting is so that the branch doesn't disappear -- one
> advantage of patches in the BTS is that they can't 404.)

I'm not sure that a command-line tool is what our target audience for
this would be looking for.  But contributions certainly welcome.

Ian.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Ian Jackson]

Sean Whitton writes ("Re: infinite number of Debian workflows (Re: Moving away 
from (unsupportable) FusionForge on Alioth?)"):
> On Mon, May 22, 2017 at 09:22:00PM +0100, Sean Whitton wrote:
> > On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote:
> > > Of course, dgit is yet another workflow and my understanding is that
> > > git-buildpackage (without dgit) is far more commonly used in Debian.

Jeremy: you're right that dgit is not yet used for the majority of
uploads.  I think this is a problem because I think we should all be
sharing our git trees in a way that is directly useable by
non-Debian-experts.

But I think it is not true that dgit `is yet another workflow'.  Of
course it depends a bit on what you mean by `workflow', but in this
context I think it means things like what your git branches look like,
where you keep them, how you deal with new upstream versions; and it
also means what build tools you use (eg cowbuilder vs sbuild).


>From a maintainer's point of view, dgit tries not to impose
workflow requirements.  You can use dgit:

   - with patches-applied branches,
 or with patches-unapplied branches

   - with git-buildpackage; with git-dpm; with raw git

   - with sbuild or with pbuilder (although I am working on
  smoothing out some wrinkles with the use of pbuilder)

   - if you generate your orig tarballs from git, or if you
  download them from upstream, or if you repack them
  yourself using eg dpkg-repack

etc. etc.

I want every maintainer who is using git to be able to use dgit.
We're not quite there yet, but the exceptional cases are much rarer
now.  (The main obvious one is packaging-only git trees.)

So I think the `yet another standard' jibe is unfair.  dgit is trying
to *work with* maintainers' existing packaging tools, not supplant
them.


> Ian did claim that dgit gives you one workflow for all Debian packages.
> It does indeed provide that.  What I should have said was that it does
> not enforce /that/ workflow; it just makes it available, primarily for
> the benefit of NMUers and those who aren't already Debian contributors.

Precisely.  From a _user_'s point of view (or an NMUer, or security
responder) dgit offers the same workflow for all packages.

This is possible because dgit is mostly a converter between different
source package representations, along with knowledge of where to find
these representations and when to do what kind of conversion.


Ian.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Jonathan Dowland]

On Mon, May 22, 2017 at 10:07:20PM +0100, James Clarke wrote:
> There already effectively is a semi-"primary" implementation given that
> sbuild is used on the buildds.

Yes that is a very strong fact in favour of sbuild.

> And as for making these "secondary" implementations not geared for real
> users, for whom would they then be?

I was thinking of things like 'dash' which are pedantically POSIX compliant, 
serve to find
bugs in other scripts/shells but are not themselves recommended for end-user 
use (at least
interactively)

> There are lots of areas where Debian has far too many tools to
> accomplish the same thing, but I don't think this is one of them; there
> are only two main tools for building in chroots (sbuild and
> pbuilder[0]), both of which have significant user bases.
> [0] cowbuilder is a thin wrapper that behaves (almost) identically, so
> it doesn't really count as something different

Fair enough, cowbuilder was one of the ones in my hazy peripheral vision as
"another", along with some tools to use things like docker that I am aware of
but couldn't remember the names. None of them have the same traction as
pbuilder or sbuild. I've only used pbuilder myself personally.

> Anyway, I'm done with this debate; it's clear I have very different
> views from some on this matter.

The points you have made are a valuable contribution IMHO, thanks for making 
them.


-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Sean Whitton]

On Mon, May 22, 2017 at 09:22:00PM +0100, Sean Whitton wrote:
> On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote:
> > Of course, dgit is yet another workflow and my understanding is that
> > git-buildpackage (without dgit) is far more commonly used in Debian.
> 
> This isn't fair to dgit.  While it does impose some minimal requirements
> upon git trees, it is otherwise workflow neutral.  This is evidenced by
> the fact that there are already several distinct dgit-compatible
> workflows documented in the dgit-maint-*(7) namespace.

I re-read Ian's e-mail and realised I wasn't quite fair to you, either :)

Ian did claim that dgit gives you one workflow for all Debian packages.
It does indeed provide that.  What I should have said was that it does
not enforce /that/ workflow; it just makes it available, primarily for
the benefit of NMUers and those who aren't already Debian contributors.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Marc Haber]

On Mon, 22 May 2017 22:20:29 +0200, Andreas Tille 
wrote:
>On Mon, May 22, 2017 at 10:46:59PM +0500, Andrey Rahmatullin wrote:
>> On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote:
>> > there's just a hundred Debian workflows to maintain a package and 200
>> > manuals for that.
>> No, no, there are more workflows than manuals for them.
>
>For instance there is no manual for cdbs (at least I have not yet found
>one that helps you over the real hurdles).

cdbs docs used to be pretty good. Or at least I remember them to be
that way before I switched to dh.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Holger Levsen]

Hi Andreas,

On Thu, May 18, 2017 at 09:07:53AM +0200, Andreas Tille wrote:
> > I think that in the mid-term (probably even in short term) you'll *save*
> > developer time by switching to git,
> And your thinking is based on what arguments?  

a.) git is a lot faster than svn on most operations, which btw does not allow
one to get things done faster, but also enables one to do things which one
would never do with svn… (because its just so damn slow…)

b.) if one needs to know and use several scm tools, one will make more mistakes
using those tools (as you explained in the mail I'm replying to…)

> > I'd be happy if Debian would enforce git for every source package now!
> 
> I'm willing to adapt to such decision but I feel my time totally wasted
> to do a SVN versus Git flamewar (and this is my last mail regarding
> this).
 
oh, yes, surely a flamewar helps noone. just to make a good decision one
needs to discuss, and again, best without flamewars! :)
 
> I fully agree and I'm known for team highjacking packages into Git
> repositories in several cases (and was also critizised about doing so).

I applaud you for doing so.

> > And probably we should all just use git.
> If we really could agree upon a common workflow I will definitely adapt.
> But there is no such agreement as far as I can see.

quite probably there will always be some with who will not use debhelper,
not use version control, ignore bugs in stable, dont tests their uploads, 
doing foo, but that shouldnt stop everybody else from agreeing on things.

>  Please take my
> previous mail rather as an explanation for the current state than my
> definite wish to keep the status quo under any circumstance.

happily noted. also noted that half of the packages you're uploading to main
*are* maintained in git :) (and the other half svn… /me likes stats too much :)
 

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[James Clarke]

On Mon, May 22, 2017 at 05:10:26PM +0100, Jonathan Dowland wrote:
> On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote:
> > On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
> > > Excellent, this is a great start, and seeing "Michael Stapelberg" for me 
> > > is an
>^^^
> > > indication of quality.
>
> emphasis on *start*

To qualify as "great" I think you should be accurate, but hey, maybe I
have too high standards. Anyway the main point wasn't to attack you but
to provide another side to that blog post.

> > You say that, but this is incredibly biased. Even he admits that in the
> > colour choice.
>
> I was completely ignoring the colour choices and implementation language.
>
> > that for the sbuild path, schroot is completely missing
>
> Indeed there are a lot of omissions. I think the next step, whether this
> is the basis for what goes next, or not, would be to get the source of
> this picture (or another) into a version control system so it can be
> iteratively and collaboratively improved.

That sounds sensible (for the uncoloured version).

> [ Stapelberg via James Clarke ]
> > > I propose to eliminate complexity in Debian by deprecating the
> > > pbuilder toolchain in favor of sbuild.
> >
> > Now, I am not necessarily against simplifying workflows, but choosing
> > one to rule the all arbitrarily because you prefer the language it's
> > written in is not the way to go about it.
>
> Language should be a factor, as there are practical considerations that can't
> be avoided, independent of personal preferences – but I got the impression
> that he was not coming to this conclusion soley on the basis of implementation
> language anyway, nor soley in terms of his own preferences for implementation
> language.

Sure, language can be important, but I would say Bash and C are *more*
accessible to the average developer these days than Perl, and that's
only going to become more true over time. He didn't give any other
reasons, but if there are, these would be welcome in the form of
constructive bug reports so we can address them and make the situation
better for everyone.

> > There are also benefits to having a variety of implementations; they behave
> > slightly differently, sometimes not implementing policy in the same way, and
> > this can be a good thing, allowing policy to be clarified, or finding
> > mistakes in the other builder, or just exposing flaws in your package.
>
> These are good points. However, considering just these points in isolation,
> the "secondary" implementation(s) would not need to be something that was
> actually geared towards real users, or advertised as such.

There already effectively is a semi-"primary" implementation given that
sbuild is used on the buildds. And as for making these "secondary"
implementations not geared for real users, for whom would they then be?
Designating a certain tool as "primary" will just lead its behaviour
becoming the de facto policy, so everyone will be required to build with
it locally, and so nobody would even consider using a secondary
alternative.

> > I'm not trying to sell pbuilder over sbuild here though; there are also many
> > ways in which sbuild is better than pbuilder.
>
> I am not (yet) familiar enough with either of them (or the other dozen or so
> similar tools for the same job) to come to a conclusion on what I think would
> be the correct number/recommendations for Debian contributors, but I am of the
> initial opinion that there are too many. I've heard a lot of good things about
> sbuild.

There are lots of areas where Debian has far too many tools to
accomplish the same thing, but I don't think this is one of them; there
are only two main tools for building in chroots (sbuild and
pbuilder[0]), both of which have significant user bases.

Anyway, I'm done with this debate; it's clear I have very different
views from some on this matter.

James

[0] cowbuilder is a thin wrapper that behaves (almost) identically, so
it doesn't really count as something different

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Sean Whitton]

On Mon, May 22, 2017 at 03:07:42PM +0100, Ian Jackson wrote:
> Areas of work that could do with attention from people with relevant
> expertise and effort:
> 
>  * Getting rid of the need to mess with the changelog.  That might
>involve changes to Debian changelog practice, or better tooling (eg
>yet another wrapper around dpkg-buildpackage - maybe a way to set
>the version without committing? - etc. etc.)

A way to set the version during the build, as you suggest, would be
sufficient to cover this.  It is hard to see how we could relieve the
user of the need to understand how to choose a version number for a .deb
for testing.  An option to set the version in the build command line
would remove the need for Debian source package knowledge.

>  * Pull request workflow for submitting changes.  This should
>eventually turn into a bug submission to the Debian BTS.
>This sounds to me like it probabl needs to be a web service, but
>perhaps some local client utility that looked enough like a web
>page would do.

We basically already have all the pieces:

- git-request-pull(1)
- reportbug(1)
- git hosting on alioth / our shiny pagure git hosting (coming soon)

dgit could ship a script that ties these together.  (The reason I suggest
using our own git hosting is so that the branch doesn't disappear -- one
advantage of patches in the BTS is that they can't 404.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Sean Whitton]

On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote:
> Of course, dgit is yet another workflow and my understanding is that
> git-buildpackage (without dgit) is far more commonly used in Debian.

This isn't fair to dgit.  While it does impose some minimal requirements
upon git trees, it is otherwise workflow neutral.  This is evidenced by
the fact that there are already several distinct dgit-compatible
workflows documented in the dgit-maint-*(7) namespace.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Andreas Tille]

On Mon, May 22, 2017 at 10:46:59PM +0500, Andrey Rahmatullin wrote:
> On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote:
> > there's just a hundred Debian workflows to maintain a package and 200
> > manuals for that.
> No, no, there are more workflows than manuals for them.

For instance there is no manual for cdbs (at least I have not yet found
one that helps you over the real hurdles).

SCNR

  Andreas.

-- 
http://fam-tille.de

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Zlatan Todoric]

On 05/22/2017 07:42 PM, Jeremy Bicha wrote:
> On Mon, May 22, 2017 at 10:07 AM, Ian Jackson
> <ijack...@chiark.greenend.org.uk> wrote:
>> Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away 
>> from (unsupportable) FusionForge on Alioth?)"):
>> I would encourage anyone who has effort to work on this end of the
>> contributor experience to consider what dgit has to offer.  dgit
>> provides a single git workflow for all Debian packages.
> Of course, dgit is yet another workflow and my understanding is that
> git-buildpackage (without dgit) is far more commonly used in Debian.
>
> Thanks,
> Jeremy Bicha
>
https://xkcd.com/927/

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Andrey Rahmatullin]

On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote:
> there's just a hundred Debian workflows to maintain a package and 200
> manuals for that.
No, no, there are more workflows than manuals for them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Jeremy Bicha]

On Mon, May 22, 2017 at 10:07 AM, Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away 
> from (unsupportable) FusionForge on Alioth?)"):
> I would encourage anyone who has effort to work on this end of the
> contributor experience to consider what dgit has to offer.  dgit
> provides a single git workflow for all Debian packages.

Of course, dgit is yet another workflow and my understanding is that
git-buildpackage (without dgit) is far more commonly used in Debian.

Thanks,
Jeremy Bicha

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Jonathan Dowland]

On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote:
> On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
> > Excellent, this is a great start, and seeing "Michael Stapelberg" for me is 
> > an
 ^^^
> > indication of quality.

emphasis on *start*

> You say that, but this is incredibly biased. Even he admits that in the
> colour choice.

I was completely ignoring the colour choices and implementation language.

> that for the sbuild path, schroot is completely missing

Indeed there are a lot of omissions. I think the next step, whether this
is the basis for what goes next, or not, would be to get the source of
this picture (or another) into a version control system so it can be
iteratively and collaboratively improved.

[ Stapelberg via James Clarke ]
> > I propose to eliminate complexity in Debian by deprecating the
> > pbuilder toolchain in favor of sbuild.
> 
> Now, I am not necessarily against simplifying workflows, but choosing
> one to rule the all arbitrarily because you prefer the language it's
> written in is not the way to go about it.

Language should be a factor, as there are practical considerations that can't
be avoided, independent of personal preferences – but I got the impression
that he was not coming to this conclusion soley on the basis of implementation
language anyway, nor soley in terms of his own preferences for implementation
language.

> There are also benefits to having a variety of implementations; they behave
> slightly differently, sometimes not implementing policy in the same way, and
> this can be a good thing, allowing policy to be clarified, or finding
> mistakes in the other builder, or just exposing flaws in your package.

These are good points. However, considering just these points in isolation,
the "secondary" implementation(s) would not need to be something that was
actually geared towards real users, or advertised as such.

> I'm not trying to sell pbuilder over sbuild here though; there are also many
> ways in which sbuild is better than pbuilder.

I am not (yet) familiar enough with either of them (or the other dozen or so
similar tools for the same job) to come to a conclusion on what I think would
be the correct number/recommendations for Debian contributors, but I am of the
initial opinion that there are too many. I've heard a lot of good things about
sbuild.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[James Clarke]

On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
> On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote:
> > Someone else already had this idea:
> >
> > https://people.debian.org/~stapelberg//2016/11/25/build-tools.html
>
> Excellent, this is a great start, and seeing "Michael Stapelberg" for me is an
> indication of quality.

You say that, but this is incredibly biased. Even he admits that in the
colour choice. Disclaimer: as the cowbuilder maintainer (which comes
from the cow*dancer* source package, for historical reasons, despite
what the diagram may tell you) I am of course also biased. But I notice
that for the sbuild path, schroot is completely missing, which is
implemented in C++ and therefore probably deserves a bright red colour
just like cowbuilder in his second picture (or maybe even something
worse, depending on your views of C++). Then there's the extremely
unhelfpul, hostile comment at the end:

> I propose to eliminate complexity in Debian by deprecating the
> pbuilder toolchain in favor of sbuild.

Now, I am not necessarily against simplifying workflows, but choosing
one to rule the all arbitrarily because you prefer the language it's
written in is not the way to go about it. There are also benefits to
having a variety of implementations; they behave slightly differently,
sometimes not implementing policy in the same way, and this can be a
good thing, allowing policy to be clarified, or finding mistakes in the
other builder, or just exposing flaws in your package. For example,
pbuilder will by default use a new isolated network namespace for the
build, whereas sbuild won't, so if you just use sbuild you may not be
aware of violating policy (4.9). I'm not trying to sell pbuilder over
sbuild here though; there are also many ways in which sbuild is better
than pbuilder.

James

infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Ian Jackson]

Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away 
from (unsupportable) FusionForge on Alioth?)"):
> I can totally confirm this. When people ask me how to get foo fixed in Debian
> and I start explaining the above, people role their eyes and point to this:

Yes.

> there have been a few trying to stick around but often they dont
> know where to move on, as there is no "Debian workflow", no "Debian
> manual", there's just a hundred Debian workflows to maintain a
> package and 200 manuals for that.

I would encourage anyone who has effort to work on this end of the
contributor experience to consider what dgit has to offer.  dgit
provides a single git workflow for all Debian packages.

Depending on the maintainer's workflow practices, the history may be
poor, but the code is there in your git tree just like a non-Debian
git user would expect, and patches can be cherry-picked straight onto
it off upstream branches.

The dgit user does not need to know anything about the Debian
packaging teams or workflow rules or to read package-specific
documentation from the maintainer; nor do they need to know anything
about Debian source *packages* (as opposed to source *trees*).

To do a test build and install the user does need to know
some runes, and they do need to mess with the changelog:
  https://manpages.debian.org/jessie-backports/dgit/dgit-user.7.en.html
(And of course if they want to change packaging they will need to know
or learn about whatever it is they're changing.)

Areas of work that could do with attention from people with relevant
expertise and effort:

 * Getting rid of the need to mess with the changelog.  That might
   involve changes to Debian changelog practice, or better tooling (eg
   yet another wrapper around dpkg-buildpackage - maybe a way to set
   the version without committing? - etc. etc.)

 * Pull request workflow for submitting changes.  This should
   eventually turn into a bug submission to the Debian BTS.
   This sounds to me like it probabl needs to be a web service, but
   perhaps some local client utility that looked enough like a web
   page would do.

 * User/contributor testing to discover other roadblocks that make
   contribution tricky.

An area that I am working on myself is:

 * A way to do a new upstream version that does not involve the user
   having to mess with Debian source packages.  Sadly I can't see how
   to do this in a reasonable way without interacting with the
   maintainers' git workflows; for now, I am working on a way for
   maintainer(s) to cooperate using git branches as the interchange
   format, with the patch stacks on upstream worked on as a rebasing
   git branch.

Ian.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Jonathan Dowland]

On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote:
> Someone else already had this idea:
> 
> https://people.debian.org/~stapelberg//2016/11/25/build-tools.html

Excellent, this is a great start, and seeing "Michael Stapelberg" for me is an
indication of quality.



-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Jonathan Dowland]

On Mon, May 22, 2017 at 12:28:01PM +0200, Emilio Pozuelo Monfort wrote:
> Do you mean cdbs rather than cmake? I'm struggling to make a connection 
> between
> dh and cmake.

Yes, I do; thanks for the correction.

(although it does remind me that this issue of more-than-one-way-to-do-it 
extends
up to upstreams, too)

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Sean Whitton]

On Mon, May 22, 2017 at 10:29:24AM +0100, Jonathan Dowland wrote:
> I often think about this problem, and I start to wonder if step 0 is to try 
> and
> enumerate it properly. That is: I picture in my mind some kind of huge diagram
> (perhaps generated from more structured data, I dunno, something into a 
> graphviz)
> of a landscape of debian developer tools, grouped by some kind of
> categorisation that might overlap (venn diagram style), so you'd have dh and
> cmake in one place, git-buildpackage, dgit, possibly others in another; and
> also our documentation: not just maint-guide but developers-reference, wiki
> pages, etc.

Someone else already had this idea:

https://people.debian.org/~stapelberg//2016/11/25/build-tools.html

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Emilio Pozuelo Monfort]

On 22/05/17 11:29, Jonathan Dowland wrote:
> I often think about this problem, and I start to wonder if step 0 is to try 
> and
> enumerate it properly. That is: I picture in my mind some kind of huge diagram
> (perhaps generated from more structured data, I dunno, something into a 
> graphviz)
> of a landscape of debian developer tools, grouped by some kind of
> categorisation that might overlap (venn diagram style), so you'd have dh and
> cmake in one place, git-buildpackage, dgit, possibly others in another; and
> also our documentation: not just maint-guide but developers-reference, wiki
> pages, etc.
> 
> Such a thing could potentially be annotated with relevant statistics (number
> of source packages in archive using dh; cmake; etc.; number with Vcs headers,
> pointing at git or svn or ... repos;)

Do you mean cdbs rather than cmake? I'm struggling to make a connection between
dh and cmake.

Cheers,
Emilio

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Jonathan Dowland]

I often think about this problem, and I start to wonder if step 0 is to try and
enumerate it properly. That is: I picture in my mind some kind of huge diagram
(perhaps generated from more structured data, I dunno, something into a 
graphviz)
of a landscape of debian developer tools, grouped by some kind of
categorisation that might overlap (venn diagram style), so you'd have dh and
cmake in one place, git-buildpackage, dgit, possibly others in another; and
also our documentation: not just maint-guide but developers-reference, wiki
pages, etc.

Such a thing could potentially be annotated with relevant statistics (number
of source packages in archive using dh; cmake; etc.; number with Vcs headers,
pointing at git or svn or ... repos;)

I'm inspired by the Debian Women wiki's diagrams of packaging workflows which
took existing flows and presented them in a way that made them much easier to
understand as a whole (and also made it clearer how complex they are, or aren't)

Then we could look to see what should be eliminated in order to make the diagram
simpler.

We could re-calculate/draw the diagram on a regular basis: annually (or even
monthly if we had much movement behind this idea of simplifying the landscape)
to see what the current state of the art is, and compare it to the case last
time.

We could even attempt to formulate the 'ideal picture' diagram, as something to
work towards, although we would not likely get a complete consensus on any one
version of that.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Holger Levsen]

On Mon, May 22, 2017 at 07:52:34AM +, Riku Voipio wrote:
> Right now, if you have a minor change - such fixing Homepage: or typo on
> definition, it's not as straitforward as submitting a pull request. And
> it gets much worse if you want to patch against upstream or build a new
> upstream version. Every maintainer has their own preferred workflow which
> a new contributor needs to adapt to.

_this_!

I can totally confirm this. When people ask me how to get foo fixed in Debian
and I start explaining the above, people role their eyes and point to this:

> [...] But for better or worse, there is now a generation that has
> become used to github style use. And if we want avoid Debian becoming an
> old grumpy mens club, we have cater for them.

and then most of these people move on without bothering trying to fix it.

there have been a few trying to stick around but often they dont know where
to move on, as there is no "Debian workflow", no "Debian manual", there's just
a hundred Debian workflows to maintain a package and 200 manuals for that.

The nice thing about standards is *not* that there are so many to choose from.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Riku Voipio]

On Fri, May 19, 2017 at 01:56:17PM +0200, Andreas Tille wrote:
> If (and only if) there would be some momentum for a move to Git neither
> I nor any other member of the Debian Med team will block this.  But for
> the moment I keep on failing to see an advantage only out of the fact
> that "it is possible". 

I think the key advantage is lowering the barrier of contribution. Which is
a bit funny how we ended up so - as git is the most painful to use VCS
after tla. But for better or worse, there is now a generation that has
become used to github style use. And if we want avoid Debian becoming an
old grumpy mens club, we have cater for them.

Right now, if you have a minor change - such fixing Homepage: or typo on
definition, it's not as straitforward as submitting a pull request. And
it gets much worse if you want to patch against upstream or build a new
upstream version. Every maintainer has their own preferred workflow which
a new contributor needs to adapt to.

Consolodating around git/pagure could help here.

Riku

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Zlatan Todoric]

On 05/21/2017 09:17 AM, Wouter Verhelst wrote:
> On Mon, May 15, 2017 at 09:45:46PM +0200, Zlatan Todoric wrote:
>>
>> On 05/15/2017 02:02 PM, Lars Wirzenius wrote:
>>> On Mon, May 15, 2017 at 01:42:09PM +0200, Arturo Borrero Gonzalez wrote:
 On 15 May 2017 at 13:30, Paul Wise  wrote:
> TBH if I was confronted with the new LXDE web design with CSS turned
> on, I would probably just close the page. The old page is way more
> informative and less heavy on the marketing.
>
 Hi Paul,

 I believe that what we are actually looking for is a bit of
 improvement in the marketing side.
 Modern and fancy things.

 The LXDE example is good on that.
>>> http://lxde.org/ seems to be the site in question. I agree with Paul,
>>> I don't like it, and when I encounter pages in that style, I tend to
>>> close the window.
>> Then lets forget about getting newcomers (fresh blood) to Debian as
>> you're so close minded to modern/new things - the same way they probably
>> close the window when they see '90 style with a lot of text that
>> actually says nothing.
> Sorry, but no.
>
> There's a difference between "let's use a random default design from
> some design website that has five buttons and a few slogans" and an
> actual, working, responsive design.
>
> Debian does need the latter, yes. It does not need the former. LXDE did
> choose that.
>
I kinda fail to see to what are you objecting and on what are you
commenting. All what I argued here is that we need to modernize website
(I even recall people complaining about how hard is to download things
so we put link right there on the first page and it still is not the
best) and I am for sure not in favor of LXDE but I am sure that their
website is more appealing than ours. Being technical excellent doesn't
mean we are design/artistic excellent so we should welcome those
contributors as well, and RTFM attitude that many have is not going to
help anything, on contrary it is going to alienate.

I agree with paultag, we need to have some to conduct research on this
(and we need to be open minded about it) and then do a redesign (I am in
favor of clean one rather than fixing old one, just adopt text and move
forward or I fear it is going to stay stuck in time).

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Wouter Verhelst]

On Mon, May 15, 2017 at 09:45:46PM +0200, Zlatan Todoric wrote:
> 
> 
> On 05/15/2017 02:02 PM, Lars Wirzenius wrote:
> > On Mon, May 15, 2017 at 01:42:09PM +0200, Arturo Borrero Gonzalez wrote:
> >> On 15 May 2017 at 13:30, Paul Wise  wrote:
> >>> TBH if I was confronted with the new LXDE web design with CSS turned
> >>> on, I would probably just close the page. The old page is way more
> >>> informative and less heavy on the marketing.
> >>>
> >> Hi Paul,
> >>
> >> I believe that what we are actually looking for is a bit of
> >> improvement in the marketing side.
> >> Modern and fancy things.
> >>
> >> The LXDE example is good on that.
> > http://lxde.org/ seems to be the site in question. I agree with Paul,
> > I don't like it, and when I encounter pages in that style, I tend to
> > close the window.
> 
> Then lets forget about getting newcomers (fresh blood) to Debian as
> you're so close minded to modern/new things - the same way they probably
> close the window when they see '90 style with a lot of text that
> actually says nothing.

Sorry, but no.

There's a difference between "let's use a random default design from
some design website that has five buttons and a few slogans" and an
actual, working, responsive design.

Debian does need the latter, yes. It does not need the former. LXDE did
choose that.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Sean Whitton]

Hello Paul,

On Fri, May 19, 2017 at 01:25:06PM -0400, Paul Tagliamonte wrote:
> I, frankly, don't even pretend to care what our developer community
> thinks of the site -- the site isn't just for you.

I agree that it would be great to have data from usability testing of
our site.

I disagree with the extent to which you deprioritise what our developer
community thinks of the site.  It would be quite demotivating to a lot
of us if the site ran contrary to various of our community values.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: LXDE web page bashing thread Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Medical Wei]

The website is on GitHub so anyone can suggest things by throwing me issues
or PRs at
https://github.com/lxde/lxde.org

The hamburger menu requiring JavaScript is something that I don't have good
alternative with right now.

Also, welcome back, Martin :)

Yao Wei
On Fri, 19 May 2017 at 21:18 Martin Bagge / brother 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2017-05-19 15:00, Zlatan Todoric wrote:
> > Well Debian on its page doesn't mention it is Linux based
> > or has Linux kernel or at all word Linux.
>  We have Linux, HURD and the FreeBSD kernel, though.  I
>  suspect the thought was Debian hopes its practices, values
>  and community will outlive any specific kernel, just like
>  they could outlive apt/dpkg.
> 
> >>> You could add the quote on which I quoted (lxde page doesn't
> >>> say it can be installable on linux) so my comment makes more
> >>> sense
> >> Sorry, I'm still not sure what you mean.
> >>
> > I mentioned Linux because it was previously mentioned that LXDE
> > page doesn't mention it can be installed on Linux (and afaik it can
> > be also on FreeBSD/Hurd?).
>
> You need to be some special type of person to not understand that
> At
>  http://lxde.org
> they have one big red button in the center that takes you to
>  http://lxde.org/get/
> Linux is mentioned in the second sentence.
> BSD is mentioned in the second bold sentence.
>
> The LXDE page has some problems but lack of mentioning supported
> systems isn't one of them.
>
> It seems like they decided to focus on two types of audiences.
>  - those who are somewhat familiar with LXDE by name and like to try it.
>  - those who like to find the code of it.
>
> If I still was involved in the project I would suggest they move the
> "join" part up to a more prominent spot, it's buried at the the front
> page after help text and unhelpful texts about some features of LXDE
> (in panels that are totally not clickable but should have been).
>
> The hamburger menu top right shows the join option as number three,
> more sane priority in my opinion.
>
> - --
> brother
> http://sis.bthstudent.se
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlke8IsACgkQOIRDexPY
> /4v5Nw/7B9UBwo9221aPALXxqFYepekr6c5UOhC0bZcnOCLhf1bXgT7F1wBYDxU+
> JdEPSDTn8kNs6H+cbdHCbaSPA3WCMMdHUooylpj02yuvpuC84zjXxD7utnT6KLNE
> On3V4RbwzegMTgnKCaZz8YTNsVV9DQTCTnayKeuQ4n+C1e/zffQaI3ppkpZjSViM
> Oobt7Hp87yLKHTU2DgEZiKmI3L5brdNGQtV9hAglRgwTtMMcYaB+JHT2MHKj1YnY
> TXUdWDexQqsz47bsZa7UO4PAR+/o/L8hJB3MytV4hc6BCka3CVESYkrttoRqnyRu
> rh4W1no/ko6wRUjIuK2C2E6e0RB7vadGnSZUaowDyvFPr1+VF2Q8pv8ajaM6bMLG
> 0Tq97yj8iNM+QodsX2e2mjXe31LUOxgVUiB2wLMko+AN5FssLoOmFDzzA1AW9+oo
> RWi0KkGmMFjE/q8tItIAFgT9BJmd/xWOokdwNyc45gVXpSpIrja1/ZKJaHFzg59M
> Chf6en/hYtUlUlQFlaVdIdxn5VCGAfteDwdvV3t4SXcAxO4DEIgxonPlPIX7EoHa
> HfyNKR9IvSiAH8fdf9wdFnVaIuTkgUYcwn7/6Ps6xKAt9MnQ1BxEnkEyTV1c4ZWX
> EyE6gwmb65chmA6mmt2RyBW1FLbILyHHTaHIHwJBBon9MoyInBU=
> =qXxI
> -END PGP SIGNATURE-
>
>

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Paul Tagliamonte]

[loads of bikeshedding and grandstanding]

So this thread is a shitshow.



Has anyone thought about taking the website (or really, anything we put
out), going and talking with **our users** and see what they have to
say? What they think of the site? Record them finding and creating an
install medium?


I, frankly, don't even pretend to care what our developer community
thinks of the site -- the site isn't just for you.


Until someone comes back with data on what things are easy, what things
are hard, and large enough sample sizes covering an *accurate* slice of
our userbase, I don't care about what anyone on this thread says.


   Paul


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Hans]

Hi there,

please remember: it is not the design, that makes a website interesting, but 
the content! 

So maybe we should first discuss, and maybe confirm, what might people interest 
on the debian site. 

I suggest just to collect ideas, and make a ranking (i.e. freedom was named 
1563 times, low cost was named 873 times and so on) and then express the top 
ranks on the site. 

IMO for example, "stability" and "freedom" might new users not interest at 
first, but maybe "runs office, multimedia, graphics" or "be safe from windows 
viruses" or "faster than windows" might interest people more than "freedom".

Also the term "cost nothing, for free!" might not interest people, as people 
believe, MS-Windows on computers they buy is also for free (which of course is 
NOT!)

I think, you know, what I want to say. 

Just my 3,1415926 cents.

Best regards

Hans

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Jonathan Dowland]

On Thu, May 18, 2017 at 01:40:03PM +0200, Andreas Tille wrote:
> In last GSoC the student was not comfortable with SVN.  I have converted
> lots of packages at request of the student.  So I'm perfectly following
> your reasoning if (and only if) there are potential packaging
> contributors at horizon.

Oh sure, I didn't mean to say I think you should be *doing* any different,
merely that the rationale you gave (user experience) for doing so (or not)
didn't cover the problem case.


-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

LXDE web page bashing thread Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2017-05-19 15:00, Zlatan Todoric wrote:
> Well Debian on its page doesn't mention it is Linux based
> or has Linux kernel or at all word Linux.
 We have Linux, HURD and the FreeBSD kernel, though.  I
 suspect the thought was Debian hopes its practices, values
 and community will outlive any specific kernel, just like
 they could outlive apt/dpkg.
 
>>> You could add the quote on which I quoted (lxde page doesn't
>>> say it can be installable on linux) so my comment makes more
>>> sense
>> Sorry, I'm still not sure what you mean.
>> 
> I mentioned Linux because it was previously mentioned that LXDE
> page doesn't mention it can be installed on Linux (and afaik it can
> be also on FreeBSD/Hurd?).

You need to be some special type of person to not understand that
At
 http://lxde.org
they have one big red button in the center that takes you to
 http://lxde.org/get/
Linux is mentioned in the second sentence.
BSD is mentioned in the second bold sentence.

The LXDE page has some problems but lack of mentioning supported
systems isn't one of them.

It seems like they decided to focus on two types of audiences.
 - those who are somewhat familiar with LXDE by name and like to try it.
 - those who like to find the code of it.

If I still was involved in the project I would suggest they move the
"join" part up to a more prominent spot, it's buried at the the front
page after help text and unhelpful texts about some features of LXDE
(in panels that are totally not clickable but should have been).

The hamburger menu top right shows the join option as number three,
more sane priority in my opinion.

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlke8IsACgkQOIRDexPY
/4v5Nw/7B9UBwo9221aPALXxqFYepekr6c5UOhC0bZcnOCLhf1bXgT7F1wBYDxU+
JdEPSDTn8kNs6H+cbdHCbaSPA3WCMMdHUooylpj02yuvpuC84zjXxD7utnT6KLNE
On3V4RbwzegMTgnKCaZz8YTNsVV9DQTCTnayKeuQ4n+C1e/zffQaI3ppkpZjSViM
Oobt7Hp87yLKHTU2DgEZiKmI3L5brdNGQtV9hAglRgwTtMMcYaB+JHT2MHKj1YnY
TXUdWDexQqsz47bsZa7UO4PAR+/o/L8hJB3MytV4hc6BCka3CVESYkrttoRqnyRu
rh4W1no/ko6wRUjIuK2C2E6e0RB7vadGnSZUaowDyvFPr1+VF2Q8pv8ajaM6bMLG
0Tq97yj8iNM+QodsX2e2mjXe31LUOxgVUiB2wLMko+AN5FssLoOmFDzzA1AW9+oo
RWi0KkGmMFjE/q8tItIAFgT9BJmd/xWOokdwNyc45gVXpSpIrja1/ZKJaHFzg59M
Chf6en/hYtUlUlQFlaVdIdxn5VCGAfteDwdvV3t4SXcAxO4DEIgxonPlPIX7EoHa
HfyNKR9IvSiAH8fdf9wdFnVaIuTkgUYcwn7/6Ps6xKAt9MnQ1BxEnkEyTV1c4ZWX
EyE6gwmb65chmA6mmt2RyBW1FLbILyHHTaHIHwJBBon9MoyInBU=
=qXxI
-END PGP SIGNATURE-

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Zlatan Todoric]

On 05/18/2017 12:32 PM, Sean Whitton wrote:
> Hello Zlatan,
> [...]
>
> The community consensus seems to be that we want to promote ourselves,
> but we care more about providing quality information than do the people
> who designed sites like lxde.org (sorry to keep using that example).
> This consensus position is itself a value of our community, and an
> aspect of its identity.

lxde page is bad, I didn't say anything about the quality of information
on it but I do think (and would love to be proven otherwise) that
average Joe of 2017 will feel more appealed towards lxde page than our
debian.org. I do agree that quality shouldn't suffer but than we do have
a lot of out-of-date docs, Arch wiki being much better than our own etc
etc. We need to improve the quality overall and make it more accessible
to everyone and that includes people who use modern workflows/moder
views/designs etc. Or run a huge global survey what people want to see
from Debian...

 Well Debian on its page doesn't mention it is Linux based or has
 Linux kernel or at all word Linux.
>>> We have Linux, HURD and the FreeBSD kernel, though.  I suspect the
>>> thought was Debian hopes its practices, values and community will
>>> outlive any specific kernel, just like they could outlive apt/dpkg.
>>>
>> You could add the quote on which I quoted (lxde page doesn't say it can
>> be installable on linux) so my comment makes more sense
> Sorry, I'm still not sure what you mean.
>
I mentioned Linux because it was previously mentioned that LXDE page
doesn't mention it can be installed on Linux (and afaik it can be also
on FreeBSD/Hurd?).



signature.asc
Description: OpenPGP digital signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Andreas Tille]

Hi Guido,

On Fri, May 19, 2017 at 01:35:58PM +0200, Guido Günther wrote:
> 
> Keeping only debian/ in git is supported by gbp as well (see
> --git-overlay).

Thanks for the hint - I've seen this and I'm aware of it.

> AFAIK It's not that commonly used so there might be bugs
> lurking and features lacking but it might be worth a try in case there
> is some momenturm for moving to git.

If (and only if) there would be some momentum for a move to Git neither
I nor any other member of the Debian Med team will block this.  But for
the moment I keep on failing to see an advantage only out of the fact
that "it is possible". 

Thanks anyway

   Andreas.

-- 
http://fam-tille.de

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Guido Günther]

On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote:
> Hi,
> 
> On Mon, May 15, 2017 at 02:43:56PM +0200, Johannes Schauer wrote:
> > 
> > The top 10 teams with packages in SVN are:
> > 
> > 347 Debian Med Packaging Team 
> > 
> 
> This number contains possibly 150 packages that *could* be migrated -
> provided somebody wants to take the time for some unproductive work.
> However, we intentionally do packaging of new R CRAN packages in SVN
> since in this case packaging is brain dead simple and we keep only the
> debian/ dir and not the upstream source in VCS.  This is a sensible and
> established workflow and currently there is no short term plan to change
> this.

Keeping only debian/ in git is supported by gbp as well (see
--git-overlay). AFAIK It's not that commonly used so there might be bugs
lurking and features lacking but it might be worth a try in case there
is some momenturm for moving to git.
Cheers,
 -- Guido

> 
> In short:  There is no doubt that Git is the better VCS but spending
> developer time simply to switch lots of packages from an old VCS to a
> modern one has zero effect on users desktops and has no high priority.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Boyuan Yang]

在 2017年5月14日星期日 +08 下午2:33:19，Pirate Praveen 写道：
> On ഞായര്‍ 14 മെയ് 2017 02:23 വൈകു, Boyuan Yang wrote:
> > As a result, I'm writing to suggest we find an answer to such a problem
> > soon. Migration to Jessie or Stretch with new FusionForge version might
> > be possible. Or we should just drop outdated FusionForge and move to some
> > modern platforms like GitLab (with an alternated workflow possibly).
> 
> This is already planned (though pagure instead of gitlab). Anyone who
> wish to see it happen faster can help with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046

There are some pages about the alternative of FusionForge on Debian Wiki but 
they fail to describe the final decision:

[1] https://wiki.debian.org/Alioth/GitNext
[2] https://wiki.debian.org/Alioth/OtherForges
[3] https://wiki.debian.org/Shukra (for GitLab)

And I found a long thread on debian-devel saying GitLab won't be used due to 
controversy:

[4] https://lists.debian.org/debian-devel/2016/07/msg00510.html

If that's true, I will later update [1] according to [4], remove GitLab from 
the option list and describe pagure as the most possible sucessor of 
FusionForge. Tell me if that's not correct.

However, note that pagure is lacking features. For example, the authentication 
method only includes FAS (Fedora Account System) and local (local database). 
Obviously we need to implement support for Debian SSO/LDAP and migrate alioth 
account system by ourselves. (GitLab supports LDAP & OAuth2 [3] but anyway we 
are not using it.) I'm wondering where should related development work 
happens.

--
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Andreas Tille]

Hi Mattia,

On Wed, May 17, 2017 at 10:38:41PM +0200, Mattia Rizzolo wrote:
> I wonder...
> The problem here is about fusionforge only, in fact.
> If we were to move git (i.e. the vast majority of its usage) to another
> place, and took down fusionforge (i.e. no more guest user management), I
> do not think there is a reason to shut down the rest.
> SVN could stay there, with viewvc and everything, and let packages and
> project migrate whenever they need something not provided by old-alioth
> (f.e. direct contribution from a non-DD that won't be possible without
> fusionforge running to create its user and dealing with groups).

I like this suggestion.
 
> @tille: please have a look at pkg-haskell and their DHG_packages
> repository.  I've never interacted with it, and I find it highly unusual
> and non-standard that I doubt the usual tooling can deal with it, but it
> might of ispiration about how to deal with R packages maybe?

I confirm that I once had a short look into DHG_packages and I vaguely
considered this as a potential solution for R packages.  What keeps me
away from implementing it is that it also includes a change of workflows
(not only of users but also tools that are inspecting VCS need to be
rewritten).  So for the moment not to change a running system is my
prefered way to go - but thanks for the hint anyway.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Elisa Godoy de Castro Guerra]

One local team of BSP Debian paris ask me to propose a new webiste.
i did :)

If it fit to any use you need, i'm happy, if not, i'm happy to help in fit
it better :)
Elisa

2017-05-18 16:54 GMT+02:00 Sean Whitton :

> Hello Elisa,
>
> On Thu, May 18, 2017 at 03:14:49PM +0200, Elisa Godoy de Castro Guerra
> wrote:
> > To finish this website we need :
> > - the text to present stretch to news user to debian (who do ?)
>
> Are you suggesting this as a "Get Stretch" website, similar to
> ?
>
> This thread has been about replacing the whole debian.org website.
>
> --
> Sean Whitton
>



-- 
--
Elisa de Castro Guerra

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Sean Whitton]

Hello Elisa,

On Thu, May 18, 2017 at 03:14:49PM +0200, Elisa Godoy de Castro Guerra wrote:
> To finish this website we need :
> - the text to present stretch to news user to debian (who do ?)

Are you suggesting this as a "Get Stretch" website, similar to
?

This thread has been about replacing the whole debian.org website.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Elisa Godoy de Castro Guerra]

Thanks,

To finish this website we need :
- the text to present stretch to news user to debian (who do ?)
- more ilustration to be more firendly and attractive (i can do)
- official publication after official approval from community :)
- a available deadline to help in organization ^^'

2017-05-18 15:06 GMT+02:00 Sean Whitton :

> On Thu, May 18, 2017 at 02:37:33PM +0200, Elisa Godoy de Castro Guerra
> wrote:
> > I participate to the BSP debian meeting in paris last week end.
> > I propose a little webpage.
> > https://gitlab.com/yemanjalisa/debianstretchwebsite
> >
> > I would love finish this work to fit for your need.
> > I dit it very quickly on last sunday in collaboration with the all local
> team.
>
> This is really nice.  Thank you for contributing.
>
> It's a great idea to use the branding of the latest stable release for
> the splash (though I guess the existing website does that too).
>
> --
> Sean Whitton
>



-- 
--
Elisa de Castro Guerra

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Sean Whitton]

On Thu, May 18, 2017 at 02:37:33PM +0200, Elisa Godoy de Castro Guerra wrote:
> I participate to the BSP debian meeting in paris last week end.
> I propose a little webpage.
> https://gitlab.com/yemanjalisa/debianstretchwebsite
> 
> I would love finish this work to fit for your need.
> I dit it very quickly on last sunday in collaboration with the all local team.

This is really nice.  Thank you for contributing.

It's a great idea to use the branding of the latest stable release for
the splash (though I guess the existing website does that too).

-- 
Sean Whitton


signature.asc
Description: PGP signature

When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Elisa Godoy de Castro Guerra]

Hi,

My name is elisa, Sorry for my english...

I participate to the BSP debian meeting in paris last week end.
I propose a little webpage.
https://gitlab.com/yemanjalisa/debianstretchwebsite

I would love finish this work to fit for your need.
I dit it very quickly on last sunday in collaboration with the all local
team.

I would be happy to help anyone or take in charge this task.


Elisa



-- 
--

On Mon, 2017-05-15 at 11:19 +0200, Arturo Borrero Gonzalez wrote:
> On 14 May 2017 at 11:58, lumin  wrote:
> > On the other hand, I fancy modern platforms such
> > as Gitlab, as a user. And wondering when Debian
> > will update its homepage (www.d.o) to a modern
> > design[1].
> >
> > [1] This is off-thread, but some of my young
> > friends just gave up trying Debian at the
> > first glance at our homepage.
>
> off-thread, yes. But please spawn another thread to talk about this
> real issue.

> Our users are really complaining about our look in the web and
> we
> should address it.

I'm looking forward to a new design of our homepage, but I'm not
able to help since not familiar to this field.

Take a look at the homepages of major distros:
https://www.archlinux.org/https://www.centos.org/https://www.opensuse.org/https://manjaro.org/https://www.ubuntu.com/https://getfedora.org/https://linuxmint.com/https://gentoo.org/

Especially look at the homepage of Gentoo. Some of you must
remember the old gentoo homepage, but now gentoo has a way much
prettier face. Then look at ours
https://www.debian.org/

We are the last major distro that move to systemd as the
default init system. And now we are the last major distro
that keeps an old design of homepage.

Debian is a community that driven by volunteers. I believe
volunteers are working hard for community at the points
they are interested in. I guess, possibly there are too few
volunteers able/intend to update the design, so the homepage is
just kept as is.

If none of the volunteers is willing to contribute a new
design, what about spend some money to hire several worker
working on this. neilm pointed out that we don't know how
to spend our money at Debconf16, that we don't know how
to spend our money. Making the community better is a good
reason for doing so, since a modern design may
attract more users/contributors, and is less likely to scare
newbies away ...

Even if Debian is ranked number 2 at distrowatch.

Elisa de Castro Guerra

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Andreas Tille]

On Thu, May 18, 2017 at 10:43:44AM +0100, Jonathan Dowland wrote:
> > developer time simply to switch lots of packages from an old VCS to a
> > modern one has zero effect on users desktops and has no high priority.
> 
> Absolutely; the impact is on potential packaging contributors.

In last GSoC the student was not comfortable with SVN.  I have converted
lots of packages at request of the student.  So I'm perfectly following
your reasoning if (and only if) there are potential packaging
contributors at horizon.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Sean Whitton]

Hello Zlatan,

On Tue, May 16, 2017 at 02:58:14AM +0200, Zlatan Todoric wrote:
> Improving things doesn't mean destroying identity. We add and remove
> archs, we added graphical installer, we don't configure graphics
> manually anymore - did we loose identity? Social Contract and DFSG
> ensure our identity imho.

There are aspects of our community's identity that go beyond the text of
those documents, though those aspects could still be construed as
interpretations of clauses in those documents.

In this thread, we have seen views that are fiercely anti-promotion, and
views that are in favour of very radical modernisations to our site.

The community consensus seems to be that we want to promote ourselves,
but we care more about providing quality information than do the people
who designed sites like lxde.org (sorry to keep using that example).
This consensus position is itself a value of our community, and an
aspect of its identity.

> >> Well Debian on its page doesn't mention it is Linux based or has
> >> Linux kernel or at all word Linux.
> > We have Linux, HURD and the FreeBSD kernel, though.  I suspect the
> > thought was Debian hopes its practices, values and community will
> > outlive any specific kernel, just like they could outlive apt/dpkg.
> >
> You could add the quote on which I quoted (lxde page doesn't say it can
> be installable on linux) so my comment makes more sense

Sorry, I'm still not sure what you mean.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Sean Whitton]

On Tue, May 16, 2017 at 11:13:38AM +0100, Wookey wrote:
> I will observe that the debian wiki is a lot more up-to-date than the
> website because it is much easier to update (much as I admire wml as
> a tool/language).

A relevant read is 
https://joeyh.name/blog/entry/ending_the_tyranny_of_unix_permissions/

However, I'm not sure that our public front pages should be editable by
anyone, or even all DDs.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Sean Whitton]

On Thu, May 18, 2017 at 09:07:53AM +0200, Andreas Tille wrote:
> > And probably we should all just use git.
> 
> If we really could agree upon a common workflow I will definitely adapt.
> But there is no such agreement as far as I can see.

This is basically the problem.  It's not that we have to use exactly the
same workflow, but the differences between our workflows are large
enough that we can't have something like Fedora's specs repo (e.g. repos
with only the contents of debian/ -- inside or outside an enclosing
debian/ dir).

The best way to think about the current situation is to realise that the
archive is a (bad) VCS: an upload is a commit, so NMUs are commits.
Except for dgit, any repo is a secondary repo when compared to the
archive.

I have submitted a git packaging practices BoF for DebConf.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Sean Whitton]

On Wed, May 17, 2017 at 10:38:41PM +0200, Mattia Rizzolo wrote:
> I wonder...
> The problem here is about fusionforge only, in fact.
> If we were to move git (i.e. the vast majority of its usage) to another
> place, and took down fusionforge (i.e. no more guest user management), I
> do not think there is a reason to shut down the rest.
> SVN could stay there, with viewvc and everything, and let packages and
> project migrate whenever they need something not provided by old-alioth
> (f.e. direct contribution from a non-DD that won't be possible without
> fusionforge running to create its user and dealing with groups).

I assume that you mean a read-only dump of all the old CVS repos, which
could be hosted on a newer-than-wheezy machine?

> @tille: please have a look at pkg-haskell and their DHG_packages
> repository.  I've never interacted with it, and I find it highly
> unusual and non-standard that I doubt the usual tooling can deal with
> it, but it might of ispiration about how to deal with R packages
> maybe?

I /believe/ that the reason we have the monolithic DHG_packages is
because we frequently have to upload every or almost every Haskell
package at once (e.g. bump all build-deps to use new ghc and upload to
experimental).

I don't think it's because the workflow for packaging any given Haskell
package is very simple, which was what Andreas mentioned w.r.t. R.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Sean Whitton]

On Wed, May 17, 2017 at 11:49:26AM +0200, Steffen Möller wrote:
> We should vividly demonstrate on our home page that we are just that -
> alive and developing. If we could have users contribute success stories
> like "I switched my Granny from Windows to Debian and she likes it" or
> "We autoconfigure our HPC cluster in the cloud with Debian and Ansible,
> saving us 30 grand this year" then we have enough to get people hooked
> and invest to dig deeper into the site, I tend to think.

The git-annex website does this quite well:
https://git-annex.branchable.com/ ("use cases" in the middle)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Ole Streicher]

Andreas Tille  writes:
> I do not see a good reason to spent time into a migration from SVN to
> Git.

Isn't EOL of the hosting platform FusionForge a good reason?

Cheers

Ole

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Jonathan Dowland]

On Wed, May 17, 2017 at 11:12:53PM +, Holger Levsen wrote:
> git clone https://src.fedoraproject.org/cgit/rpms/${srcpkg}.git is really
> awesome and works for every package in Fedora! (*)

I haven't looked at it much yet but I though Ian Jackson's dgit was a pretty
neat solution to this problem; or if not a solution, a decent puzzle piece.


-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Jonathan Dowland]

On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote:
> In short:  There is no doubt that Git is the better VCS but spending
> developer time simply to switch lots of packages from an old VCS to a
> modern one has zero effect on users desktops and has no high priority.

Absolutely; the impact is on potential packaging contributors.
 

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Andreas Tille]

Hi Holger,

On Wed, May 17, 2017 at 11:12:53PM +, Holger Levsen wrote:
> On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote:
> > In short:  There is no doubt that Git is the better VCS but spending
> > developer time simply to switch lots of packages from an old VCS to a
> > modern one has zero effect on users desktops and has no high priority.
>  
> I think that in the mid-term (probably even in short term) you'll *save*
> developer time by switching to git,

And your thinking is based on what arguments?  As I tried to explain I'm
perfectly convinced that Git is way better in most cases - but those
superior features are not needed in all cases.  The only thing that would
save me some time in the cases I mentioned is that I from time to time
type

   svn commit -a
   git commit -a

if I actually mean

   svn commit

:-)

> And also you're imposing a stupid tool to anyone who wants to help out or
> do security fixes.

Hmmm, if those packages received any NMUs the NMUer never commited
anything anyway - so this argument is void.
 
> I'd be happy if Debian would enforce git for every source package now!

I'm willing to adapt to such decision but I feel my time totally wasted
to do a SVN versus Git flamewar (and this is my last mail regarding
this).
 
> Debian aims to be the universal OS, but that doesn't mean we have to support
> an universe of workflows and tools.

Surely we doesn't have to support various workflows but these have
developed over the time and I never had the impression that changes
in Debian happened with dead beat arguments.

> Everybody should be using version 
> control for their packages. Really.

I fully agree and I'm known for team highjacking packages into Git
repositories in several cases (and was also critizised about doing so).

> And probably we should all just use git.

If we really could agree upon a common workflow I will definitely adapt.
But there is no such agreement as far as I can see.  Please take my
previous mail rather as an explanation for the current state than my
definite wish to keep the status quo under any circumstance.

> And work together nicely.

+1
 
Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Andreas Tille]

Hi Tzafir,

On Thu, May 18, 2017 at 06:04:09AM +0200, Tzafrir Cohen wrote:
> > > The top 10 teams with packages in SVN are:
> > > 
> > > 347 Debian Med Packaging Team 
> > > 
> > 
> > This number contains possibly 150 packages that *could* be migrated -
> > provided somebody wants to take the time for some unproductive work.
> > However, we intentionally do packaging of new R CRAN packages in SVN
> > since in this case packaging is brain dead simple and we keep only the
> > debian/ dir and not the upstream source in VCS.  This is a sensible and
> > established workflow and currently there is no short term plan to change
> > this.
> 
> Just an obvious question: have you looked into
> 
>   gbp buildpackage --git-export

I wonder in how far is the question obvious when I tried to explain that
I do not see a good reason to spent time into a migration from SVN to
Git.  I have converted lots of packages where I had good reasons.

I admit that it would be a good reason if the project would decide to
support Git exclusively - but I for myself do not see any reason to
drive this decision.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Medical Wei]

But responsive design does not only matters for mobile, it also matters on
bigger screen, like high resolution or hi dpi screen, which is what Debian
lack of.  Like what I said the website is bizarre on a bigger screen. You
can try reading the website with the window maximized on 1920x1080 screen.

On Wed, 17 May 2017 at 22:02 Ian Jackson 
wrote:

>
> > It looks as though the Debian website (or at least its front page)
> > already has responsive design and the necessary runes to make mobile
> > browsers make use of it, although it could perhaps benefit from
> > dropping more content (requiring extra clicks instead) at small sizes.
>
> OK, good.
>
> I don't have any clear idea show close the views of the Debian project
> as whole are to the ones I expressed in my article, but I'm pretty
> sure that my views as expressed there are at least those of a
> significant and vocal minority :-).  They might even be the majority
> view, but we sowouldn't be able to tell without a GR - and let's not.
>
> Thanks,
> Ian.
>
>

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Holger Levsen]

On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote:
> In short:  There is no doubt that Git is the better VCS but spending
> developer time simply to switch lots of packages from an old VCS to a
> modern one has zero effect on users desktops and has no high priority.
 
I think that in the mid-term (probably even in short term) you'll *save*
developer time by switching to git, so that actually right now your choice
to not switch to git has an effect on users desktops: they get stuff later.

And also you're imposing a stupid tool to anyone who wants to help out or
do security fixes.

I'd be happy if Debian would enforce git for every source package now!

git clone https://src.fedoraproject.org/cgit/rpms/${srcpkg}.git is really
awesome and works for every package in Fedora! (*)

https://fedoraproject.org/wiki/Packaging:Guidelines says:


 Spec Maintenance and Canonicity

Fedora's git repository is the canonical location for Fedora spec files. 
Maintainers MUST expect that other maintainers and automated tooling will
make changes to their packages, potentially without communicating prior to
doing so (though communication is always encouraged). If some maintainers
are also attempting to keep copies of a spec in an outside repository, they
MUST be prepared to merge changes made to the spec in Fedora's repository,
and MUST NOT overwrite those changes with a copy from an external repository
or using fedpkg import. 



Debian aims to be the universal OS, but that doesn't mean we have to support
an universe of workflows and tools. Everybody should be using version 
control for their packages. Really. And probably we should all just use git.
And work together nicely.


-- 
cheers,
Holger

(*) even though I wonder why it's not even more simply 
git.fedoraproject.org/git/${srcpkg} ;)


signature.asc
Description: Digital signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Mattia Rizzolo]

On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote:
> In short:  There is no doubt that Git is the better VCS but spending
> developer time simply to switch lots of packages from an old VCS to a
> modern one has zero effect on users desktops and has no high priority.

I wonder...
The problem here is about fusionforge only, in fact.
If we were to move git (i.e. the vast majority of its usage) to another
place, and took down fusionforge (i.e. no more guest user management), I
do not think there is a reason to shut down the rest.
SVN could stay there, with viewvc and everything, and let packages and
project migrate whenever they need something not provided by old-alioth
(f.e. direct contribution from a non-DD that won't be possible without
fusionforge running to create its user and dealing with groups).


@tille: please have a look at pkg-haskell and their DHG_packages
repository.  I've never interacted with it, and I find it highly unusual
and non-standard that I doubt the usual tooling can deal with it, but it
might of ispiration about how to deal with R packages maybe?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Andreas Tille]

Hi,

On Mon, May 15, 2017 at 02:43:56PM +0200, Johannes Schauer wrote:
> 
> The top 10 teams with packages in SVN are:
> 
> 347 Debian Med Packaging Team 
> 

This number contains possibly 150 packages that *could* be migrated -
provided somebody wants to take the time for some unproductive work.
However, we intentionally do packaging of new R CRAN packages in SVN
since in this case packaging is brain dead simple and we keep only the
debian/ dir and not the upstream source in VCS.  This is a sensible and
established workflow and currently there is no short term plan to change
this.

In short:  There is no doubt that Git is the better VCS but spending
developer time simply to switch lots of packages from an old VCS to a
modern one has zero effect on users desktops and has no high priority.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Ian Jackson]

Simon McVittie writes ("Re: When do we update the homepage to a modern design? 
(was Re: Moving away from (unsupportable) FusionForge on Alioth)"):
> On Wed, 17 May 2017 at 13:33:06 +0100, Ian Jackson wrote:
> >  * Websites which reorganise themselves through CSS and/or JavScript
> >to try to produce a better selection of visibloe bits depending on
> >the screen size.
...
> The jargon term for this is *responsive design*. [...]

Thanks for the explanation.

> The problem, apart from smartphone screens just not being very big,
> is that mobile browsers and websites are engaged in a "do what
> I mean" loop where each side works around bugs in the other.

Gagh, world is so shit.  Fine, whatever.

> It looks as though the Debian website (or at least its front page)
> already has responsive design and the necessary runes to make mobile
> browsers make use of it, although it could perhaps benefit from
> dropping more content (requiring extra clicks instead) at small sizes.

OK, good.

I don't have any clear idea show close the views of the Debian project
as whole are to the ones I expressed in my article, but I'm pretty
sure that my views as expressed there are at least those of a
significant and vocal minority :-).  They might even be the majority
view, but we sowouldn't be able to tell without a GR - and let's not.

Thanks,
Ian.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Simon McVittie]

On Wed, 17 May 2017 at 13:33:06 +0100, Ian Jackson wrote:
>  * Websites which reorganise themselves through CSS and/or JavScript
>to try to produce a better selection of visibloe bits depending on
>the screen size.
> 
>I find these mildly annoying, but I don't use a smartphone and
>apparently smartphones are terrible at laying out ordinary web
>pages (because wtf?).

The jargon term for this is *responsive design*. It's essentially the
same principles as Web 1.0 best-practices - graceful degradation and
willingness to re-flow for arbitrary viewport widths - together with
some CSS magic to hide or shrink non-essential content, reduce margins,
or convert multi-column designs into a single-column stack when viewed
on a small screen.

The problem, apart from smartphone screens just not being very big,
is that mobile browsers and websites are engaged in a "do what
I mean" loop where each side works around bugs in the other.
If not told otherwise, mobile browsers assume that websites were
designed with the "requires Internet Explorer on 1024x768" mindset
and render the page at a width similar to a traditional desktop browser,
because if they didn't, badly designed websites would be unreadable
and so nobody would use that browser. As a result, if a website *is*
designed to scale gracefully to narrow widths, it has to announce
that in metadata so that mobile browsers will stop applying that
workaround.

It looks as though the Debian website (or at least its front page)
already has responsive design and the necessary runes to make mobile
browsers make use of it, although it could perhaps benefit from
dropping more content (requiring extra clicks instead) at small sizes.

S

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Ian Jackson]

Steffen Möller writes ("Re: When do we update the homepage to a modern design? 
(was Re: Moving away from (unsupportable) FusionForge on Alioth)"):
> And there is a confusion over "dynamic web sites" (maybe problematic)
> with "non-static content" (must have).

I don't know what these terms mean.  I see four kinds of ways in which
a website might be `dynamic' as opposted to `static':

 * Content which is updated fairly frequently and relates to recent
   events, such as news stories, blog posts, and testimonials.

   I have no objection to this kind of thing and I can see how it
   might make our website seem more exciting.

 * Websites which reorganise themselves through CSS and/or JavScript
   to try to produce a better selection of visibloe bits depending on
   the screen size.

   I find these mildly annoying, but I don't use a smartphone and
   apparently smartphones are terrible at laying out ordinary web
   pages (because wtf?).  I don't really object to this kind of
   approach so long as all features remain accessible (perhaps through
   extra clicks) even on small screens, and there is sensible fallback
   if JavaScript and/or CSS are not supported.

 * Websites with elements which, when you move the mouse, pop up
   menus, change shape or colour, etc. etc.  I find these intensely
   irritating.  Often they are buggy too.

 * Websites with elements which move even when you don't touch the
   computer.  This is an outrage - an outrage, I tell you!  That
   web browsers even honour this kind of thing by default is a
   travesty.  Rant rant rant.

Can some webby person please tell me the conventional names for these
four levels of dynamism ?

> We should vividly demonstrate on our home page that we are just that -
> alive and developing. If we could have users contribute success stories
> like "I switched my Granny from Windows to Debian and she likes it" or
> "We autoconfigure our HPC cluster in the cloud with Debian and Ansible,
> saving us 30 grand this year" then we have enough to get people hooked
> and invest to dig deeper into the site, I tend to think.

That sounds like it would be nice, but it shouldn't take away from the
navigation parts of our site.  We have a lot of information; the
problem I find is that it can be difficult to find.

Ian.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Steffen Möller]

On 16/05/2017 07:07, Mechtilde wrote:

> these two questions come into my mind: > > What does a "newcomer" expect from 
> such a website? > what do we
expect from a newcomer? >  > To go from user to dev is a gliding
way. > > "Want To Become Debian Developer" is the last step for a dev
not the > first one. IMO > > We should try to differ into the different
tasks for the user e.g: > > * Installation > * Configuration > *
Applications > * ... > * How can I help > * Structure of the Packages >
* Packaging > * ... > > +1

And there is a confusion over "dynamic web sites" (maybe problematic)
with "non-static content" (must have).

We should vividly demonstrate on our home page that we are just that -
alive and developing. If we could have users contribute success stories
like "I switched my Granny from Windows to Debian and she likes it" or
"We autoconfigure our HPC cluster in the cloud with Debian and Ansible,
saving us 30 grand this year" then we have enough to get people hooked
and invest to dig deeper into the site, I tend to think.

So, I see:
 * something along the lines of Mechthilde
 * dynamic user-provided feedback that we can annotate further with
references to HOWTOs etc for new users that want to share that
experience, i.e. a smaller Debian+Derivatives-centric stackoverflow kind
of thing that starts off with a success rather than with a problem

Steffen

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Gunnar Wolf]

Arturo Borrero Gonzalez dijo [Mon, May 15, 2017 at 01:42:09PM +0200]:
> Hi Paul,
> 
> I believe that what we are actually looking for is a bit of
> improvement in the marketing side.
> Modern and fancy things.
> 
> The LXDE example is good on that.

Is a good example on how to craft content-void websites that look well
on mobile devices but are useless for finding information.

I guess that if you click around enough, you will get to a decent web
site in it that actually contains information.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Sean Whitton]

Hello Boyuan,

On Tue, May 16, 2017 at 09:11:07PM +0800, Boyuan Yang wrote:
> I've got some different ideas. While it makes sense that packaging-only
> projects on the new VCS hosting system should not enable the issue tracking
> system (people should use Debian BTS instead. Pull Requests should be enabled
> to allow external contribution.), there are many semi-native and native 
> packaging projects directly related to Debian.
> 
> For example, there are documentation projects like debian-reference and 
> debian-handbook, native packages like dpkg, apt and reportbug. In that case, 
> the issue tracking *should* be enabled and used. Issue tracking here will act 
> as the replacement of mailing lists from lists.alioth.debian.org. (Issue 
> tracker acts just like mailling lists. The sole difference is that you must 
> start a thread on web interface.)
>
> My opinion is that the use of issue tracking systems should be decided by the 
> maintenance/packaging team (for team-maintained pkg) or the repository owner.

Firstly, as noted by Benjamin, disabling issue tracking does not mean
losing the merge/pull request workflow (which is what we really want out
of all this).  You do lose some integration between issues and
pull/merge requests, but that's minor.

I think that we should disable issue tracking across the Pagure
instance.  I disagree that it should be up to the package maintainers.
This is for two reasons.

(1) Please don't underestimate the confusion and inconvenience of having
two issue trackers for Debian.  This is not a migration: we will not
drop the Debian BTS because it is heavily customised for our needs --
even for native and pseudopackages, which you suggest replacing.  So we
should try really, really hard to avoid the situation where code
contributors have to look in two places.

I'm even more concerned for those who only report bugs and test fixes,
who might not know where to report.  If it is clear that pagure is for
code/doc contributors only, and those who only report bugs never need
look at pagure, we can minimise the frustration of our pure bug
reporters, who are an extremely valuable group of contributors.

(2) A web interface is much less accessible than our BTS.  We have
contributors on poor network connections, and we shouldn't force them to
use pagure's interface.  Perhaps it has GitHub-style e-mail support, but
in my experience you always end up having to access the web issue tracker.

-- 
Sean Whitton

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Antonio Terceiro]

On Tue, May 16, 2017 at 10:25:54AM +0800, Paul Wise wrote:
> On Tue, May 16, 2017 at 12:39 AM, Antonio Terceiro wrote:
> 
> > Right. IIRC that was said to me at Debconf16 about Debian-specific
> > services (such as ci.debian.net which was the context of my question).
> 
> Yeah, for codebases maintained by the service maintainer not having
> packages seems reasonable (but not for dependencies of that codebase)
> and that seems to be the current feeling within DSA.
> 
> Personally I'm leaning towards the feeling that all configuration,
> code and dependencies for Debian services should be packaged and
> subjected to the usual Debian QA activities but I acknowledge that the
> current archive setup (testing migration plus backporting etc) doesn't
> necessarily make this easy. The PPA/bikeshed mechanism might make it
> more feasible if that happens.

That makes sense.

I am currently working on a personal project that involves deployment to
my private server. I have Debian packaging for it, and I have a make
target that will take the most current code, apply the Debian packaging,
build a binary package, scp it to my server, and install it.  Whenever I
am ready to deploy a new version, doing it is just on command away.

An alternative to waiting for bikesheds and for waiting for the full
archive dance could be DSA providing a similar system for service
maintainers. They would upload one or more binary packages (alongside a
signed .changes, and maybe we also want the corresponding full source)
for their service. On the receiving end, the system would install those
binary packages after verifying signatures, and perhaps also a whitelist
of binary packages that the service maintainer in question can submit.


signature.asc
Description: PGP signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Boyuan Yang]

在 2017年5月16日星期二 +08 下午3:15:31，Mattia Rizzolo 写道：
> On Tue, May 16, 2017 at 09:11:07PM +0800, Boyuan Yang wrote:
> > For example, there are documentation projects like debian-reference and
> > debian-handbook, native packages like dpkg, apt and reportbug. In that
> > case, the issue tracking *should* be enabled and used. Issue tracking
> > here will act as the replacement of mailing lists from
> > lists.alioth.debian.org. (Issue tracker acts just like mailling lists.
> > The sole difference is that you must start a thread on web interface.)
> 
> Except that those projects are *expected* to use the official Debian BTS
> to track issues, and not any other bug tracker of their choice, nor a
> simple ML.

All right. If that is the case, disabling issue tracking / ticketing function 
is doable on the new VCS hosting platform. Pagure has separate global config 
switch on those functions. [1]

...but I believe we must enable the Pull Request system (if there's any). 
That's one of the killer features current Alioth is lacking. Sending patches 
onto Debian BTS or maillists is really painful and that prevents people from 
making contributions, especially for those not that familiar with Debian's 
development.

[1] https://docs.pagure.org/pagure/configuration.html#enable-tickets

--
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Mattia Rizzolo]

On Tue, May 16, 2017 at 09:11:07PM +0800, Boyuan Yang wrote:
> For example, there are documentation projects like debian-reference and 
> debian-handbook, native packages like dpkg, apt and reportbug. In that case, 
> the issue tracking *should* be enabled and used. Issue tracking here will act 
> as the replacement of mailing lists from lists.alioth.debian.org. (Issue 
> tracker acts just like mailling lists. The sole difference is that you must 
> start a thread on web interface.)

Except that those projects are *expected* to use the official Debian BTS
to track issues, and not any other bug tracker of their choice, nor a
simple ML.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Boyuan Yang]

在 2017年5月16日星期二 +08 下午2:51:16，Benjamin Drung 写道：
> Am Dienstag, den 16.05.2017, 13:47 +0530 schrieb Pirate Praveen:
> > On ചൊവ്വ 16 മെയ് 2017 05:20 രാവിലെ, Sean Whitton wrote:
> > > Thank you for updating us, Alex.
> > > 
> > > On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> > > > - Git Hosting - we want to give pagure [1] a try, which uses
> > > > gitolite, which is a
> > > >   nice git solution.
> > > 
> > > Ah, that's nice.
> > > 
> > > > Pagure also has issue tracking.
> > > 
> > > Is it possible to turn this off?
> > > 
> > > I think it would be bad if we ended up with some people filing
> > > issues on
> > > the BTS, and others filing them on Pagure.
> > 
> > I think issue tracking and merge/pull requests go together. The main
> > attraction of the github/gitlab/pagure workflow is merge/pull
> > requests.
> 
> No. They are not necessarily go together. For example, GitHub allows
> projects to disable issue tracking, but allow merge proposals. This is
> what I would expect for a VCS hosting for Debian.

I've got some different ideas. While it makes sense that packaging-only 
projects on the new VCS hosting system should not enable the issue tracking 
system (people should use Debian BTS instead. Pull Requests should be enabled 
to allow external contribution.), there are many semi-native and native 
packaging projects directly related to Debian.

For example, there are documentation projects like debian-reference and 
debian-handbook, native packages like dpkg, apt and reportbug. In that case, 
the issue tracking *should* be enabled and used. Issue tracking here will act 
as the replacement of mailing lists from lists.alioth.debian.org. (Issue 
tracker acts just like mailling lists. The sole difference is that you must 
start a thread on web interface.)

My opinion is that the use of issue tracking systems should be decided by the 
maintenance/packaging team (for team-maintained pkg) or the repository owner.

--
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Benjamin Drung]

Am Dienstag, den 16.05.2017, 13:47 +0530 schrieb Pirate Praveen:
> On ചൊവ്വ 16 മെയ് 2017 05:20 രാവിലെ, Sean Whitton wrote:
> > Thank you for updating us, Alex.
> > 
> > On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> > > - Git Hosting - we want to give pagure [1] a try, which uses
> > > gitolite, which is a
> > >   nice git solution.
> > 
> > Ah, that's nice.
> > 
> > > Pagure also has issue tracking.
> > 
> > Is it possible to turn this off?
> > 
> > I think it would be bad if we ended up with some people filing
> > issues on
> > the BTS, and others filing them on Pagure.
> > 
> 
> I think issue tracking and merge/pull requests go together. The main
> attraction of the github/gitlab/pagure workflow is merge/pull
> requests.

No. They are not necessarily go together. For example, GitHub allows
projects to disable issue tracking, but allow merge proposals. This is
what I would expect for a VCS hosting for Debian.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
Web: https://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Achim Weiss.


signature.asc
Description: This is a digitally signed message part

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Wookey]

On 2017-05-15 13:42 +0200, Hans wrote:

> Maybe other things, that people do not know yet, which show the power of 
> debian, should be mentioned (I think of biggest community, best documentation,

'Best documentation' is a strong claim that I don't think many would agree with 
:-)

Debian is many good things, but 'well documented', especially for
newcomers, is not one of them. Several other distros demonstrably do a
better job on this (Arch, Ubuntu spring to mind).

I will refrain from making further comments on the website except that
I like Debian's style much more than the lxde 'vertical sliding pane
minimal-info' thing that is quite popular these days. But then I am
old, favour substance over style, and don't use a tiny phone screen to
read the net. The more I see of the modern web, the more I become
convinced of the long-term advantages of 30K of HTML over 1MB of
javascript to convey essentially the same info.

I will observe that the debian wiki is a lot more up-to-date than the
website because it is much easier to update (much as I admire wml as
a tool/language).

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Zlatan Todoric]

On 05/16/2017 04:56 AM, lumin wrote:
>> I'll take any day a sort animations that explains things rather then
>> going through forest of information to figure out what is it, but I
>> guess these all are personal opinions.
> A tiny bit of animations should be enough for our homepage. The style
> of lxde.org does not fit Debian's style and I think the style of the
> old lxde homepage is a better fit at this point.

I didn't say we should become YouTube channel, I just pointed the
difference from one to another opinion regarding what is better for
easier understanding of particular things.

>
> Too much animation and loud web page elements are too fancy but
> actually somewhat annoying, and lack solemnity.
>
 I believe that what we are actually looking for is a bit of
 improvement in the marketing side.
 Modern and fancy things.

 The LXDE example is good on that.
>>> http://lxde.org/ seems to be the site in question. I agree with
>> Paul,
>>> I don't like it, and when I encounter pages in that style, I tend
>> to
>>> close the window.
>> Then lets forget about getting newcomers (fresh blood) to Debian as
>> you're so close minded to modern/new things - the same way they
>> probably
>> close the window when they see '90 style with a lot of text that
>> actually says nothing. We are strange with our talks last few
>> debconfs -
>> we want new people but we don't want to break our precious habits nor
>> do
>> we want to give freedom to others to express themselves if they don't
>> fit into our circle of thinking which must be the best one.
> LXDE is a desktop environment so it's fine to craft a fancy homepage
> to attract people. However that style does not fit Debian.

What is the style of Debian?

>
> Most of modern business websites are fancy. New bloods may like
> them.
> However if we craft a fancy page alike, they will forget
> it immediately
> after closing the window. And many of you don't
> like that to happen,
> aren't you?
>
> What exactly scares newbies away is the feeling of rigidness but
> not the solemnity and simplicity. We value our common value,
> we appreciate the hard work you've done via bugs.d.o and
> ftp-master and many others alike, but what a newbie can see
> about Debian is its face. I know that new users who value
> only "pretty face" are less likely to catch the common value
> of Debian, and people with love to this community can bear
> any "ugly face" of it.  No one dislike a proper and better design.

We don't want only users who will value what you value, nor users who
can contribute to Debian - we also should be perfectly capable to catch
average users like my grandma and not see her slip to Windows, Mac or
Debian derivative.

>
> IMHO there are two good examples, the Gentoo homepage and the kernel
> homepage https://www.kernel.org/ .(Remember the old kernel page?)
> These pages are pretty but not annoying. An ideal homepage for Debian
> should be 1. solemn and silent (as few loud elements/animations
> as possible) 2. informative (dense but not exhausting one's eyes)
> 3. well-designed (e.g. https://www.kernel.org/ is visually simple,
> but not too simple. Visitors sense a well-designed style.)
>
> On the other hand, I think the CD image link of Sid should be added
> to the Debian image download page, maybe with some tags say
> "for expert".
>
I don't agree with sid image (I don't think we even produce those) but
testing one should be fine (with short explanation how to upgrade to sid
if one wants or even add experimental branch - we have it, we could as
well show it more).

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Игорь Пашев]

2017-05-15 13:12 GMT+03:00 lumin :
> Especially look at the homepage of Gentoo


It's ugly, seriously.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Raphael Hertzog]

On Mon, 15 May 2017, Adrian Bunk wrote:
> The contents of the Gentoo homepage is similar to what Debian has but 
> presented with a different CSS - something like that would be a good 
> improvement.

I took a look at the Gentoo website and there's more than just better CSS.
I find it much better than the Debian one.

The things which are improvements compared to Debian:

- the frontpage is really only a (dynamic) portal to many other services,
  the main content does not duplicate what's already in the
  header/footer, they do not waste real estate uselessly

- every time that a somewhat lengthy explanation is needed, they direct
  users to their Handbook so that they do not duplicate instructions
  in multiple places

- they have more pictures and icons to illustrate and make it easier on the eyes

- their "get started" and "download" page are really visually appealing
  and very clear whereas our simple "bullet list" look like unstructured in
  comparison

- the two menu bars show clearly where you are within the website (in
  Debian we have no such visual indication), the headers/footers are
  easily identified compared to the main content
  
The only downside of Gentoo's website is the lack of translations.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Pirate Praveen]

On ചൊവ്വ 16 മെയ് 2017 05:20 രാവിലെ, Sean Whitton wrote:
> Thank you for updating us, Alex.
> 
> On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
>> - Git Hosting - we want to give pagure [1] a try, which uses gitolite, which 
>> is a
>>   nice git solution.
> 
> Ah, that's nice.
> 
>> Pagure also has issue tracking.
> 
> Is it possible to turn this off?
> 
> I think it would be bad if we ended up with some people filing issues on
> the BTS, and others filing them on Pagure.
> 

I think issue tracking and merge/pull requests go together. The main
attraction of the github/gitlab/pagure workflow is merge/pull requests.



signature.asc
Description: OpenPGP digital signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Stéphane Aulery]

Le 16/05/2017 03:47, Nicholas D Steeves a écrit :

On Tue, May 16, 2017 at 02:17:40AM +0200, Stéphane Aulery wrote:


Yes, Debian is a community like another, and a community is build
with shared principles. Design isn't principle, it is just a shameful
exploitation of the idea of beauty, serving a precise purpose which
is not a shared principle. Wanting to do the number is not and should
never be a goal of Debian.

Debian say claim to be "The universal operating system". It should not 
be

understood that it is used by everyone but that is generalist
and at the service of all.

Design and advertising are one and the same, manipulating the mind 
through
the image to obtain consent. We are stuck in this rotten atmosphere 
since

the interwar period.


Much longer than that!  See "beauty" "deception" "kalon" vs "kallos"
in Plato's writing.  While some people use beauty to lie and cheat and
bend both truth and understanding, this is not always the case.
Something that is beautiful can be admirable and true.

If Debian's structure is all of these things, then shouldn't also be
its artwork and design?  Even website design...  Isn't this the point
of the Fibonacci logo?


I did not want to talk about philosophers, it would have been 
pretentious.
But you understood the message. Yes, beautiful, truth and being are one 
thing.


I think that Debian does not especially need aesthetic beauty research 
because
it already has the accents of truth for it, and since it is one the same 
thing

it already has a little intrinsically.

Do we need to make a very beautiful site to bring people to us? No,
because Debian already has real principles that have attracted thousands 
of people.

Do we need to make a better site? Yes, because it goes together.

What I really want to say is that the original message calls for an 
aesthetic
among others that is the one of the moment, but that is not what we 
should aim
for as this kind of beauty does not fit the timeless beauty of the 
principles

of Debian since it is so quickly obsolete.

Regards,

--
Stéphane Aulery

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Jonathan Dowland]

On Mon, May 15, 2017 at 08:39:11AM +, Riku Voipio wrote:
> OTOH it might just not be worth to convert all project histories into
> git. Linus didn't do it for upstream kernel either. Convert the easy
> cases automatically and leave the rest ones for maintainers as an
> opportunity to do a clean start.
> 
> Else we risk delaying moving forward because time is spent supporting
> esoteric legacy workflows.

I agree completely. The ideal of converting all history has a chilling
effect on actually migrating at all; and in the meantime, there's a huge
opportunity cost IMHO, as we've had git for 10 years now there are plenty
of developers who have completely forgotten how to use SVN (like me) or
even never learned it at all.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Mechtilde]

Hello,

Am 15.05.2017 um 21:45 schrieb Zlatan Todoric:
> 
> 
> On 05/15/2017 02:02 PM, Lars Wirzenius wrote:
>> On Mon, May 15, 2017 at 01:42:09PM +0200, Arturo Borrero Gonzalez wrote:
>>> On 15 May 2017 at 13:30, Paul Wise  wrote:
 TBH if I was confronted with the new LXDE web design with CSS turned
 on, I would probably just close the page. The old page is way more
 informative and less heavy on the marketing.

>>> Hi Paul,
>>>
>>> I believe that what we are actually looking for is a bit of
>>> improvement in the marketing side.
>>> Modern and fancy things.
>>>
>>> The LXDE example is good on that.
>> http://lxde.org/ seems to be the site in question. I agree with Paul,
>> I don't like it, and when I encounter pages in that style, I tend to
>> close the window.
> 
> Then lets forget about getting newcomers (fresh blood) to Debian as
> you're so close minded to modern/new things - the same way they probably
> close the window when they see '90 style with a lot of text that
> actually says nothing. We are strange with our talks last few debconfs -
> we want new people but we don't want to break our precious habits nor do
> we want to give freedom to others to express themselves if they don't
> fit into our circle of thinking which must be the best one.

these two questions come into my mind:

What does a "newcomer" expect from such a website?
what do we expect from a newcomer?


>> * It's not nearly information-dense enough. www.debian.org is too
>>   dense, but the lxde one goes too far in the other direction.
>>   Something in between would be good.
>>
>> * It's hard for me to navigate or to find anything. It has a short
>>   one-sentence summary ("Desktop environment for all"), but nowhere on
>>   the front page does it mention that it works on Linux. That
>>   information is probably on some other page, linked from the front
>>   page, but finding that is someone else's job.
>>
> Well Debian on its page doesn't mention it is Linux based or has Linux
> kernel or at all word Linux. And short sentences are fine - no one is
> forcing you to learn all plane parts and how it works to just board it
> and come from point A to B. If we want users, you need to understand
> that they just want a nice looking and working OS, they don't want to be
> preached about it. For devs - we just need to have something like "Want
> To Become Debian Developer" and link it to some good doc.
> 

To go from user to dev is a gliding way.

"Want To Become Debian Developer" is the last step for a dev not the
first one. IMO

We should try to differ into the different tasks for the user e.g:

* Installation
* Configuration
* Applications
* ...
* How can I help
* Structure of the Packages
* Packaging
* ...

my 2 cents
-- 
Mechtilde Stehmann
## Apache OpenOffice.org
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## Key-ID 0x141AAD7F



signature.asc
Description: OpenPGP digital signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Gunnar Wolf]

Jonathan Dowland dijo [Mon, May 15, 2017 at 09:27:27AM +0100]:
> On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> > Nice to have:
> (snip)
> > - Mailinglists
> 
> I've always thought it a bit weird, unfortunate (and possibly a historical 
> accident)
> that we have lists.debian.org and lists.alioth.debian.org. Could this be an 
> opportunity
> to move to one Debian mailing list service?

Oh, but we also have them at lists.debconf.org! And they even use
different software. And there have been attempts at joining, but don't
succeed...

Re: Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[lumin]

> I'll take any day a sort animations that explains things rather then
> going through forest of information to figure out what is it, but I
> guess these all are personal opinions.

A tiny bit of animations should be enough for our homepage. The style
of lxde.org does not fit Debian's style and I think the style of the
old lxde homepage is a better fit at this point.

Too much animation and loud web page elements are too fancy but
actually somewhat annoying, and lack solemnity.

> >> I believe that what we are actually looking for is a bit of
> >> improvement in the marketing side.
> >> Modern and fancy things.
> >>
> >> The LXDE example is good on that.
> > http://lxde.org/ seems to be the site in question. I agree with
> Paul,
> > I don't like it, and when I encounter pages in that style, I tend
> to
> > close the window.
> 
> Then lets forget about getting newcomers (fresh blood) to Debian as
> you're so close minded to modern/new things - the same way they
> probably
> close the window when they see '90 style with a lot of text that
> actually says nothing. We are strange with our talks last few
> debconfs -
> we want new people but we don't want to break our precious habits nor
> do
> we want to give freedom to others to express themselves if they don't
> fit into our circle of thinking which must be the best one.

LXDE is a desktop environment so it's fine to craft a fancy homepage
to attract people. However that style does not fit Debian.

Most of modern business websites are fancy. New bloods may like
them.
However if we craft a fancy page alike, they will forget
it immediately
after closing the window. And many of you don't
like that to happen,
aren't you?

What exactly scares newbies away is the feeling of rigidness but
not the solemnity and simplicity. We value our common value,
we appreciate the hard work you've done via bugs.d.o and
ftp-master and many others alike, but what a newbie can see
about Debian is its face. I know that new users who value
only "pretty face" are less likely to catch the common value
of Debian, and people with love to this community can bear
any "ugly face" of it.  No one dislike a proper and better design.

IMHO there are two good examples, the Gentoo homepage and the kernel
homepage https://www.kernel.org/ .(Remember the old kernel page?)
These pages are pretty but not annoying. An ideal homepage for Debian
should be 1. solemn and silent (as few loud elements/animations
as possible) 2. informative (dense but not exhausting one's eyes)
3. well-designed (e.g. https://www.kernel.org/ is visually simple,
but not too simple. Visitors sense a well-designed style.)

On the other hand, I think the CD image link of Sid should be added
to the Debian image download page, maybe with some tags say
"for expert".

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Paul Wise]

On Tue, May 16, 2017 at 12:39 AM, Antonio Terceiro wrote:

> Right. IIRC that was said to me at Debconf16 about Debian-specific
> services (such as ci.debian.net which was the context of my question).

Yeah, for codebases maintained by the service maintainer not having
packages seems reasonable (but not for dependencies of that codebase)
and that seems to be the current feeling within DSA.

Personally I'm leaning towards the feeling that all configuration,
code and dependencies for Debian services should be packaged and
subjected to the usual Debian QA activities but I acknowledge that the
current archive setup (testing migration plus backporting etc) doesn't
necessarily make this easy. The PPA/bikeshed mechanism might make it
more feasible if that happens.

> It makes sense to prefer packages for something that has a proper
> upstream that is not us, which is the case in this discussion.

Right.

> In any case, it would be super useful to have this explicitly documented
> at the DSA website.

AFAICT, DSA doesn't have any hard rules/policy written down, just
evaluation on a case-by-case basis.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Medical Wei]

Let's begin with a sin of big screen users. Say, I am using 2560x1440
display, and the website is painful to view. Adding a max-width to the
container can help.

Secondly, I think the fonts can be larger and be less crowded (by
increasing line-height).

I think there are much more we can do even without changing the content.
On Tue, 16 May 2017 at 09:53 Nikolaus Rath  wrote:

> On May 15 2017, Adam Borowski  wrote:
> >> https://www.debian.org/
> >
> > Not that different from Gentoo's.  What's the problem you're seeing?
>
> I think this is one of the those situations where if you don't see it
> yourself right away, you'll just have to take other people's word for
> it. It may not be that different for you, but there's a big difference
> for at least some other people.
>
> Best,
> -Nikolaus
>
> --
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>  »Time flies like an arrow, fruit flies like a Banana.«
>
>

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Nikolaus Rath]

On May 15 2017, Adam Borowski  wrote:
>> https://www.debian.org/
>
> Not that different from Gentoo's.  What's the problem you're seeing?

I think this is one of the those situations where if you don't see it
yourself right away, you'll just have to take other people's word for
it. It may not be that different for you, but there's a big difference
for at least some other people.

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Nicholas D Steeves]

On Tue, May 16, 2017 at 02:17:40AM +0200, Stéphane Aulery wrote:
> 
> Yes, Debian is a community like another, and a community is build
> with shared principles. Design isn't principle, it is just a shameful
> exploitation of the idea of beauty, serving a precise purpose which
> is not a shared principle. Wanting to do the number is not and should
> never be a goal of Debian.
> 
> Debian say claim to be "The universal operating system". It should not be
> understood that it is used by everyone but that is generalist
> and at the service of all.
> 
> Design and advertising are one and the same, manipulating the mind through
> the image to obtain consent. We are stuck in this rotten atmosphere since
> the interwar period.

Much longer than that!  See "beauty" "deception" "kalon" vs "kallos"
in Plato's writing.  While some people use beauty to lie and cheat and
bend both truth and understanding, this is not always the case.
Something that is beautiful can be admirable and true.

If Debian's structure is all of these things, then shouldn't also be
its artwork and design?  Even website design...  Isn't this the point
of the Fibonacci logo?

⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄

Sincerely,
Nicholas


signature.asc
Description: Digital signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Zlatan Todoric]

Hi,


On 05/16/2017 01:48 AM, Sean Whitton wrote:
>
> More generally, while I agree that we should be flexible in the pursuit
> of new contributors and users, we mustn't lose our identity in that
> process.

Improving things doesn't mean destroying identity. We add and remove
archs, we added graphical installer, we don't configure graphics
manually anymore - did we loose identity? Social Contract and DFSG
ensure our identity imho.

>> Well Debian on its page doesn't mention it is Linux based or has Linux
>> kernel or at all word Linux.
> We have Linux, HURD and the FreeBSD kernel, though.  I suspect the
> thought was Debian hopes its practices, values and community will
> outlive any specific kernel, just like they could outlive apt/dpkg.
>
You could add the quote on which I quoted (lxde page doesn't say it can
be installable on linux) so my comment makes more sense and afaik, lxde
also can be installed on freebsd and hurd. I am there in hopes that
Debian will outlive all current things. :)

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Stéphane Aulery]

Le 16/05/2017 02:27, Ben Hutchings a écrit :

On Tue, 2017-05-16 at 02:17 +0200, Stéphane Aulery wrote:
[...]

Yes, Debian is a community like another, and a community is build
with shared principles. Design isn't principle, it is just a shameful
exploitation of the idea of beauty, serving a precise purpose which
is not a shared principle. Wanting to do the number is not and should
never be a goal of Debian.

Debian say claim to be "The universal operating system". It should 
not 

be
understood that it is used by everyone but that is generalist
and at the service of all.

Design and advertising are one and the same, manipulating the mind 
through
the image to obtain consent. We are stuck in this rotten atmosphere 
since
the interwar period.


Please tell me this is satire.  Because if this is serious, this is
seriously rude and dismissive toward everyone in Debian who thinks and
works at a higher level than hacking on code.

It's not all about the code.  Design matters.  So does creating a
community where all kinds of contributions are valued.


Debian is the second distribution without this beautiful design that
we are often asked. No ? I do not reject the work of those who
contribute anything other than code. I personally contribute mainly
translations. I only say that if we put a very beautiful facade
in the fashion of the day we will mainly attract people
who are superficial. That does not mean that things should not be 
improved,

but that it should be reasonable. Is it less hard?

--
Stéphane Aulery

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Ben Hutchings]

On Tue, 2017-05-16 at 02:17 +0200, Stéphane Aulery wrote:
[...]
> Yes, Debian is a community like another, and a community is build
> with shared principles. Design isn't principle, it is just a shameful
> exploitation of the idea of beauty, serving a precise purpose which
> is not a shared principle. Wanting to do the number is not and should
> never be a goal of Debian.
>
> Debian say claim to be "The universal operating system". It should not 
> be
> understood that it is used by everyone but that is generalist
> and at the service of all.
> 
> Design and advertising are one and the same, manipulating the mind 
> through
> the image to obtain consent. We are stuck in this rotten atmosphere 
> since
> the interwar period.

Please tell me this is satire.  Because if this is serious, this is
seriously rude and dismissive toward everyone in Debian who thinks and
works at a higher level than hacking on code.

It's not all about the code.  Design matters.  So does creating a
community where all kinds of contributions are valued.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
 - Carolyn
Scheppner



signature.asc
Description: This is a digitally signed message part

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Stéphane Aulery]

Le 16/05/2017 01:48, Sean Whitton a écrit :

Hello Zlatan,

On Mon, May 15, 2017 at 09:45:46PM +0200, Zlatan Todoric wrote:

Then lets forget about getting newcomers (fresh blood) to Debian as
you're so close minded to modern/new things - the same way they 
probably

close the window when they see '90 style with a lot of text that
actually says nothing. We are strange with our talks last few debconfs 
-
we want new people but we don't want to break our precious habits nor 
do

we want to give freedom to others to express themselves if they don't
fit into our circle of thinking which must be the best one.


I'm a relative newcomer, and I'm less than 30 years old, and one thing
that attracted me to Debian was the website's not being like lxde.org 
:)


More generally, while I agree that we should be flexible in the pursuit
of new contributors and users, we mustn't lose our identity in that
process.


Well Debian on its page doesn't mention it is Linux based or has Linux
kernel or at all word Linux.


We have Linux, HURD and the FreeBSD kernel, though.  I suspect the
thought was Debian hopes its practices, values and community will
outlive any specific kernel, just like they could outlive apt/dpkg.


Yes, Debian is a community like another, and a community is build
with shared principles. Design isn't principle, it is just a shameful
exploitation of the idea of beauty, serving a precise purpose which
is not a shared principle. Wanting to do the number is not and should
never be a goal of Debian.

Debian say claim to be "The universal operating system". It should not 
be

understood that it is used by everyone but that is generalist
and at the service of all.

Design and advertising are one and the same, manipulating the mind 
through
the image to obtain consent. We are stuck in this rotten atmosphere 
since

the interwar period.

--
Stéphane Aulery

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Sean Whitton]

Thank you for updating us, Alex.

On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> - Git Hosting - we want to give pagure [1] a try, which uses gitolite, which 
> is a
>   nice git solution.

Ah, that's nice.

> Pagure also has issue tracking.

Is it possible to turn this off?

I think it would be bad if we ended up with some people filing issues on
the BTS, and others filing them on Pagure.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Sean Whitton]

Hello Zlatan,

On Mon, May 15, 2017 at 09:45:46PM +0200, Zlatan Todoric wrote:
> Then lets forget about getting newcomers (fresh blood) to Debian as
> you're so close minded to modern/new things - the same way they probably
> close the window when they see '90 style with a lot of text that
> actually says nothing. We are strange with our talks last few debconfs -
> we want new people but we don't want to break our precious habits nor do
> we want to give freedom to others to express themselves if they don't
> fit into our circle of thinking which must be the best one.

I'm a relative newcomer, and I'm less than 30 years old, and one thing
that attracted me to Debian was the website's not being like lxde.org :)

More generally, while I agree that we should be flexible in the pursuit
of new contributors and users, we mustn't lose our identity in that
process.

> Well Debian on its page doesn't mention it is Linux based or has Linux
> kernel or at all word Linux.

We have Linux, HURD and the FreeBSD kernel, though.  I suspect the
thought was Debian hopes its practices, values and community will
outlive any specific kernel, just like they could outlive apt/dpkg.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Scott Leggett]

On 2017-05-15.15:02, Lars Wirzenius wrote:
> http://lxde.org/ seems to be the site in question. I agree with Paul,
> I don't like it, and when I encounter pages in that style, I tend to
> close the window.
>
> * It's not nearly information-dense enough. www.debian.org is too
>   dense, but the lxde one goes too far in the other direction.
>   Something in between would be good.
> 
> * It's hard for me to navigate or to find anything. It has a short
>   one-sentence summary ("Desktop environment for all"), but nowhere on
>   the front page does it mention that it works on Linux. That
>   information is probably on some other page, linked from the front
>   page, but finding that is someone else's job.

I agree completely.

If Debian gets a page like this, I think it should be at
brochure.debian.org, perhaps with a prominent link on www.debian.org.

Please lets keep the main page information dense.

-- 
Regards,
Scott.


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Zlatan Todoric]

On 05/15/2017 08:01 PM, Adam Borowski wrote:
> On Mon, May 15, 2017 at 10:12:26AM +, lumin wrote:
>> On Mon, 2017-05-15 at 11:19 +0200, Arturo Borrero Gonzalez wrote:
>>> Our users are really complaining about our look in the web and we
>>> should address it.
>> I'm looking forward to a new design of our homepage, but I'm not
>> able to help since not familiar to this field.
>>
>> Take a look at the homepages of major distros:
>> https://www.opensuse.org/
> Oh no!  Kill it!  Kill it with fire!  Quickly!
>
>> https://www.centos.org/
>> https://www.ubuntu.com/
>> https://getfedora.org/
> Also abysmal.
>
>> https://manjaro.org/
>> https://linuxmint.com/
> Not good either.
>
>> https://www.archlinux.org/
>> https://gentoo.org/
> These are ok.
>
>> Especially look at the homepage of Gentoo. Some of you must
>> remember the old gentoo homepage, but now gentoo has a way much
>> prettier face. Then look at ours
>>
>> https://www.debian.org/
> Not that different from Gentoo's.  What's the problem you're seeing?
>
>> We are the last major distro that move to systemd as the
>> default init system. And now we are the last major distro
>> that keeps an old design of homepage.
> The response here seems obvious, but I won't spell it out :p
>
>> Debian is a community that driven by volunteers. I believe
>> volunteers are working hard for community at the points
>> they are interested in. I guess, possibly there are too few
>> volunteers able/intend to update the design, so the homepage is
>> just kept as is.
> If it ain't broken... (speaking about layout, not the contents.
> Improvements to the latter are always worth some effort.).
>
>> If none of the volunteers is willing to contribute a new
>> design, what about spend some money to hire several worker
>> working on this.
> The current fad seems to be javascript-only blind-unfriendly
> elinks-unfriendly bandwidth-wasting monstrosities.  I'd really prefer
> a website written by a programmer over one made by a "designer".
>
> A good page is one that lets you find information quickly, not one that
> forces you to watch animations.
>
>
I'll take any day a sort animations that explains things rather then
going through forest of information to figure out what is it, but I
guess these all are personal opinions.