Re: non-free?
On Tue, 2014-03-25 at 15:29 +0900, Stefano Zacchiroli wrote: > Because as long as we document it, it's very hard to claim that > "non-free" is not part of Debian, when you could just add it as a > keyword side-by-side with "main" in your sources.list. The firmware have been moved from main to non-free a few years ago. The unintended consequences is that almost every system now use the non-free suite. Therefore users are more likely to install non-free packages. Aren't you afraid that we end-up with unintended consequences, where users become prone to add "foreign" repository... that eventually break their system (the dependency hell...)? Aren't you afraid that users become prone to add various repository... including closed-source/proprietary software? > The point is not dropping the current interface. The point is stop > teaching new users, generation after generation, that "non-free" is just > one word away from "main". > At least make it one domain away! :-) What's the workload on various teams and package maintainers for that fancy difference ? Is it really worth the time spent? Regards, Franklin -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395736346.4751.25.ca...@solid.klabs.be
Re: Question to all Candidates: we want more, aren't we?
Hello, [switching to debian-project] On Thu, 2010-04-01 at 09:57 +0200, Frank Lin PIAT wrote: > > Debian project raise it's expectation every year: higher quality, more > package, more architectures, more Desktops, etc... (cool). > > How do we face the challenge to do more every year? This first email introduce a series of emails, which aims to find some super-hyper-mega-brilliant[1] ideas to help the DPL. My first idea will focus on how people can help the DPL without stepping up for a whole year. The second email, will introduce an idea of how to make large/non-technical/boring projects happen. (well maybe) Do you have more 2¢ for the DPL? Franklin [1] I know, April first is over, it may not be so brilliant. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270243813.3612.1593.ca...@solid.paris.klabs.be
Question to all Candidates: we want more, aren't we?
Hello dear candidates, Debian project raise it's expectation every year: higher quality, more package, more architectures, more Desktops, etc... (cool). How do we face the challenge to do more every year? What would you do about it, as a DPL? Thanks to each one of you for being candidate. Franklin -- Hints: the obvious leverage are: productivity, quality and count(DD). -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270108658.3567.722.ca...@solid.paris.klabs.be
Re: Standardization, large scale changes, innovations
On Wed, 2010-03-31 at 18:13 -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
> > My father, for instance, often drives a screw into a piece of
> > wood with a chisel when he doesn't have a screwdriver around.
> > And I've also seen him chop off bits of wood with a
> > screwdriver, on occasion.
I like this example... If I were using a screw driver when I should use
a chisel, I would be rounding off the shaft of the screw driver, which
makes it unsuitable to screw at some point (and I am likely to hurt
myself too)
If I use a chisel to screw, I am spoiling the screw (and I am likely to
hurt myself too)
In both case:
1. I am shooting a bullet in my own feet, as I am making my futur
significantly tougher, just to a little bit lazy now.
(Also, this is really not nice if I am working with someone).
2. Not using the appropriate tool is amateurism. If you ever hire a
professional, which happens to do such thing, then just fire him off
before he makes a mess. (I am not suggesting to fire off any DD that
don't use dh ;-)
> > The same is true with Manoj. You may think debhelper is the best thing
> > [[[droping personal statements]]], but Manoj just disagrees. And as long
> > as Policy does not specify that debhelper is to be used, it's perfectly
> > within his right to not use it.
I think you just overlooked my previous email, especially the part about
industrializing.
http://en.wikipedia.org/wiki/Not_Invented_Here <-- replace "here" by ${me}
There isn't just Manoj that work on Manoj's packages (QA team, Security
team, Derivative distro... and our users!). BTW, does Manoj own those
package?. As I wrote those lines, I wonder if some developer don't
precisely use home made stuff to say "keep out, this is my own package".
A best practice isn't a standard (or a policy), still most people follow
it.
> > As long as the result is good -- a working, policy-compliant package
> -- how he gets that result is not your business.
Isn't Debian an organisation (with 1000+ developers)?
> > If you think otherwise, you should first get Policy changed, and then
> > complain to Manoj.
That's an easy move... (anyone who disagrees has to turn his proposal
into a policy!)
> Also, as a general rule of thumb, Policy should be about standardizing
> interfaces, not about standardizing tools. What matters from a Policy
> perspective is what ends up on the system, what ends up in the package,
> and how the packages interoperate for the end-user, not how you create
> them. So from that direction, I'm not sure it would ever make sense for
> Policy to require debhelper.
>
> To the extent that Policy already does this in a few places, I think it's
> a bug, since among other things it makes it much harder to figure out
> what's really going on and it makes it harder for subsequent tool authors.
I agree, the policy should not mandate a tool (because it would be
impossible to experiment *new* and *better* alternatives).
> If someone thought there was some much better design for how debhelper
> does things and wanted to start from scracth writing a new helper, they
> should be able to find documentation explaining what interfaces they need
> to satisfy, ideally.
debhelper has a standard interface quite documented in the manpages
(especially when using flat files as input). Anyone could provide an
alternative tool.
And this is a great feature. (anyone trying to do QA on the source will
agree).
> The major exception to this right now is that Policy assumes dpkg and the
> core dpkg tools
By standardizing more tools, we would be more efficient.
Those tools should be described by their interface, as you mentioned.
> (not the dpkg-dev tools necessarily) like dpkg-divert. I
> personally think this is a bug and I'd like to see the low-level
> documentation of the exact deb format, for instance, in Policy, but it's a
> very low priority compared to lots of other Policy work.
> Now of course if one orphans one's package or can't maintain it properly
> (lots of RC bugs, etc.), then I think redoing the packaging design is fair
> game once QA comes into play. Were Manoj to orphan a package, I suspect
> it's quite likely that whoever picked it up would convert it to debhelper,
> and that's fine. If I adopted a package maintained in bzr, one of the
> first things I'd do is convert the VCS repository to Git. But as long as
> the package is staying with its current maintainer and that maintainer is
> doing a good job, I think the obligation of that maintainer is to satisfy
> the interfaces, and what tools they use to do that is their business.
What about Debian users who need to modify a package for special needs?
What about peer review of the packages?
What about other teams in Debian? (nmu, porters...)
What about derivatives?
What about upstream review of his packages? (there isn't just patches).
Debian project raise it's expectation every year (cool). How do we face
the challenge to do more every year? (of course
Re: Standardization, large scale changes, innovations
On Wed, 2010-03-31 at 14:22 +0200, Josselin Mouette wrote: > Le mercredi 31 mars 2010 à 05:03 -0700, Manoj Srivastava a écrit : > > I just update code in one place, test it, and then run a script > > that does a git pull for all my packages. The next time I build the > > package, it will pull in the change. > > Which is what I already explained in other terms: > > Your packages are absolutely impossible to maintain by anyone > but yourself. I hear lots of people complaining that we lack ressource, but "everyone" seems to fight any effort to leverage the de-facto standard and best practices. Isn't the purpose of industrialization to spend less time in repetitive tasks and more time in innovative and useful tasks? Doesn't the Unix philosophy implies that I should reuse tools and code, rather than re-writing my's own? Usual question... I wonder if dpkg-dev would be accepted as a standard if it was invented nowadays? dpkg-dev was invented back in '94, do we have to stick it "as-is" or can we standardize and industrialize further? > > > This doesn’t raise questions about the competence of the newcomer. This > > > raises questions about the competence of the person who designed the > > > package. > > > > I am happy you have an opinion. I don't think much of it, but > > you are indeed entitled to it. > > I wouldn’t expect you to be able to question your own choices anyway. > > Actually, I shouldn’t be discussing this with you, this is pointless as > always. Let's go personal... Regards, Franklin -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270064936.3624.435.ca...@solid.paris.klabs.be
Re: planet.debian.org is RC buggy (?)
On Sat, 2010-03-27 at 17:56 +0100, Josselin Mouette wrote: > Le samedi 27 mars 2010 à 13:39 +0100, Frank Lin PIAT a écrit : > > DFSG / rc-buggy > > ¨¨¨ > > I consider blogs as non-free, proprietary material (a very few have a > > proper license, the "distribution" media s*cks anyway). > > > > Breaks DFSG #1: A document (HowTo...) published on planet can't be > > distributed in Debian main. Is this a problem? > > The content isn't archived. Is this a problem? a feature? > > An alternative solution would be to index the contents and make the > history searchable. I don’t think this requires any authorization if we > don’t store the archived posts themselves, only permanent links to them. Some valuable content vanish from homepages (same for people.d.o). > Overall, I’m curious to why you are asking such questions as part of the > DPL campaign. Do you feel the DPL should give have authority over what > services *.debian.org provides? This would be way out of the > Constitution. I believe that DPLs should promote collaboration. I personally believe that planet has many undesirable side effects, especially on collaboration behavior. Franklin PS. No, I don't actually want to shut-down planet ;) No, I am not expecting people to put their opinions under DFSG or PD May be some content could be moved to collaborative media, bts, etc May be some "I am doing something" post could be turned into a news May be that allowing comments should be a best practice May be I am not keeping-up with my own standards, so should shut-up! -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1269712661.3962.2680.ca...@solid.paris.klabs.be
Re: planet.debian.org is RC buggy (?)
Hi, Sorry if we are getting a little bit off-topic, feel free to follow up on debian-project (I would still be interested by the candidates PoV) On Sat, 2010-03-27 at 14:49 +0100, Nico Golde wrote: > Hey, > * Frank Lin PIAT [2010-03-27 13:44]: > > [I don't intend to start a flame war, but I do have venom for planets] > > > > planet.d.o has became one of the most visible media for Debian, if not > > the most visible one. Do you think it is a good thing? > [...] > On what are you basing this assumption? This is essentially based on my perception (people say "watch planet.d.o" rather than "watch debian-n...@lists.d.o"). As far as the News and Announce are concerned, the subscription are stalling: http://lists.debian.org/stats/debian-news.png http://lists.debian.org/stats/debian-announce.png (Planet was introduced in 2004) I know Ubuntu was introduced in 2004 too, but it isn't the reason for debian-news decline because debian-user never stopped growing: http://lists.debian.org/stats/debian-user.png You may consider that this one prove me wrong: http://lists.debian.org/stats/debian-devel-announce.png > While I agree that Debian isn't especially visible in any way media > wise I don't see the relevance of planet when it comes to our users. I > have no numbers to prove that but > I doubt that a lot of users are reading planet (why should they..). IT specialist and corporate consumers want to know what is going on for the next release. > As for the rest of your text I have to say (and I also do not intend to start > a flame): aren't there more important problems in Debian than our planet?! I asked precisely because it is a sign. You have a team when people speak as a team, not as individuals, IMHO. Franklin P.S. No I don't actually want to shut-down planet ;) and Yes, I prefer a planet blog rather than nothing. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1269702186.3962.1916.ca...@solid.paris.klabs.be
planet.debian.org is RC buggy (?)
Dear candidates, [I don't intend to start a flame war, but I do have venom for planets] planet.d.o has became one of the most visible media for Debian, if not the most visible one. Do you think it is a good thing? DFSG / rc-buggy ¨¨¨ I consider blogs as non-free, proprietary material (a very few have a proper license, the "distribution" media s*cks anyway). Breaks DFSG #1: A document (HowTo...) published on planet can't be distributed in Debian main. Is this a problem? Breaks DFSG #3: Derived work aren't allowed. In the few case where it is legally possible, it is difficult to merge and publish the updated version. Is this a problem? Breaks DFSG #2: No source for stuffs like charts and graphs (HTML is a valid source here). Is this a problem? Opacity ¨¨¨ Replying to a blog entry is very difficult. The replies and the original posted aren't available side-by-side. The comments aren't available on Debian planet (a kind of censorship). Actually, some blog even forbid comments! Is this a problem? The content isn't archived. Is this a problem? a feature? Community ¨ Do you think Debian Planet reflects the fact that Debian is a community where people collaborate? Do you think planet encourage collaboration? Do you think Debian Planet reflects the fact that Debian encourages to constitute teams? Do you think planet encourage that? Fame Do you see a shift in recognizing people for their communication skill (and/or committed time to communicate), rather that their actual work? What would you suggest and/or do? Sorry for that pretty long mail I wanted to make myself clear. Do not feel like you have to reply each and every question ;) Franklin P.S. Kudos for people behind "Debian News" (Ana Guerrero). -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1269693546.3962.1109.ca...@solid.paris.klabs.be
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Russell Coker wrote: > On Thu, 12 Nov 2009, Wouter Verhelst wrote: >> First, network protocols that "do not allow to display" anything are >> abundant, since no network protocol "displays" anything -- clients that >> use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot. > > If you connect to my SMTP server you will see a legal disclaimer (which I > claim to be as valid as any that you may see in a .sig). [..] > Now in terms of granting rights, if my mail server contained AGPL code > and this was displayed in the SMTP protocol then a user could connect > to it and discover whether I was using code for which they could demand > the source. I disagree with your interpretation. The AGPL states "prominently offer all users", displaying at protocol level doesn't comply with either "prominently" nor with "all users" (because only a few sysadmins will telnet to port 25.) Such offer should be on SMTP *and* on the website offering this service. (Would you consider it valid if the offer were included in HTTP headers?) /me don't like AGPL, especially due to the way linked/combined code is contaminated. I hate the way FSF made an exception for GPL-v3, and not for "any compatible license". That's proprietary sh*t. Regards, Franklin -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
