Re: Question to candidates: what are your quantitative diversity goals and metrics?
On 17183 March 1977, Salvo Tomaselli wrote: I am also the original author of packages, and since I am told that salsa is only for debian and upstream projects are not supposed to be there, for me it is easier to keep packaging and development on a single repository. Which of course can't be salsa. Whoever tells you that is *WRONG* You can, happily, host upstream projects on salsa too. Please do. The more, the better. The requirement is open source, so don't host things that wouldn't be able to get added to Debian... -- bye, Joerg
Re: On community and conflicts
On 16804 March 1977, Roberto C. Sánchez wrote: And yes, if someone manages to go that way with another conspiracy theory that directly affects people like this one did, I do believe the outcome will be the same. The ones you list above are on the comedy side of things. :) You, on the other hand, seem to take the position that DAM (or some other authority) gets to determine what "directly affects people" and then act in response to that determination. In effect, you seem to be advocating for the practice of "thought policing". Or do I misunderstand what your position is? I think you do. It was in response to the theories you selected. Clear nut cases where the ranting is tiresome to hear, possibly, but - for example - does not make people avoid scientifically proven methods for protecting themselves and others. Can we have a clear statement of what "directly affects people"? No. That way members of our community can have an opportunity to determine if what they are about to say/write might be considered problematic under that criterion? This seems to come from a point of view that any "wrong thing one may write leads to an exclusion". And that's just so wrong, that even trying to define something here is impossible - and also wrong. We (DAMs) said it many times during numbers of similar threads. We aren't a thought police, and we are (should be) the last instance things end up with. And if you look at such DAM actions of the past, you will find that DAM does not directly go and removes membership. We do try to work with people, not against. -- bye, Joerg
Re: On community and conflicts
On 16803 March 1977, Roberto C. Sánchez wrote: Yet, would someone posting about the earth being flat, the moon landings being faked, or aliens being kept in various secret government facilities around the world have been so swiftly removed from the project? Hardly swiftly. And not to a single event. The timeline in the DAM post he published lists it nicely, about 2 years and multiple warnings in. And yes, if someone manages to go that way with another conspiracy theory that directly affects people like this one did, I do believe the outcome will be the same. The ones you list above are on the comedy side of things. :) -- bye, Joerg
Re: Changing how we handle non-free firmware
On 16594 March 1977, Timo Lindfors wrote: 3) Ensure that the filename of the installation media includes "non-free-firmware" or something similar so that it is clear to everyone what they are getting into. Debian has had such a long history of not including non-free bits in the installation image that people will definitely be surprised if the filename does not reflect this change. Actually, people are surprised we are hiding the useful images (with firmware) somewhere in some subdirectory away currently. -- bye, Joerg
Re: Changing how we handle non-free firmware
On 16594 March 1977, Steve McIntyre wrote: = We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will *normally* be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will *also* be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software. We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages. = Seconded. -- bye, Joerg signature.asc Description: PGP signature
Re: General resolution: Condemn Russian invasion of the Ukraine
On 16454 March 1977, Joerg Jaspert wrote: While that war is idiotic and entirely stupid - what is the gain for Debian issuing such a statement? What is the goal here? Oh, and why now, not for all of those other wars and the misery coming out of them, all over the world, in the last years? -- bye, Joerg
Re: General resolution: Condemn Russian invasion of the Ukraine
On 16454 March 1977, Julian Andres Klode wrote: The Debian project strongly condemns the invasion of Ukraine by Russia. The Debian projects affirms that Ukrain is a souvereign nation which includes the Donbas regions of Luhansk, as well as Crimea, which has already been illegaly annexed by Russia. While that war is idiotic and entirely stupid - what is the gain for Debian issuing such a statement? What is the goal here? And does that mean we should from now on do one on every larger thing going on? How does that fit with what Debian actually is? -- bye, Joerg
Re: Renaming the FTP Masters
On 16314 March 1977, Thomas Goirand wrote:
Wrong wrong wrong ... we're "project members" ... don't you remember?
:)
Just like AH is now CT. (Gosh, DMT TLA...)
This shows that it will take years, if not decades, for the rename to
ever be effective (if the person(s) in charge decide(s) it...).
Well.
To rename just the team itself - minutes.
To be effective in terms of us mere humans using the new term, years to
decades.
To actually adjust all the resources around it ("sub"team names, unix
roles, host (aliases), mail, directory structures, database roles, BTS
pseudopackage, dput targets, all the code) may be faster, but a huge
work with lots of breakage possibilities, not all of which solveable as
simple as "then have the old name stay for a while as cname".
And that is just from our view of things and we aren't yet sure we are
complete on that. There are a trillion and two external dependencies on
many of the above that take extra work and ages on top of that.
--
bye, Joerg
Re: Renaming the FTP Masters
On 16308 March 1977, Jonathan Carter wrote: I would like to rename the FTP Masters team—ideally via a General Resolution. Ideally? Its the worst possible way to go about. I'm at a loss to actually find polite words to describe how off it is, That might be slightly harsh, Felix only became a DD last year, it takes some time to learn not to go for the biggest and bluntest hammer first. Only slightly, and nah, I am pretty sure that was a 100% calculated move to go directly to this. Also, changing the name is Step 1 only and if we leave it at that, quite pointless. Getting it all changed will take quite a while longer (start with hostnames for example). *nod*, although I don't see harm in starting with just a team name change. It doesn't have to mandate immediate changes everywhere else. The next step would probably be to file bugs for everywhere the name occurs with some tag and then track that, but I wouldn't want to force a surge of work because of this change. Starting with the delegation and then taking it one step at a time from there seems ok. Yeah. The current name is wrong for ages already, ftp is hardly in use for a long time, so thats a good reason to adjust it. If it happens to lose the "master" part in that, oh fine. And yeah, it will take *ages* and lots of small steps before it will be all through. -- bye, Joerg
Re: Renaming the FTP Masters
On 16306 March 1977, Felix Lechner wrote: I would like to rename the FTP Masters team—ideally via a General Resolution. Ideally? Its the worst possible way to go about. I'm at a loss to actually find polite words to describe how off it is, to do this via a GR. Without even ever asking the team what they think about a change. Not that I am against a change, and I can even see some of the reasoning behind it. I'm sure the team can find something entirely without an entirely needless GR. Also, changing the name is Step 1 only and if we leave it at that, quite pointless. Getting it all changed will take quite a while longer (start with hostnames for example). -- bye, Joerg
Expectation of constructive interaction
Dear fellow Debian community members, We have been having two weeks of difficult and heated discussion. The level of conflict has escalated out of proportion, both within the project and outside. We remind everyone that you are expected to interact constructively with our community. That goes not only for Debian Members, but also everybody who uses our mailing lists and other infrastructure. This is true especially at a time when some in our community have received threats and others are expecting them, just because they took part in discussions or voted as our constitution allows them to. This is entirely unacceptable. We remind you that if you repeatedly send messages which raise the level of conflict; if you often behave confrontationally towards people; if you tend to disregard cries for help or requests to take a step back: you are not meeting our community standards. We expect people not to justify themselves using the bad behaviour of others. As long as you use the unacceptable behaviour of others to justify your own unacceptable behaviour, you are not meeting our community standards. Consider this a general warning to everyone / all sides. Different opinions are normal, and we have ways to resolve conflicts. But some of the behaviour we have witnessed recently is not, ever, tolerable. Please think about the message you're about to send and whether it genuinely furthers discussion or simply antagonises others. For help, do reach out to your close circle of friends, and the Community Team. -- For the DAMs, Joerg Jaspert Enrico Zini Jonathan Wiltshire signature.asc Description: PGP signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On 16082 March 1977, Steve Langasek wrote: I accept an amendment to include the word "board" (which was missed on accident by me) and would ask the seconders to confirm their acceptance of this amendment so we can avoid any unnecessary extra variations on the GR ballot. Confirmed. -- bye, Joerg signature.asc Description: PGP signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
On 16082 March 1977, Sam Hartman wrote: I don't think we're going to get much benefit out of a prolonged discussion, and I think that there is significant benefit in acting quickly in this instance. So, I'd like to ask the DPL to consider shortening the discussion period. And for whatever it counts: Seconded. No need to have a longish thread about it, its either a yes or no for support of a given text. -- bye, Joerg signature.asc Description: PGP signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On 16082 March 1977, Steve Langasek wrote: Under 4.1.5 of the Constitution, the developers by way of GR are the body who has the power to issue nontechnical statements. https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md is a statement which I believe Debian as a project, and not just individual Debian developers, should consider signing on to. This is a proposal for Debian to sign on to the statement, by adopting the text from that open letter via GR. Seconded. Text of GR The Debian Project co-signs the statement regarding Richard Stallman's readmission to the FSF seen at https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md. The text of this statement is given below. Richard M. Stallman, frequently known as RMS, has been a dangerous force in the free software community for a long time. He has shown himself to be misogynist, ableist, and transphobic, among other serious accusations of impropriety. These sorts of beliefs have no place in the free software, digital rights, and tech communities. With his recent reinstatement to the Board of Directors of the Free Software Foundation, we call for the entire Board of the FSF to step down and for RMS to be removed from all leadership positions. We, the undersigned, believe in the necessity of digital autonomy and the powerful role user freedom plays in protecting our fundamental human rights. In order to realize the promise of everything software freedom makes possible, there must be radical change within the community. We believe in a present and a future where all technology empowers – not oppresses – people. We know that this is only possible in a world where technology is built to pay respect to our rights at its most foundational levels. While these ideas have been popularized in some form by Richard M. Stallman, he does not speak for us. We do not condone his actions and opinions. We do not acknowledge his leadership or the leadership of the Free Software Foundation as it stands today. There has been enough tolerance of RMS’s repugnant ideas and behavior. We cannot continue to let one person ruin the meaning of our work. Our communities have no space for people like Richard M. Stallman, and we will not continue suffering his behavior, giving him a leadership role, or otherwise holding him and his hurtful and dangerous ideology as acceptable. We are calling for the removal of the entire Board of the Free Software Foundation. These are people who have enabled and empowered RMS for years. They demonstrate this again by permitting him to rejoin the FSF Board. It is time for RMS to step back from the free software, tech ethics, digital rights, and tech communities, for he cannot provide the leadership we need. We are also calling for Richard M. Stallman to be removed from all leadership positions, including the GNU Project. We urge those in a position to do so to stop supporting the Free Software Foundation. Refuse to contribute to projects related to the FSF and RMS. Do not speak at or attend FSF events, or events that welcome RMS and his brand of intolerance. We ask for contributors to free software projects to take a stand against bigotry and hate within their projects. While doing these things, tell these communities and the FSF why. We have detailed several public incidents of RMS's behavior. Some of us have our own stories about RMS and our interactions with him, things that are not captured in email threads or on video. We hope you will read what has been shared and consider the harm that he has done to our community and others. End Text of GR -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- bye, Joerg signature.asc Description: PGP signature
Re: Should the project hire one or two persons to help the DPL?
On 16077 March 1977, Raphael Hertzog wrote: There are quite a few software projects that have hired staff to help smooth the internal working of organizations, I know at least of Django with its fellowship program: https://www.djangoproject.com/fundraising/#fellowship-program The current resources of Debian means that we can confidently hire at least one or two fellows that would work under the direction of the DPL and not be in troubles for many years. Leaving out the detail of Debian paying someone for work, this has one more thing that can backfire hard, as I just could witness in an (entirely unrelated) org: That those hired ones got more powerful than the actual leader. Simply by being there continuously, doing ground work, that the actual leader(s) over time didn't want to do. With time a big bunch of the work just got done, mostly leaving the radar of the leader then, and so they ended up controlling much, the leader being a figurehead in the end. There sure are ways to work against this, but for the first few leaders it was just comfortable, and then on and on the next ones got less interested in that particular work, and it all went down. And it appearently is quite hard to get back in control, even if you want to, if you have the whole admin setup working against you, as they want to keep what they have. -- bye, Joerg
Re: Some thoughts about Diversity and the CoC
On 15614 March 1977, Gerardo Ballabio wrote: Anyway, thank you for clarifying that using people's preferred pronouns is a requisite for being welcome in Debian. As I read them, neither the CoC nor the Diversity Statement are explicit on that. Maybe it would be useful to make it explicit? They state that we welcome everyone, no matter how they identify. They state that we are respectful. Anyone who is unable to transfer that to "Use however they want to be called" sure should rethink their involvement in Debian. -- bye, Joerg
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
On 15367 March 1977, Mathias Behrle wrote: *Usually* they do not do that during running elections, just short before they start, so you may be out of luck. If so then I think there is a clear gap in the procedures. That may be, though they are like this for a long time now. - What about DDs being approved just during the voting period? They should clearly be able to vote. It has always been avoided to add new DDs during voting period to avoid accusations of "rig a vote by letting the right people join at that moment". - What about DDs losing their right during the voting period? Should their ballots be valid? That also hasn't happened that I can remember. To cover cases like mine it would probably be good practice to update the keyring at least shortly before the end of the voting period. Of course I understand very well that the workload on the keyring maintainers should be kept at a reasonable size. I can see value in both ways, but I keep myself out of this. Not for me to say, I just reported on the current state as I know it. -- bye, Joerg
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
On 15367 March 1977, Mathias Behrle wrote: - originally set to 2019-04-07 - updated on 2019-04-08 to 2021-04-06 and pushed to various keyservers including keyring.debian.org. That was a bit late, but the right place to send to. Do I have to wait for a keyring sync of the DD Keyring? When will it happen? Do I have to get in touch with someone to get the key synced? Yes, same as for the archive and uploads. Updates send to keyring.d.o are not automagically included in the keyrings the debian infratructure uses. It needs a keyring maint to run some tool. *Usually* they do not do that during running elections, just short before they start, so you may be out of luck. -- bye, Joerg
End of campaigning
Hi three weeks of campaining, nearly over. Soon we have two weeks of voting. It was a nice time with a managable amount of mails. And one that certainly gave me new ideas and also incentive to get some of my thoughts around Debian clearer and more focused. Should I win, the extra time I gain from that will surely be used for good. Next two weeks please go vote. The more votes, the better for all of us. No matter who of us four will win, it will be a good year coming up, I'm sure. -- bye, Joerg
Re: Bikeshedding
On 15361 March 1977, Sean Whitton wrote: Yes. The amount of effort that we would need to expend on implementing zack's Statement seems out of proportion to the benefit, given that it mandates no particular git workflow. That's because you are all in way too deep in technical stuff. This is -vote, not -devel. Actually hashing out how it will work and look isn't what these threads here are (should be) about. dgit may even be (part of) the answer when one goes down to the technical work and specs. It may also not be but something new that may be based on concepts of it. Or not. I don't think that can, or should, be defined here and now. -- bye, Joerg
Re: Q to all candidates: what is the long-term role of traditional Linux distributions?
On 15361 March 1977, Matthew Garrett wrote: But upstream development is increasingly diverging from our approach. I think that depends a bit in which area you look. Many new software ecosystems are based on external code repositories rather than relying on the distribution, and in several languages it's expected that a project directly include its dependencies rather than relying on external availability. But those software ecosystems also need a stable base that works and allows them to ignore those mundane basics. Given these upstream shifts, is attempting to package as much software as possible something that actually benefits Debian and our users, or is it something that brings us a duplication of effort? We don't need every single possible bit of software packaged. That's neither a useful nor an attainable goal. We need as much groundwork packaged that you can use any of the existing and new coming stuff in an easy, yet still secure, way. And that you can do it on an otherwise stable platform. Which is something Debian does provide pretty nicely (ok, except for releasing way too often and fast, which is a major downside of us). If we spent time on building tooling to automatically identify that (say) installed Go applications that contain dependencies with security vulnerabilities and alert users, would that be time better spent than independendly packaging and maintaining those dependencies ourselves? It may be. As I wrote elsewhere I imagine a Debian that has a Magic Archive (Hey, I got a free magic card there) and is *THE* answer to everything package related, so that anyone in any language environment (nodejs? ruby? python? perl? java? haskell? whatever) who ever goes "And now, how do my users get the crap I wrote?" goes "OH, sure, Debian, I just fill out this $somethingseomething and any user anywhere can *easily* get at it, perfectly integrated in their system with all dependencies magically resolved". Lucky, for me, even with the magic card, I have been vague enough that it fits even here. I do want Debian to be the platform chosen to build other stuff upon. In whichever environment the people building are. Go, Ruby, NodeJS, whatever. A startup that scales up tons of containers and throws them away even faster than their humans. A big business that thinks a new released Linux Distribution every 10 years is the best. Someting in between that can deal with 5 years. Users at home that have featuritis and can't wait for the next tiny dot version to finally install. Now, packaging it all is an effort we really can't sustain. And it really doesn't make sense to have packages where the metadata is larger than the code. So yes, better tooling will be part of the answer. Our advantage, and something that we should try to keep and extend on is our unification and consistency. Say, I want a perl module Foo::Bar, I get it with one command and a predictable name and location and general behaviour. Want a golang something module (just assume its packaged), I get it with the same command and a predictable name. And so on.[1] Are our current priorities the best way to serve the free software community over the next 10 years? No idea how the world will look in 10 years, but if we keep the users as part of our priority, and adapt according to their needs, we shouldn't be far off. And yeah, now someone asks to define users, especially with what I wrote some lines up. Would we be better off focusing Debian as a high-quality base for users who then largely consume software from other sources? I think we should not have just one focus and concentrate on that alone. We should have multiple and continue to try to weight them against each other as good as possible. Footnotes: [1] Sure, right now this requires the "needs to be packaged" part. -- bye, Joerg
Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL
On 15361 March 1977, Chris Lamb wrote: So, in general, I fear that the candidates may be over-estimating how much of the DPL's tasks can be delegated to teams or other individuals. [...] So, reading this back I am not entirely sure what I'm asking here but I would be interested if our candidates had any thoughts about this. Umm, lets make it short, for a change: Should there be something often enough that one can consider delegating it *and* there be volunteers for the work and it is something one can delegate, I am certainly up for delegating it. But I don't bet on being able to do that and am prepared to do the work that comes my way... -- bye, Joerg
Re: Q: Do you believe in Supercow?
On 15360 March 1977, David Kalnischkies wrote:
Old codebases usually do not attract many new people.
Well, yes, but what is that supposed to mean?
Not much more than something you probably already knew.
APT had at least one (serious) sort of rewrite (cupt) which isn't
exactly overrun either desperate it being many years younger.
I do remember cupt, yeah. Never really used it.
Debian itself is pretty old and we are talking constantly about how to
attract new blood beside keeping the current happy. Taking your response
at face value means that this is pointless. Makes me wonder why we talk
about BTS, git-debian-archive or whatever through.
Debian is not one codebase. A big collection of many different ones.
And something not being easy is no reason to keep trying. Not many new
people still means some.
And if we despair because it is hard, well, that won't make it better.
"Renewing" our toolstack and making it easy (easier) to contribute in
the small and the big ought to get more pople involved. And may overcome
the "its old, I want something new and fresh, I get more satisfaction
out of that" stigma. And some of those new ones are bound to dig into
the "hard" cases.
Also, ok, to give you another reason why not many people may step up
to do more on things like apt or dak:
They are both kind of high profile and in the middle of everything.
Break em and you break half the world.
That is scary. That gets you lots of attention. Not always from the most
friendly sort.
> Or better yet, an idea on how to change that?
if you find out how, tell me what you did, so I can repeat it for dak.
What has seemed to have worked in the past is that the entire team left
and out of the dark emerged a new team to salvage the pieces. Seems to
have happened a few times in apt. I have seen it happening in
aptitude.
Not sure if that is to be emulated and from the "outside" it seems like
a waste of resources – beside being a high stacks gamble.
Yah, thats not something to recommend.
As you are asking about dak specifically, based on my experience in the
past (but that is some years ago) it was way too hard to get a local
test instance up and running. I think/hope that changed, I would like to
revisit the {Contents,Packages,…}-all thing eventually.
Well, I am sure we aren't the easiest to setup, but hey, we do have some
gitlab ci run on our dak, and that stuff includes setting things up all
the time. And our setup docs also got much better.
> 2. There are glimmers of dissatisfaction hidden between "bikesheds",
> "curl|sudo bash" and mentions of heretic tools like npm/yarn/cargo/….
> Given a timemachine, infinite funds and unquestioned management powers,
> what would you have made APT developers do one/two/five/ten/twenty years
> ago to make you happy now?
Whats it this year with people handing out lots of magic? Is that a new
trend I missed?
A certain DPL candidate has in his platform: "We should look why people
chose something different than Debian. And see if we can enhance Debian
to provide the features, while balancing it with our current users."
Can't think of who that git has been. Still, that is based in reality,
not in magic with infinite funds, suddenly all developers agreeing to
whatever i want and even doing the work for me. I mean, that's sure a
dream, but I am not that much gone to expect such a thing :)
I am not deep enough in the apt mud to tell you what would need to have
gone different whatever time ago to make us more happy now.
Most people aren't experts in climate change but still have an idea what
could be done (if it will work or is sensible is a technical detail).
I have an idea what can be done in climate change because I get told all
the time what needs to be done if I happen to look outside Debian lists.
I am not getting told a lot of what can be done in apt all the time.
"curl|sudo bash" is even a quote from your platform, so you surely have
some opinion, broad vision or whatever. The "magic" setup is just there
to prevent you from dropping an item from the list just because it seems
too hard, out of scope, out of fear it might be silly and so on.
Well, yes. I do have opinions. But those are of the general sort and
seen from the admin user side.
That is, I like the security "theater" a package manager adds around
stuff that gets installed. In our case, with the gpg dances from the
maintainer and the archive. Which is entirely missing in the curl|sudo
bash case.
I also like the "Simple to get rid of the installed stuff"
again, somehow missing too in curl|sudo bash.
I sure also like the uniformity coming out of such a package manager.
"apt install foo" and I know what will happen, in which order, and know
where I can "jump" in if something goes wrong.
Or, to not just jump on the curl users, all that is missing in many
"managers".
So I sure know what I like. But that is a far, far different thing from
knowing what actually needs to go into such a package manager.
Re: Q: Do you believe in Supercow?
On 15359 March 1977, David Kalnischkies wrote: Mindless sweet talk might be boring through, so let me get some (wordy) questions you can dwell on as much as you like (to improve stats[2]): You know, if thats just some 1st april joke, its a bad one. But there is some stuff in that can actually be taken serious, so lets go. 1. I said you all mostly qualify as minor contributors, but that is based mostly on contributing in bugreports more than a decade ago. You are in good company through: I am the newbie in the fellowship of the cow even through I am only a few weeks away from my 10 year anniversary! Do you have any opinion on why it might be that way? Old codebases usually do not attract many new people. Or better yet, an idea on how to change that? if you find out how, tell me what you did, so I can repeat it for dak. 2. There are glimmers of dissatisfaction hidden between "bikesheds", "curl|sudo bash" and mentions of heretic tools like npm/yarn/cargo/…. Given a timemachine, infinite funds and unquestioned management powers, what would you have made APT developers do one/two/five/ten/twenty years ago to make you happy now? Whats it this year with people handing out lots of magic? Is that a new trend I missed? I am not deep enough in the apt mud to tell you what would need to have gone different whatever time ago to make us more happy now. 4. There is always the lingering question if Debian might become more or less important in the future, but asking you that seems unfair as most of you will not have a crystal ball. So my more realistic and totally technically objective question is: Do you believe APT will be more or less important (within Debian) in the future? I've not seen a real replacement proposed, so it will at least stay what it is. If it gets more or less depends on what you apt people do with it. -- bye, Joerg
Re: Bikeshedding
On 15360 March 1977, Jonas Meurer wrote: Gitlab subgroups would solve this problem: Move every Debian package into the 'debian' group, but allow subgroups in there: Not in the current way they work, no. Though there is a gitlab upstream bug about it. -- bye, Joerg
Re: Q: top three things you would like to change if that was easy?
On 15359 March 1977, Lucas Nussbaum wrote:
However, I wonder why you picked this ("maintained on salsa + upload
rights for all DD") as the first step towards increasing uniformity
(thus I assume that you see this as the most important thing to fix).
In practice, we already have a version control system with full access
to all DDs: the Debian archive (and snapshot.d.o for history). And it's
not that bad.
The Debian archive and snapshot are a *really* *bad* VCS. The archive is
really good in getting a consistent set of files/packages to the users
machines (also there are sure ways to improve there too), and snapshot
is really good in showing the history of that.
But both are *really* bad and ugly to work with for developing things.
Where you want to easily look over history and their logs. See what
changed, by who, when, ...
Yes, sure, can do all that in the archive (and snapshot). Can also just
cut off my leg, I think thats less painful.
git log. git show. git branch. All way better for actual work.
Same as git is *not* good at getting packages to the users.
If we were to move to something else, maybe it would be better to
switch to a single big repository (like the Debian Haskell team does
for their packages[1]).
That would be the debian group. Its a step forward, yes, but I think it
isn't really what a distribution the size of Debian can handle. The
access rights when you look just over "all DDs can" are getting tricky
already.
Let's imagine for a moment that you have three "full consensus +
peoplepower" magic cards.
Only 3? Booh.
So, what are the important things that you will fix or create within
Debian with those three magic cards? Why? How? Feel free to start with
a disclaimer such as:
Ok, so:
I don't think that this should ever be done in Debian without a proper
project-wide discussion first. But since you are asking, here is what I
would like to see changed in Debian, and how.
1) Magic Archive / Packaging rework.
Now, thats all, from the developer side to the user facing one. The way
how we work, the way dak works (and it sure ends up bug free, of course,
this is magic after all), and how it gets to the user.
It will also have *THE* answer to everything package related, so that
anyone in any language environment (nodejs? ruby? python? perl? java?
haskell? whatever) who ever goes "And now, how do my users get the crap
I wrote?" goes "OH, sure, Debian, I just fill out this
$somethingseomething and any user anywhere can *easily* get at it,
perfectly integrated in their system with all dependencies magicall
resolved".
2) A reworked BTS
-
I am sure the people behind our BTS are sick of hearing how bad it is,
so: I like it. But I still would have it magically enhanced. Our BTS
does work, but it is slow to react to mails (and update the web), it
feels archaic.
I would like one that still has the nice features ours offer with all
the mail handling, as thats great. But also a nice responsive web ui
that allows the same (or more), by easily clicking stuff together.
Also with a nice API so it can be easily used by tools elsewhere.
3) Diversity
Sorry, its magic, so this one is not technical. You still have to follow
me, peoplepower and full consensus and stuff. :)
I want equal amount of anyone and anywhere present and active in Debian.
I also want them equally present in the various (core) teams.
--
bye, Joerg
Re: Q to all candidates: mutual communcation and decision-making tools
On 15359 March 1977, Jonas Meurer wrote: Do you have concrete plans to improve the mutual/two-way communication between the DPL and the rest of the project? Monthly bits from the DPL are already helpful, but they're mostly a one-way communication so far. I don't mean private communication between the DPL and particular teams/developers, but public discussion. I do not have concrete plans in that direction, no. But I am on IRC a lot, everyone can start (public too) a discussion there... I am also in #debian-dpl, a channel that was used long ago (Zack DPL times). Can imagine having that used more again. Same goes for #debian-meeting. One idea that came into my mind lately: we could do regular polls about I personally don't like random polls much. Those I know usually only get answered by a very small subset of people, so you are back at what you have already, just with a different tech below. Few people giving input, except now the few are splitted over one more medium. the most pressing problems/projects/changes among all project members (after they got raised and discussed on the mailinglists) and the DPL could delegate temporary teams to solve/implement the ones that got the most votes. (I really like the idea of temporary task forces or "fixer teams" that Jonathan Carter brought up in msgid:51b4d63d-1af1-e0ca-6621-a131b7ec3...@debian.org[1].) Yep, that idea has merit. -- bye, Joerg
Re: Q to all candidates: should we have more ports?
On 15359 March 1977, Wouter Verhelst wrote: Should we try to catch up with these other systems in terms of ports? Specifically today, should we try to make Debian usable on any of the operating system kernels that I quoted above? While it is nice to have many ports, "We have the most" is not the best way to measure success, I think. Now, I do not think that the DPL should go round and get more ports ready for inclusion. But if there are people who want to do the work, then neither the DPL nor a delegate should be in the way in general. (There might be technical reasons, and some ports may have general questions in terms of freeness). -- bye, Joerg
Re: Bikeshedding
On 15359 March 1977, Russ Allbery wrote: I agree with what you are saying here. However, I am concerned that the "push == automatic package upload" idea may be a step too far in some cases. I assume this would only happen if you push a signed tag. I wouldn't want every random commit I push to immediately be uploaded. Oh yeah, definitely something with a signature need to be there for an upload, in whichever way that upload happens. But thats one of the technicalities that needs to be defined. For example, for ftp-masters dak we have an own branch, deploy. That one goes, driven by a cronscript, to all machines we run dak on. But only if its signed by a key in a pre-defined list. And if the old deployed stuff is an ancestor of the new one. So usual work happens in master (or any feature branch, but then merged to master). And if one of us is happy, we do a signed merge commit over to deploy. Some minutes later its deployed. -- bye, Joerg
Re: Bikeshedding
On 15358 March 1977, Stefano Zacchiroli wrote: I'm not fundamentally against that being a "must", but we should just be aware that there might be some use cases that we'll end up sacrificing in order to make such a unification of source control hosting possible. I agree with your analysis here: there is a clear trade-off between flexibility in package maintenance practices and uniformity. Yes. I know well where I'm placed on that trade-off: I'd take uniformity every day. I'm convinced Debian's inability to impose one way of maintaining packages is holding us back in our ability to implement (by the means of semi-automation) archive-wide changes and is also setting the bug for newcomers unreasonably high. I have been on the side of "we are fine, you need to learn stuff, go and do it". I am still on that, but much moving to "It ought to be enough to learn one way and style, not a trillion different little ones". This is scary in many ways, starting with "Oh gosh, 1k other people have access to MY packages?" and "Uh what, I am able to modify all them other 30k packages, why do you trust me with that" and is entirely different to what we do now (mostly, collab maint exists, I know). What I'm trying to determine with this sub-thread is which candidates, if any, are willing to take a courageous stance on this matter and, if so, how will they go about it. For now, I'm understanding that you're more inclined than Ganneff to take steps to uniform package maintenance practices, but at the same time you want to retain some uniformity. So I'm still at loss at what *concrete steps* you will take to increase uniformity throughout the archive. I know I've not given exact steps on how to go. Discussion, possible GR. That is vague, I understand. It is too broad a thing to nicely formulate something now and stick with it. But I wouldn't say I am not prepared to take steps to uniform stuff. Though I can list some actionable items, if that makes it feel more real. First off it needs to get discussed at a proper venue, -devel or -project, not -vote. It also needs to have talks with DSA and salsa maintainers, as it will mean a noticable load increase for that service which may mean a change of the way it is setup (split over machines). If that all works out positively, it needs -policy involved, as that document needs to have paragraphs talking about it. And then it will end up a GR, presenting the worked out solution and policy change to the developers and let them decide for or against it. And working that out will take time. While its simple to state "It all must be there", there are various exception to the rule to be considered, as usual. And get into it... -- bye, Joerg
Re: Bikeshedding
On 15358 March 1977, Stefano Zacchiroli wrote: > Statement: every Debian package must be maintained in Git on salsa and > every Debian Developer with upload rights to the archive should have > commit/push right to every packaging repository on salsa. Well, you took it from one of my mails, so it is mostly what I said, so yeah. Concepts like LowThresholdNMU are nice, but the wrong way around. The big difference is the "must": I'm suggesting that no package should be in the archive if it isn't Git-maintained on salsa in a repo writable by all DDs. So, let me insist: do you agree with that (specific version of the) statement or not? Yes. I think the DPL can (try to) start and steer discussions the right way. In the end something that drastic will need a project decision on it, either by everyone just doing it (highly unlikely given our project) or a GR. I'm sorry, but there are so many hypothethicals here that I still have no idea of what you, as a DPL, will do to make us closer to the net goal. Will you start a discussion on this or not? Will you start a GR on this or not? More than what we have at -vote just now, I will start a discussion on -devel, yes. GR or not depends on the way that discussion will run. It may show more hurdles than I currently can think of and turn out to make no sense now to run a GR on it. OTOH it can show lots of support and mostly small issues that are simple to solve, then a GR is good to have and I will start one. -- bye, Joerg
Re: Bikeshedding
On 15358 March 1977, Stefano Zacchiroli wrote: And less "I'm the package maintainer, this is my castle, go away" and more "This is how the majority does it, you follow, the benefit of it being one way, not a dozen different, outweight some personal preferences". Let's cut to the chase of this. Statement: every Debian package must be maintained in Git on salsa and every Debian Developer with upload rights to the archive should have commit/push right to every packaging repository on salsa. DPL candidates: do you agree with this statement? Well, you took it from one of my mails, so it is mostly what I said, so yeah. Concepts like LowThresholdNMU are nice, but the wrong way around. If so, what will be your approach to make this a reality? I think the DPL can (try to) start and steer discussions the right way. In the end something that drastic will need a project decision on it, either by everyone just doing it (highly unlikely given our project) or a GR. It's also possible that something this big needs more resources thrown at (like scaling salsa or the ci around it), in that a DPL can obviously use the assets available in the best possible way. Be that with sprints, throwing hardware at it, whatever. -- bye, Joerg
Re: Bikeshedding
On 15356 March 1977, Anthony Towns wrote: Did anything happen to that? (Or perhaps, that's better phrased as: did anything cause it to stall other than ENOTIME?) I'm guessing not? [1] ENOTIME. And ENOONEELSEINTERESTEDINCODING. Unless the things that caused it to stall were legal concerns or a need for separated hosting/mirror infrastructure, that might not be something the DPL can make much better. Perhaps if Joerg quits DAM due to being DPL and ftpmaster due to having to re-delegate it, the combination of those might leave him with more time for dak development despite also being DPL? Thats an interesting take on it. As a result, I kind of disagree with Joerg's statement in his platform that "As the DPL is not the lead of actual technical development, it is not for the DPL to find technical solutions for the challenges we face" -- I think spending time making a huge technical improvement for the project, like bikesheds, would be the best way to demonstrate leadership (whether done by the DPL or not), and honestly I'd be more impressed seeing a DPL do that compared to a DPL spending a year's time focussed on mediating disputes and PR. Obviously, YMMV. I stay with my statement. The DPL is not the lead of actual technical development. But that does not exclude a DPL from being the lead of actual technical development - by the virtue of the person thats DPL at the time also being in a team where that development happens. Maybe obscure, but I think of that as two hats. * Debian is made up of a lot of policies, and rules; and often has a lot of arguments and hurt feelings. Debian's also made up of a lot of genius (and admittedly not so genius) code and technical achievements. Usually, DPLs seem to spend all their time dealing with policies and conflicts, rather than technical stuff. Do you think it makes sense to put some real effort in moving the balance the other way? If so, how? I think we do have a good amount of policies and sometimes too much of a fear to just go and break one if its sensible. Also, everyone likes to define sensible different. And yeah, we discuss things to death way too often. Unsure how to get that pendulum moving into the other direction, and for how far. * Do you think bikesheds are actually a bad idea, or know of any other particular roadblocks in the way of making bikesheds happen? If Joerg is too busy to do it, do you have any ideas on how others could make it happen (within Debian, not as a derivative of some sort)? If elected, would you help remove those roadblocks? I think they are a pretty nice one and would still love to see them. Others: The hard way, join the ftp team, work your way up until you have the powers to just go and do em. Takes years. Better: First off it needs code finished. There is a branch, bikeshed, I just pushed it to salsa. That does need to get a recent master $magiced (merge, rebase, whatever) in, then cleaned up and finished off. Anyone who understands python can start working on that. A bit of understanding the archive will help, sure, but first off, its python code. That will take a while before it does need an ftpmaster. Any of us, though I am happy to be the contact and think Ansgar won't run away screaming either. * As far as technical projects go, is there anything you think would have more of an impact than having bikesheds available to every DD? (Or, if you think bikesheds are a bad idea, what's the biggest positive impact technical project, in your opinion?) Salsa as the one and only platform of hosting our packaging, with only ONE way of doing so in git, not half a dozen, followed by "git push == upload" I mentioned elsewhere. And less "I'm the package maintainer, this is my castle, go away" and more "This is how the majority does it, you follow, the benefit of it being one way, not a dozen different, outweight some personal preferences". -- bye, Joerg
Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL
On 15356 March 1977, Laura Arjona Reina wrote: There are some teams in Debian that focus in areas similar to the DPL tasks and allow people to make a difference in the project working on them, without the need - and the burden? or the satisfaction? - of being a DPL. For example: * treasury, press/publicity and partners deal with the relationship with companies/organisations, * publicity/press, the web team and events team can have influence on the image we transmit and how the project is perceived * frontdesk, MIA, outreach, events and the welcome team can have an impact in expanding/improving our user base and contributor base, helping and motivating them etc.) * ... I do not think frontdesk or MIA fit, except for delegation, they do not work with the DPL at all. Sometimes I feel that having a (single person) DPL role is somehow harmful for people to get involved in these tasks: - the elected person gets so squeezed that after their service they just prefer to focus in other tasks, Unable to properly comment on that one, until *maybe* next year. :) Though I've done lots of high profile (and sometimes) pressure jobs, and am still here and around. - the non-elected get depressed and don't continue contributing ideas/work to advance Debian in these areas, After having read your explanation to zack: I won't get depressed and use that to not contribute to the teams listed above should I not get elected. But I also won't join them unless I'm already in. For the simple reason that, should I get elected, I will have a good bunch of more time available for Debian work. That will go into DPL (and may drift to other areas I am involved with) and from there into whatever-the-DPL has with those teams. If I am not elected, that time is simple not there. -- bye, Joerg
Re: Q to all candidates: increase diversity with DDs outside Europe and USA
On 15357 March 1977, Paulo Henrique de Lima Santana wrote: We have debated on the "debconf-discuss" mailing list about DebConf21 and it was said about the huge number of DD in Europe. So, what the DPL can do to increase the number of DDs in other regions outside Europe and USA? Well. Yes, its way easier to contribute to anything, including free-software, if your day-to-day life does not consist mostly of "struggle to get through", which is one of the reasons why Europe (and the US) has so many contributors. It's important increase diversity in Debian with DD especially from southern hemisphere, right? Southern, Northern, Western, Eastern, nicest would be if the numbers of DDs (actually, free software community members) would coalesce with the numbers of people living in the various areas. Same thing for numbers of members for woman, trans, colored people, whatever. When we ever get to that, then it really doesn't matter where you are from, how you look, what body you carry. It only matters if your work is good (and you are not a nutjob). That would be nice. But unfortunately still far away. Still, on the way to that, DPL can support with promoting those goals. With spending money, if there are ways where money can support (say, some diversity grant, help financing a local event, ...). Or with plain recognition. -- bye, Joerg
Re: Question to Martin: How are your Grants and Paid DPL Proposals Differnt than Dunc-Tanc
On 15354 March 1977, Martin Michlmayr wrote: Really? Taking off weekends unless there's something urgent is "problematic"? For a volunteer, unpaid position? No. Taking time off is fine. I do that too, sometimes, or I wouldn't be a DD anymore after all this time. Announcing a set time where you basically won't be doing some work does create (IMO negative) expectations and will end up with people trying to steer around it. Especially for those that may only have those times available and now see "OH, can't deal with you then" -- bye, Joerg
Re: Conflict of Interest Statement for Joerg Jaspert
On 15353 March 1977, martin f. krafft wrote: I am holding positions of power in Debian What does this mean in the context of you running for DPL? Will you hold on to these roles, or give them up? Thats part of my platform: --8<---cut here---start->8--- 7 What with your delegations? Lets start with the most important one in this context, DAM. The constitution is simple there. $8.1.2 is specific for this. It says: The Project Leader's Delegates: […] may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. The simple takeaway here is that, should I get elected, I will resign from DAM. Besides the above quote the constitution only forbids the secretary and the chair of the CTTE to be DPL, so I do not see any conflict with keeping my other delegation, FTPMaster. That is, until the moment I would need to update it, then I would need to resign from that, as a DPL may not delegate to themself. --8<---cut here---end--->8--- -- bye, Joerg
Conflict of Interest Statement for Joerg Jaspert
Hi * Conflict of interest: I'm happy to see that your and Joerg's employers would support your DPL activities. However, I've no idea who they are or what they want from Debian. Maybe they use Debian and want to give back with no strings attached, but I could definitely see a situation where a company tries to exert undue influence over Debian by having the DPL on payroll. Right. A theoretical concern, but nothing more than that. I am holding positions of power in Debian (and other projects) for so long, that my work contract has conditions in it addressing such a possibility. Even better, (though not much important here) I have conditions that code I write will be licensed using a DFSG free license (minus parts that are actual (customer) secrets).. I work for a small company based in Darmstadt with a large customer a big german airline, me working in Frankfurt. Noone, not my boss, not anyone of those from the customer I work with, has ever tried to have me do $whatever using any of my Debian hats. They sure know I have them (and am nominated to get one more) and are happy about that, but that's all. -- bye, Joerg signature.asc Description: PGP signature
Re: Debian presence on newer platforms
On 15352 March 1977, ans...@debian.org wrote: Do you think Debian should be more active to establish (official) presence on newer platforms? For those that are free, sure. In particular I also wonder if Debian should look at Matrix[1]: it is a free and decentralized platform, and the UI (of Riot[2]) seems more friendly than IRC clients. I think that doesn't need a DPL. Anyone who wants can do it. And setup (to speeak in irc terms) channels for the users to get in. And then it can go the usual way of "the more people use it, the more important it becomes". Similar things also apply to mailing lists; there are solutions that might be more accessible to some users (e.g. mailman3's web interface which for example Fedora uses). Though I can't say much about those as I haven't used them so far. While I agree that some "more modern" going way would be nice for lists, I don't think that is an easy task. Nor one where DPL can do much (unless listmasters need some resources that DPL can approve for such a change). Its up to the listmasters, though as far as i know, our current setup is anything but easily converted. -- bye, Joerg
Re: Discussion on eventual transition away from source packages
On 15349 March 1977, Lucas Nussbaum wrote: I'm probably missing something, but it doesn't sound like a lot of work to me? It's "just" a service that: Same here: You think about just something that keeps the traditional layout around. If one does that, yes, that service isn't too hard. I was thinking further. Something like "the archive is a huge git". -- bye, Joerg
Re: Is free software political?
On 15348 March 1977, Jonathan Carter wrote: 1. Do you think that free software is inherently political? Do you think there's place for politics in free software? 2. The same as #1, but for Debian instead of free software. Well, I think that in the case of #1, the Free Software Foundation (and hence the free software movement and free software) is very much political on purpose, it's part of their core identity and this guides their decisions. In Debian's case, we definitely take less political stances (if at all), but many of our choices have consequences and I don't think it's wise to deny that there are major political consequences to our work, and while I don't think it's necessary to have as many political stances and statements as the FSF does, I do think that we should perhaps also be more diligent when considering non-technical consequences of our decisions. Hey now, that answer is for a different question of "Should Debian be politically active?". Which we, as a project, are not much of, yes. -- bye, Joerg
Re: Is free software political?
On 15348 March 1977, Jonathan Carter wrote: My question is to the other 4 DPL candidates, and I'm happy to answer it too if anyone is interested in my view. Yes, please go. 1. Do you think that free software is inherently political? Do you think there's place for politics in free software? 2. The same as #1, but for Debian instead of free software. The answer is the same. Yes, Debian (and free software in general) is definitely political. Like it or not, but creating something that is free for anyone to use, modify, redistribute and of course learn from is a political thing. Even if one doesn't like politics and ignores that side. -- bye, Joerg
Re: Discussion on eventual transition away from source packages
On 15348 March 1977, Lucas Nussbaum wrote: Couldn't we imagine a schema where a push of an annotated signed tag to the salsa repository triggers a gitlab-ci job that notifies a service on ftp-master that there's a git repo with a suitable signed tag waiting? that service could then fetch the git repository in question and create the source package from the tag. Just picking this mail, Ians before also already was good. Yes, it should be simple to use. Something which I meant by "something alongside salsa that gets triggered". Then it could be triggered not only from salsa, but also gitlab, github, personal git servers, whatnot. Also, it will be a drastical change and has many far reaching consequences and needs lots of work nefore we are near it. But I think doing "something" to a git commit that then results in "an upload" to Debian where it gets build and pushed to the mirrors would be nice. -- bye, Joerg
Re: Questions about "Winding down my Debian involvement"
On 15348 March 1977, Sean Whitton wrote: I won't write a long reply because it's not that important to the DPL election, but I did want to note that `dgit push-source` has answers for everything you've listed. I'd encourage you to take a(nother) look! Do those answers only apply if you still think of the traditional source archives to upload, or also if one envisions to go away from that? -- bye, Joerg
Re: Q to all candidates: SWOT analysis
On 15347 March 1977, Jose Miguel Parrella wrote: One of the questions in my platform hinted at one point: The "package" managers various new languages came up with. Do you (and other candidates) see this as a threat or as an opportunity? Both. It is a threat if we do nothing and ignore it or even go "Oh gosh, those newcomers with their toy language, look, they have no security". It is an opportunity, if someone steps up to take it. If we manage to put the well-known sanity our packaging delivers around the craziness of "fetch things from random git repos wherever", and that in a way that even on stable Debian you can get latest and (hopefully) greatest $languagestuff, then we win. This won't be simple. The reason why I think this is a question for everyone and not just APT maintainers is connected to a question I made in another thread. I asked whether Debian is more than Debian GNU/Linux the distro you download and install or that you get from a hoster or that you get as a side effect of someone choosing FROM debian in a Dockerfile. apt is only a small part in it. -- bye, Joerg
Re: Questions about "Winding down my Debian involvement"
On 15347 March 1977, Sean Whitton wrote: I would actually like if we end up with a "git push turns into an upload". Which would need some central $thing for it to make it so. Not sure thats salsa. Or something seperately (but maybe together with it). We already have something that is quite close to this, in the form of `dgit push-source`. I don't believe dgit to be *the answer*. I am not really sure why people think some salsa CI thing would be better than that -- but would be grateful to know. Ideally you get an upload by a simple git push. Now we want to control a bit WHEN it uploads. We also want some checks before the upload. For legal reasons we do not want the full history (think of removed undistributable files) in all cases. And so on. There are many points and I just list a tiny few. This is a long term change. With a quite radical change of workflow. Which, in the end, will benefit us all. Which needs strong drivers and a lot of support in the project. -- bye, Joerg
Re: Question to Martin: How are your Grants and Paid DPL Proposals Differnt than Dunc-Tanc
On 15347 March 1977, Stefano Zacchiroli wrote: As a random factoid related to this: in the Debian contributors survey that we ran a while ago, ~18% of the respondents who declared to be Debian contributors also declared to be paid (at least in part) for their contributions [1]. I think there is a difference between someone random paying them and Debian doing so. (Or a TO to be exact). Say, part of my time commitment for DPL, should I get elected, is 45 workdays over the year. That is quite obviously time I get paid for - but it is my employer that does. Not Debian or SPI or whatever. -- bye, Joerg
Re: Q to all candidates: SWOT analysis
On 15347 March 1977, Lucas Nussbaum wrote: You are probably familiar with https://en.wikipedia.org/wiki/SWOT_analysis Nope. Note that if you prefer not to frame this in the context of SWOT analysis, you can also answer the following four questions, which should result in basically the same information: Lets go this way instead. * What are the main 2-4 strengths of Debian today? Known to be rock solid stable. Known to just work on nearly everything you throw it at. Great resource of highly skilled people. Very independent from any one company, can't just be bought off. Release today? Tomorrow? When a marketing droid says? When its ready! Huge and diverse community. Very good defined processes for a lot of things. Especially good in the technical area. * What are the main 2-4 weaknesses of Debian today? Great pool of people with a highly developed and defended set of opinion, leading to huge discussions on central topics. Reputation for flamewars. We aren't good at marketing us. Not having a company behind us, some doors/avenues are closed. While our community is more diverse than many others, in reality we can do way better. We need more non-cis-white-male members everywhere. * What are the main 2-4 external things happening in the world outside Debian, and that are "opportunities" for Debian? That new "serverless" computing trend. Or in general, containerization, virtualization. Debian is a nice ground for it, but sure not perfect. Privacy and security are in everyones mouth, and there are derivates of us focusing on that. We are already pretty conscious of those issues, but can sure do more to fulfill what more and more people and companies nowadays want: A system that is not focused on spying on its users. But enabling them to overcome such bad behaviour. * What are the main 2-4 external things happening in the world outside Debian, and that are "threats" for Debian? Trolling. We are big enough that a certain set of people with a bad mindset take notice of us. Users chosing another distribution over us. For whatever reason. Less users means less contributors means less work means less Debian. One of the questions in my platform hinted at one point: The "package" managers various new languages came up with. -- bye, Joerg
Re: Q to all candidates: Universal Operating System
On 15347 March 1977, Ian Jackson wrote: I would like to reframe this question: When should we expect a Debian maintainer to put in effort for use cases, software designs, hardware platforms, etc., that they don't personally care about ? I have an answer to this: So long as most of the work is being done by those who are interested in the use case, maintainers (and anyone else with a gatekeeper role) should do their bit (by carrying patches, mentioning alternative dependencies, advising about debugging, or whatever). DPL candidates: do you agree ? Yes. -- bye, Joerg
Re: Q to all candidates: Universal Operating System
On 15347 March 1977, Lucas Nussbaum wrote: 1) So, if you were asked to write a Social Contract paragraph about our universality, defining/outlining both what we aim for, and also maybe some limits to that quest for universality, what would it be? I wouldn't be the one to write such a paragraph, sorry. There are people who are way better with the language to get a nice and clear one written. The limits, IMO, would be in terms of cost. Universality is nice, but if it means (as an example) each maintainer has to take an extra 3 hours per upload just for it, it wouldn't be a good thing to do. If it would "just" waste some CPU/RAM/DISK otoh, it would be good. 2) More specifically, if you believe that we should not aim for being fully universal, *how* (in terms of decision-making processes) do you think that we should draw a line about what's acceptable, for example to decide how to cater to the needs of an hypothetical Debian GNU/Darwin on m68k port? And what's your own opinion on where that line should be (specific examples could rely on debian-ports, release architectures, support for non-Linux kernels, init systems, ...) I believe we should aim to be as universal as possible without bending ourself too much. As above, cost, manpower is a size that is not hard to measure. Applied to the whole project, and it should be clear if a thing like a Debian Darwin m68k is a viable thing. -- bye, Joerg
Re: Q to all candidates: Universal Operating System
On 15347 March 1977, Jose Miguel Parrella wrote: To add to this question: Do candidates think Debian "competes" for "share"/"mindshare" of users and contributors in the "Linux distro" category? Whenever I get asked (especially at events) "I'm a new linux user, do you recommend Debian" or "I'm new, why should I use Debian", the answer is not "Yeah, use Debian because of..." but "I use Debian, like it, and can recommend it, but you should look around. Either your friends, or your local Linux user group. Find out what they use, thats what you should use. If thats Debian, great. If not, Debian may be something for you later, but as a start you want something where you have local people to ask about". And yes, Debian competes for users and also contributors. The more users, the more such users as above. Also the more contributors. And there is a limited resource of users, so everyone more is better. And if so, what do they think users and contributors expect from a "universal" distro in 2020? Do we think it even matters, or is it being reimagined? First off they expect a working system. Do candidates think that Debian has far more technical deliverables than packages in a repo plus installers? And if so, do candidates think the organizational structure [1] accurately reflects this? Would DPL candidates propose changes to the organizational structure? How would they use, for example, delegations to re-shape the org structure? I dont think that structure is set in stone, nor am I bend on changing it a lot. Wouldn't work anyways in a project like ours. It takes time and people. -- bye, Joerg
Re: Questions about "Winding down my Debian involvement"
On 15347 March 1977, Andreas Tille wrote: Recently I've read the article "Winding down my Debian involvement" from Michael Stapelberg[1]. I consider that article an interesting reading and I would love to hear the opinion of the candidates about it. I read it and it influenced parts of my platform. 1. I followed the hint to rsync checked out the source package have read the 6k d/rules of it. In line with the request for modernisation I wonder whether the candidates see any chance to convince maintainers to stick to some standard like debhelper >= 9 as a recommended build tool. (Rsync is just a random example - I have seen several other packages that made my work as bug hunter harder than necessary and I know efforts like cross building which would profit heavily from some unification.) While it seems nice that every maintainer can, more or less, do what they want in their package, as long as the outcome fits the usual policy stuff, I agree that we should get rid of parts of this. More unification in central parts, with the biggest part being packaging, is better. OTOH we need to stay open for enhancing things. So while I am a fan of "dh for everyone, throw away all the hand crafted stuff", it should not make it impossible to come up with new stuff in the future. 2. I consider packaging in Git on salsa.debian.org a big move forward to some unified workflow for Debian packaging (thanks to Salsa admins by the way). Do you see any chance to convince maintainers to maintain their packages on salsa.d.o as a recommended development platform. I would actually like if we end up with a "git push turns into an upload". Which would need some central $thing for it to make it so. Not sure thats salsa. Or something seperately (but maybe together with it). Aside that, yes, the more stuff is similar, the better and easier larger changes can be done. Though salsa or not is a small point here. How many different ways of maintaining a package in git do we have by now? Driving something here to end up with one, now that would be good. Also, something that shouldnt be the DPLs job - but the DPL may need to help out with communications, delegations, support (say, meetings and cost for them). -- bye, Joerg
Re: A few high level questions for all platforms
On 15347 March 1977, Michael Meskes wrote: But yes, depending on/with some events/companies, speaking as a DPL will be perceived much more strongly. Any "normal" DD won't be heard. If that is the case, and if its sufficient, a delegation can be good. Are you saying you would delegate the role of making-presentations-as- DPL? Or are you planning to do it yourself? Having met Chris all over the world I do think DPL speaking engagements do involve a bit of traveling and from my own personal experience, doing that with small children at home is not ideal to say the least. I'm saying that sometimes People want to hear the DPL. I don't think that is something one can delegate, you either are, or are not, the DPL. And yes, in my original sentence a *not* is missing, it should have read "If that is NOT the case, ..., a delegation can be good". Now, me and travelling: I don't think I will be travelling as much as others do/have done. But I am not planning to just stay home. I am prepared (and my family too) to attend events as DPL. -- bye, Joerg
Re: A few high level questions for all platforms
On 15347 March 1977, Jose Miguel Parrella wrote: * As a DPL, what steps would you take (if any) towards reducing the workload and breadth of activities the DPL is expected to engage in? Depending on the actual activity and there being any volunteers, it may get delegated. * Would you pursue delegating functions such as representing Debian (as a spokesperson or otherwise), resolving differences in the project or signing authority for expenditures, etc.? Now that highly depends on the function. First off, any DD can "represent" Debian, in some ways. That doesn't need a DPL hat. Sure, the hat makes it somewhat more "official", but same as any DD, the DPL can not just go there and "reveal" the new, big, until-now-secret direction of Debian (or other crazy stuff). Something like that needs the project to decide on it with the usual way. But yes, depending on/with some events/companies, speaking as a DPL will be perceived much more strongly. Any "normal" DD won't be heard. If that is the case, and if its sufficient, a delegation can be good. Resolving differences: I think we have ways to do that with technical differences, so I assume you think of social ones. Being a participant in the current two bigger such issues, I do think that we can still evolve a lot there, and a delegation *may* be part of it. But there are numerous people in the various involved teams already thinking about it, I don't want to take an early step here and "announce" it should go this or that way. Signing for expenditure: I think it should stay the DPLs job to make large decisions about Debian assets. I also think that not each little cent needs to be approved by the DPL. Say, something like "DSA can spend anything below $amount within $timeframe on hardware" (eg. to replace broken disks) is a good thing to do and can easily be extended to other such predictable spendings. * Do you anticipate anything in your platform would require an amendment to the constitution or a foundation document, or to otherwise call a GR within the next year? If so, what is it and how would you debate it? I do not expect a change to a foundational document, but depending on how it goes, two or three points in it could end up as a GR to have project backup. * Do you believe in the concept of a DPL team? If so, do you plan to implement such a concept in the next year? If so, how? I do not believe in a DPL team as a predefined thing that MUST happen and has THOSE members. So no, I do not intend to implement such a concept. OTOH, as I wrote, I'm not afraid to ask for help and there may be stuff that can be given to others. If that's the case I would see if there is a volunteer for it. * Do you believe Debian is actively pursuing a vision for the next 5 years? If so, what is it? If not, do you think it should? And if so, how do you expect to work with all the decision-making bodies? Oi, those are loads of ? here. I do not think Debian as a whole has a common vision for the next 5 years ecept for "Enhance it and release the next version". Which is a good vision in and of itself, but (I guess) probably not what you ask for. I assume a vision for your question would be more like "We need to become the #1 container provider for all the newfangled technology". Or "We must integrate all and everything from any derivative and offer it within Debian directly". I do not think that there is such a common vision all over Debian. Instead I think there are multiple areas / groups of people that do have their own vision where to go with Debian. Like there are the people working on the cloud stuff, those with Debian med, people who want to see Debian as the one place for all of nodejs/rust/go/... with all that entails. And I think it is a good thing that we have so many different areas. Molding them all together based on our common grounds makes us stronger as a whole. And the way the DPL can work with any decision-making body is by talking. By organizing meetings, possibly joint ones for multiple teams. And by finding out what they need and if applicable, get that to them. -- bye, Joerg
Re: Debian Project Leader Elections 2019: Call for nominations
On 15337 March 1977, Debian Project Secretary wrote: Since there were no candidates during the nomination period, the nomination period has been extended by 1 week. Soo, lets ensure we do not have another week: I hereby nominate myself for the DPL election 2019. -- bye, Joerg signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
On 15337 March 1977, Zlatan Todorić wrote: So, funny, maybe we will live to our long history of community fostering (which is the thing I most enjoy from Debian, besides that we produce kickass OS) and be leaderless as we in all nature of project actually are. While the idea of going leaderless may sound good, the project isn't setup for that. There is a whole bunch of things going via the leader that is either hard to delegate or impossible to do so. It would need quite a bunch of changes to the constitution to enable that. -- bye, Joerg
Re: Debian Project Leader Elections 2019: Call for nominations
On 15337 March 1977, Sam Hartman wrote: In fairness, I'd recommend that the nominations period be extended for some explicit time. I think that we want to have a known window for new nominations rather than say starting the campaigning as soon as someone nominates themselves. §5.2.4 to the rescue. (Something I also missed earlier). --8<---cut here---start->8--- For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning and discussion. If there are no candidates at the end of the nomination period then the nomination period is extended for an additional week, repeatedly if necessary. --8<---cut here---end--->8--- So basically we are now having one more nomination period week. -- bye, Joerg
Re: Q: NEW process licence requirements
On 14994 March 1977, Adrian Bunk wrote: > Since Debian distributing whatever random people upload to salsa > is fine for you, I fail to see the point why you would consider > distributing what is in the DD-only NEW a huge problem. It is not fine. But I've chosen to not go down the road that would be needed here. I've got enough on my plate, I can't put this on. If someone does go down the road, then any project creation on salsa would possibly end up needing to be vetted by an admin (or a new team doing this, or a combination of new team and NEW handling, as parts of this surely could be merged then). Right now, the handling of stuff on salsa follows what was done for alioth "It may have a .debian.org, but its not run by Debian, so the project chose to ignore parts of the problems with it". And implicitly either put it onto the shoulders of the alioth admins, or the individual. There is an argument for this having changed now, with the new setup, yes, but following that opens such a big can, I don't want to do this. Thats something the DPL might want to get some informed (ie. lawyers) opinion on, how free that service can be. I would love for the outcome of that to be something like "It's fine if open, as long as there is a contact that quickly disables reported $legalfoo violations". Also, in a way we do assume people NOT intentionally putting bad stuff up, though the current system does make it farely easy to play bad here. -- bye, Joerg
Re: Q: NEW process licence requirements
On 14993 March 1977, Adrian Bunk wrote: > As an example for a rule that does not make sense, recently a member of > the ftp team stated on debian-devel that the contents of NEW cannot be > made available to people outside the ftp team since it might not be > distributable, and that this is not expected to be changed. Like it or not, but there *is* a big difference in the project making something available for the big wide world (which a public NEW would be), or a user putting it somewhere readable for everyone even though the latter might be using project resources too. Sure, this is an argument for making salsa restricted too and have NEW processing on any project there, and be safe(r). *I* dont want that, you seem to advocate for it. -- bye, Joerg
Re: having public irc logs?
On 14634 March 1977, Gianfranco Costamagna wrote: > Debian has a "we don't hide things" wording in his constitution. > However we don't have a public irc log system, and most > of the conversations between us are happening there. > How do you relate to that issue? Do you see it as a problem, > or do you think people should join irc to read our conversations? > (channels protected by a passphrase are of course out of this question). If you follow your way of thinking (which is wrong here, btw :) ), you end up requiring that every time two Developers meet and speak about Debian things - they need to transcribe them and put that online somewhere. Or we hide... Every conversation at DebConf, as soon as it goes beyond "Want another beer?" needs to be scribbled down and put online. Or we hide... Silly? Yes, but thats what you started. We as a project aren't saying that everything will be available for everyone everywhere, and thats good. -- bye, Joerg
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
On 14549 March 1977, Sean Whitton wrote: > No-one who understands how GNU/Linux distributions work thinks that > there is anything problematic about short-term embargos of information > about serious security bugs. However, the SC is not just for those > people: it's also something for newcomers to read. > Imagine a newcomer who finds SC clause 3 very attractive: they > particularly value transparency about development. Then they learn that > certain information is held in a separate, non-public bug tracker, and > their initial enthusiasm for Debian is somewhat dampened. If we pass > this GR, we can avoid leaving a bad taste in that newcomer's mouth. > That's good for Debian. Is there really anyone like this? And dampened by how much, when thinking about it? Also, this is IMO nothing for a foundational document. But some docs around it as explanation on how real world handles things. Adding something like this opens a wormhole of "lets add this extra condition here" "and hey, this little one there too" and gets the document from a nice simple "thats it" to a murky "its this, but sometimes that, and other times this" and end up with a hell where you can avoid everything because the definition gets too mushy. Right now its plain simple and one has to have a real good reason to go around it, which is why its only embargoed security stuff, time limited, that does. -- bye, Joerg
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On 14361 March 1977, Nicolas Dandrimont wrote: > === BEGIN GR TEXT === > > Title: Acknowledge that the debian-private list will remain private. > > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. > 2. In keeping with paragraph 3 of the Debian Social Contract, Debian >Developers are strongly encouraged to use the debian-private mailing >list only for discussions that should not be disclosed. > > === END GR TEXT === Seconded. -- bye, Joerg > 20. What would you do if you wanted to retire from the project? Remove the passphrase from the (secret) gpg key and post it to debian-devel. The keyring maintainers will lock the account ASAP. signature.asc Description: PGP signature
Re: General Resolution: Fix Minor Bugs in Constitution
On 14106 March 1977, Sam Hartman wrote: >- GENERAL RESOLUTION STARTS - > > >Constitutional Amendment: TC Supermajority Fix > >Prior to the Clone Proof SSD GR in June 2003, the Technical >Committee could overrule a Developer with a supermajority of 3:1. > >Unfortunately, the definition of supermajorities in the SSD GR has a >off-by-one error. In the new text a supermajority requirement is met >only if the ratio of votes in favour to votes against is strictly >greater than the supermajority ratio. > >In the context of the Technical Committee voting to overrule a >developer that means that it takes 4 votes to overcome a single >dissenter. And with a maximum committee size of 8, previously two >dissenters could be outvoted by all 6 remaining members; now that >is no longer possible. > >This change was unintentional, was contrary to the original intent >of the Constitution, and is unhelpful. > >For the avoidance of any doubt, this change does not affect any >votes (whether General Resolutions or votes in the Technical >Committee) in progress at the time the change is made. > >Therefore, amend the Debian Constitution as follows: > > Index: doc/constitution.wml > === > --- doc/constitution.wml(revision 10982) > +++ doc/constitution.wml(working copy) > @@ -913,7 +913,7 @@ > > >An option A defeats the default option D by a majority > - ratio N, if V(A,D) is strictly greater than N * V(D,A). > + ratio N, if V(A,D) is greater or equal to N * V(D,A) and > V(A,D) is strictly greater than V(D,A). > > >If a supermajority of S:1 is required for A, its majority > ratio > > > > > > >Constitutional Amendment: Fix duplicate section numbering. > >The current Debian Constitution has two sections numbered A.1. >This does not currently give rise to any ambiguity but it is >undesirable. > >Fix this with the following semantically neutral amendment: > > - Renumber the first section A.1 to A.0. > > >- GENERAL RESOLUTION ENDS - Seconded. -- bye, Joerg signature.asc Description: PGP signature
Re: General Resolution: Fix Minor Bugs in Constitution
On 14106 March 1977, Sam Hartman wrote: >- GENERAL RESOLUTION STARTS - > > >Constitutional Amendment: TC Supermajority Fix > >Prior to the Clone Proof SSD GR in June 2003, the Technical >Committee could overrule a Developer with a supermajority of 3:1. > >Unfortunately, the definition of supermajorities in the SSD GR has a >off-by-one error. In the new text a supermajority requirement is met >only if the ratio of votes in favour to votes against is strictly >greater than the supermajority ratio. > >In the context of the Technical Committee voting to overrule a >developer that means that it takes 4 votes to overcome a single >dissenter. And with a maximum committee size of 8, previously two >dissenters could be outvoted by all 6 remaining members; now that >is no longer possible. > >This change was unintentional, was contrary to the original intent >of the Constitution, and is unhelpful. > >For the avoidance of any doubt, this change does not affect any >votes (whether General Resolutions or votes in the Technical >Committee) in progress at the time the change is made. > >Therefore, amend the Debian Constitution as follows: > > Index: doc/constitution.wml > === > --- doc/constitution.wml(revision 10982) > +++ doc/constitution.wml(working copy) > @@ -913,7 +913,7 @@ > > >An option A defeats the default option D by a majority > - ratio N, if V(A,D) is strictly greater than N * V(D,A). > + ratio N, if V(A,D) is greater or equal to N * V(D,A) and > V(A,D) is strictly greater than V(D,A). > > >If a supermajority of S:1 is required for A, its majority > ratio > > > > > > >Constitutional Amendment: Fix duplicate section numbering. > >The current Debian Constitution has two sections numbered A.1. >This does not currently give rise to any ambiguity but it is >undesirable. > >Fix this with the following semantically neutral amendment: > > - Renumber the first section A.1 to A.0. > > >- GENERAL RESOLUTION ENDS - Seconded. -- bye, Joerg
Re: GR: Selecting the default init system for Debian
On 13461 March 1977, Guillem Jover wrote: I think that forcing a decision through the TC at this time was very premature and inappropriate Quite the contrary, it was the right thing to do. This issue will not get any easier or more clearcut the longer we let it wait and see if maybe the maintainers will get to a consensus. They won't, this much has been clear from the beginning, the systems are simply way too different for that to happen. So it was the right time (or maybe even a bit late) to ask the TC to take this decision. I feel it's inappropriate for a small group of individuals to forcibly decide the global direction for the entire project. Such decisions, on issues that are as much technical as strategic, political or of a subjective design nature, can have huge implications for what contributors or other Debian-based projects might have to work on, or stop working on. I feel that such decisions must belong to the project at large. Where do they decide the global direction for the project? They have a technical decision to do. Sure it has a wide impact, but global direction is something different than just an init thingie. Also, seeing how much involvement we have in votes usually, I am far more happy to have a small group of people invest a lot of time to get to know all the various edges of all the involved systems and making an informed decision based on that, giving us long reasonings WHY they decided the way they did, than having a vote where a few hundred CAN vote, way less than that usually DO vote, and even less really inform themself of WHAT they vote on. Sure, there may be some who go long ways to get all the details, but I could bet their number is SMALL, especially if you look at, eg., how deep TC members like Russ went into the issue. The quality of the decision will be much better with the CTTE. -- bye, Joerg I. What would you do if a package has no sane default configuration? (There is *no* default configuration that works on most systems!) The best thing to do would be to add such a default configuration. [... ARGS ...] signature.asc Description: PGP signature
Re: Naming of non-uploading DDs
On 12243 March 1977, Stefano Zacchiroli wrote: On Sat, Sep 18, 2010 at 09:36:50AM -0500, Kumar Appaiah wrote: Even better, now with attachments! There is yet another pronoun I have missed. Please find a patch attached. Applied (wording / punctuation fix), thanks! New current text is attached. Text with Sha1sum 3dc10c8dcee25fd9af5d8895ad4bd2d9176b9397 seconded. -- bye, Joerg I'm normally not a praying man, but if you're up there, please save me Superman. pgpVkK4YV9njU.pgp Description: PGP signature
Re: Naming of non-uploading DDs
I think unlimited upload access should be simply another one of those sets of permissions that some people have and others don't. Those who need that access to do their work can receive it after appropriate vetting of their ability to use that access appropriately, just as someone would volunteer to join ftp-master, or DSA, or keyring-maint, or the Lintian maintenance team and would, after appropriate vetting, be given additional privileges to do that work. Having or not having additional access should not change the basic DD status. I, using my DAM hat, don't care if this gets a name. It got one as it seemed good at the time of writing, but whatever its named (or not) is REALLY just a very tiny little bit of this thing and about as important as the fact if someone had rice or meat for breakfast. The more important part is getting the project to acknowledge the concept of a set of members/developers/whateveryounameit not having upload rights by default and letting DAM/FD/theusualpeople just manage that. The important part is opening our membership to people who deserve it, but who (most likely) never ever will maintain a package and as such currently have a hard time joiningm as we do want to see new people have at least a basic set of knowledge packaging requires (be that using a set of questions or by evaluating what they have in the archive, the procedure there is up to the AM). And the latter part should change, giving people who want to an early exit - consequently a little less ability later on, but one they dont need/want then. I, using my FTPMaster hat, do care a lot that we do not get $whateveritsname with upload rights that never ever had to show at least the basic understanding of packaging work. Looking at all the errors existing Developers do, even longstanding ones, having something like TS drop away entirely will be near death. Whoever thinks it cant be that bad should do a month of release team, qa or ftpteam work. You will think different. -- bye, Joerg Naturally; worms that don't know what they are doing end up as fish bait, instead of getting invited into weird math experiments. -- Lars Wirzenius -- 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/87fwxbquvo@gkar.ganneff.de
Re: GR: welcome non-packaging contributors as Debian project members
On 12238 March 1977, Stefano Zacchiroli wrote: --- The Debian project aims at producing the best free operating system. To that end the project benefits from various types of contributions, including but not limited to: package maintenance, translations, infrastructure and website maintenance, porting, bug triaging and fixing, management activities, communication, testing, legal advice, quality assurance, etc. The Debian project acknowledges that: * To pursue Debian goals, package maintenance as well as a wide range of other technical and non-technical contributions are all valuable. * Active contributors of non-packaging work, which share Debian values and are ready to uphold Debian Foundation Documents, deserve the opportunity for becoming Debian project members. The Debian project therefore invites the Debian Account Managers to: * Endorse the idea that contributors of non-packaging work might become Debian Developers without upload rights to the Debian archive. These new developers shall be recognized as Debian Contributors (DC). * Establish procedures to evaluate and accept Debian Contributors. * Initiate the appropriate technical measures to enable Debian Contributors to participate in Debian decision making and to access Debian infrastructure. --- Seconded. -- bye, Joerg liw we have release cycles, that's why it takes so long to get a release out; if we had release race cars, things would go a lot faster pgpZlgfMjRxNr.pgp Description: PGP signature
Re: Questions for all candidates: decentralization of power
I also think that we need to review the NEW uploads. But this is not what I discuss here. I propose to let all DDs look what is in the NEW queue. (This would of course help to review the NEW uploads). If there is ever any legal fun around this, it is a *HUGE* difference if you can say Only people who really have need have access before the check is finished or Everyone who feels like it and happens to be a DD at that time has access. I think that the claim that some people can be sued if some DD screwed up is vague, and is really difficult to discuss factually. I think that if the NEW queue in the ftp-master mirror is readable for all the DDs, there is no risk for the DPL, his delegates, or the sponsor of the provider of the ftp-master mirror machine and connectivity to be sued. And on what base do you ground that? -- bye, Joerg Maybe, just once, someone will call me 'Sir' without adding, 'You're making a scene.' -- 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/87mxxnufdb@gkar.ganneff.de
Re: Question for all candidates: Release process
(And to answer to the comment ‘you do not need to be DPL for doing this’, that is true, but if I make a bad score at this election, I will conclude that there are not many persons interested in what I propose anyway, and will save everybody's time by not discussing them further in the short term.) Now, I think thats the wrong conclusion. While it should be pretty known that I am not really a fan of you getting DPL, I have one remark about the above: - A good idea should (unless its constitutional required, but what is?) not be bound to a DPL term. - A lost election might not mean that the ideas are all bad. (It can mean it). It might just mean they are presented wrong, or that everyone thinks they got presented wrong/at wrong time/at wrong place. -- bye, Joerg I'm not a bad guy! I work hard, and I love my kids. So why should I spend half my Sunday hearing about how I'm going to Hell? -- 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/8739zjlhra@gkar.ganneff.de
Re: Q for all candidates: license and copyright requirements
Our users includes not only an individual with a single computer who never sees the source, but also derivative distributions, private organizations, system administrators, etc, all of whom may need to modify the source for their own purposes. Our users, if they want to modify, study, redistribute or use after rebuild our system, need the source. At no moment these operations involve modifying a RFC or a binary program that is aimed at run on a Windows system. I conclude that that kind of file, although present in our source packages, are not part of the source of our operating system. *cough* (My first thought was *WAYS* more impolite.) So, you want to make Debian unfit to be distributed by anyone. You seriously consider distributing undistributable files just because you are too lazy to do your maintainers work. You seriously want to put all our mirrors, all or CD distributors AND ALL OUR USERS at risk to break laws and maybe get sued (some of our users definitely are large enough to be a nice target for law trolls), just because you fucking dont want to do the work? I think that we should have the possibility to redistribute a bit-identical upstream archive when possible. Thats possible whenever upstream has fixed his tarball to not include non-free bits. repacked tarballes, we can do with pristine ones. If we do not trust each other that a couple of useless non-DFSG-free files can be ignored, what else can't we trust ? You. -- bye, Joerg You know, boys, a nuclear reactor is a lot like a woman. You just have to read the manual and press the right buttons. -- 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/87sk7qku6t@gkar.ganneff.de
Re: Q for all candidates: license and copyright requirements
The second option aims at clarifying what is the source of the Debian operating system. It is controversial. It is a lot but not controversial, actually its pretty clear. For that statement alone *I* hope NOTA will have a big win over you, sorry. It shows you are way off with actual project. -- bye, Joerg Mr. Scorpio says productivity is up 2%, and it's all because of my motivational techniques -- like donuts and the possibility of more donuts to come. -- 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/87ljdiu7b3@gkar.ganneff.de
Question to all Candidates: 2IC
Heyho, a little question to all those up for the next DPL: Do you plan on taking on a 2IC or a team? If so: Who? And why this/those? Thanks. -- bye, Joerg Well, I’m tired of being a wannabe league bowler. I wanna be a league bowler! pgpc4eVogfX8Q.pgp Description: PGP signature
Re: lifting censorship during the DPL campaign ...
On 11696 March 1977, Sven Luther wrote: I come to you again, with the same request as i did last year, that you lift the censorship you are imposing on me for the duration of the DPL campaign on debian-vote. As you obviously do not know the word, lets copy what a dictionary or also Wikipedia has to say: Censorship: Censorship is the suppression of speech or deletion of communicative material which may be considered objectionable, harmful or sensitive, as determined by a censor. This is *not* what is done in your case. You are free to say whatever you want[1]. And none of your mails that made it to the lists got deleted. What is done is called a Ban, Debian decided to no longer be an audience for whatever you have to say. Quite different from censorship Debian does *not* forbid you to speak, Debian just does not want you to use up any Debian resource. [1] respecting the usual laws everyone follows The current taboo i am under, is well beyond what the DAM originally decided after my explusion, and the ask a DD to forward your mails politic is not working (almost 50% or so of my mails are not forwarded, either because there is some pression on the would-be forwarders, or because people tell me what i say would not further their own argument and position). Maybe you should listen to them, if so many of the people tell you its not worth it. And yes, i am still hurting to even write this by the evil you have done to me, but i am also ready to forgive you, as i have amply shown in the past by proposing constructives approaches to solving the conflict which would have been in the best interest of debian, but which received no support at all. The ball is in your camp, as it was since the start of this mess. I'm not sure how big the signs have to be before you read them, but this camp does not want to be assigned with you anymore. The biggest letters for years now read MOVE ON, THERE IS MORE IN THE WORLD THAN THIS Don Quichotte LIKE 'FIGHT' YOU PLAY -- bye, Joerg I think there's a world market for about five computers. -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Amendment: Enhance requirements for General resolutions
On 11697 March 1977, Neil McGovern wrote: AMENDMENT START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(2Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). AMENDMENT END Rationale: This is basically s/K/Q/. It keeps the 'immediate override delegate decision' as twice as hard as proposing a GR. Well. I personally dislike that, and that speaking as a delegate who had a Thank you vote from the project already, but if you get enough seconders, I'm happy to have this on the vote too. -- bye, Joerg lenny schneidet nie chilis und wascht euch dann _nicht_ die hände und reibt euch dann an der nase. lenny uargs, wie das brennt lenny hammer. das ist ja schlimmer als die dinger zu essen... pgpJV0cKIkcHu.pgp Description: PGP signature
Proposal: Enhance requirements for General resolutions
Hi, I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. Currently it needs 5 supporters to get any idea laid before every Debian Developer to vote on. While this small number was a good thing at the time Debian was smaller, I think it is no longer the case. We currently have over 1000 Developers, and even if not everyone is active all the time, there should be a little higher barrier before all of them have to deal with something, effectively taking away time from their usual Debian work. While one could go and define another arbitary number, like 10 or 15 or whatever, I propose to move this to something that is dependent on the actual number of Developers, as defined by the secretary, and to increase its value from the current 5 to something higher. My personal goal is 2Q there, which would mean 30 supporters. If you can't find 30 supporters, out of 1000 Developers, your idea is most probably not worth taking up time of everyone else. Various IRC discussions and the discussion on debian-project in December told me that others feel similar. So here is a proposal. As the discussion in December also told us, we should vote on different options than just one, so I will also send in an amendment. My personal goal would be to end up with a vote having options similar to the ones pasted below as an example, but if someone feels like having a Keep it like it is, no discusssion is needed, I would accept such an amendment too. (Not that I think its neccessary, for me FD means that, but still). - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [ ] Choice 1: Enhance seconders to 2Q [3:1] [ ] Choice 2: Enhance seconders to Q [3:1] [ ] Choice 3: Further Discussion - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- As this will change the constitution it will need a 3:1 to win. (see Constitution 4.1.2) Of course, this being a proposal to enhance the required seconds, I would love if many people do second this, even if we might be past the currently needed limit already. The more the better. :) PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END Practical changes: Taking the definitions of the latest GR we had, Current Developer Count = 1018 Q ( sqrt(#devel) / 2 ) = 15.9530561335438 K min(5, Q ) = 5 Quorum (3 x Q ) = 47.8591684006314 this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), considering that a GR affects more than 1000 official Developers and uncounted amounts of other people doing work for Debian, I think its not too much. Especially as point b only requires 15 people, 3 times the amount than now, in case there is a disagreement with the DPL, TC or a Delegate. -- bye, Joerg * libpng2 no libpng3 no why ? because no yes no yes no yes bullshit no yes no yes no yes stop ? no when someday beep beep beep beep (Closes: #157011) -- Christian Marillat maril...@debian.org Thu, 29 Aug 2002 16:41:58 +0200 pgpUDbLd85ZRf.pgp Description: PGP signature
Amendment: Enhance requirements for General resolutions
Hi, and here is the promised amendment which will require a maximum of floor(Q) developers to second a GR. PROPOSAL START General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). PROPOSAL END Practical changes: Taking the definitions of the latest GR we had, Current Developer Count = 1018 Q ( sqrt(#devel) / 2 ) = 15.9530561335438 K min(5, Q ) = 5 Quorum (3 x Q ) = 47.8591684006314 this will mean that future GRs would need 15 other people to support your idea. -- bye, Joerg Could you please add me to the mirr...@debian.org alias. I'm not receiving enough spam. -- Andrew Pollock pgpt8bg5lg3r9.pgp Description: PGP signature
Re: Proposal: Enhance requirements for General resolutions
There are some that do not take part in the discussions but vote, there are those who do not even follow debian-vote because they do not feel it is worth the effort, and those that are simply not active at all. I do not have the numbers right now, but IIRC we have had an average of 300 to 400 votes in the most controversial disputes recently. In other words, considering the seconds requirement from the 1000-something DDs we count formally is fiction, when less than half of them actually participate in the decision process. There is nothing else that good to use. *I* wouldnt want to write something like take the amount of voters for the latest GR/DPL election to calculate Q. That would be sick. And using the official DD count does work for all the other parts too, so I see no reason to define something special now, in fear of people wont vote. -- bye, Joerg NM-fun: The Debian project, at least for me, is not a joke, [...] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
Of course, had the FTP master rejected packages under the AGPL from the archive, I would not have bothered with a GR. However I would like this GR to be considered independently of the FTP master resolution. They are not the target, the AGPL is. It is not seperate. You do want to override a decision from us, which is that the AGPL is fine for packages in our archive. You do want Debian to decide that this is not true and the AGPL is not ok. Fine, have it, if you find seconders, but clearly name it after what it is please. -- bye, Joerg Some NM: A developer contacts you and asks you to met for a keysign. What is your response and why? Do you like beer? When do we meet? [...] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DPL Debates [Re: Debian Project Leader Election 2009]
If someone can't set up a poll, I'll send another message asking for DDs to privately mail me (or maybe me-too to -vote) if they find the debates useful. http://doodle.com/nmpesn9t5fwv6ewe Having this run for 7 days now, we had 72 participants. The question asked was Are the Debian DPL IRC Debates useful and should we keep them? and people could chose Yes, No, I don't care, never looked at one. and we have Yes 34 No 32 Don't care 12 From that one can chose Yes as a final winning option, but it is a very tiny margin. And some people did select Yes and No together. -- bye, Joerg But i don't think that we talk a lot, as far as i can see, you live in the USA. Australia. Only minor details like timezone and hemisphere but pretty much the same. TZ is UTC+10 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DPL Debates [Re: Debian Project Leader Election 2009]
Perhaps someone could set up a poll for DDs to indicate whether they find the debates useful or not? [I think Jeroen was doing this last?] If someone can't set up a poll, I'll send another message asking for DDs to privately mail me (or maybe me-too to -vote) if they find the debates useful. http://doodle.com/nmpesn9t5fwv6ewe -- bye, Joerg * maxx hat weasel seine erste packung suse gebracht, der hat mich dafür später zu debian gebracht weasel .oO( und jetzt ist der DD. jeder macht mal fehler.. ) maxx du hast 2 gemacht du warst auch noch advocate :P -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
So, I think you made a mistake, a very serious one, and when asked about it, your explanation is completely unsatisfactory. How do we solve this? Currently, the only solution I see is that we ask the developers what they think, and hold another vote. Do you have any other idea in mind? How about accepting that the project wants to release, and not want to have yet another vote by someone who just doesnt like the outcome of the last? Please hurt another project, not Debian, we had enough of this already. -- bye, Joerg snooze02 sind jabber und icq 2 unterschiedliche netzwerke ? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
Do you have any other idea in mind? Btw, Joerg, that goes for you too. If you have something constructive to say, this would be a good time. How about you going elsewhere until Lenny is released, then coming back as soon as that happens and start working on what is left to fix then? (Not right before a release, right after a release for a change.) -- bye, Joerg Some NM: graphviz: ouch, that license is hard to read, damn lawyer gibberish. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
I thought FD was also a vote for release Lenny given it didn't change the status quo and before the GR the release team were quite happy to release... If you believe that the release team had the authority to release lenny with an arbitrary amount of non-free software, then yes, that would seem accurate. For someone that is in Debian for so long its pretty bad how one can misjudge it... The release team has the authority to release Lenny. At whatever point they wish and feel good with it. They provide a list of what criteria need to be met for that. For the package contents of that release, they take whatever we, all the maintainers uploading packages, and what we, the ftpmasters, put into the archive. Now, if one dislikes a decision of a delegate, one can run a GR against it. Somehow we just had one, and the outcome does say they can release with the kernel that is currently in Lenny. Like it or not, but thats the option that won, no matter how fucked up the ballot may have been. Dislike this outcome? Do Debian a bad service and run yet another GR against Lenny. Or, to have something new, do such things right *after* a release, not right before one.[1] [1] But that wouldn't be half as fun complaining, wouldnt hurt Debian as much, eh? -- bye, Joerg lamont is there a tag for won't be fixed until sarge+1? sam depends whether the BTS is year 2037 compliant -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Discussion: Possible GR: Enhance requirements for General Resolutions
Hi, I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. We are over 1000 Developers, if you can't find more than 5 people supporting your idea, its most probably not worth it taking time of everyone. Various IRC discussions told me that others feel the same. So here is a possible proposal. Probably needs en_GANNEFF cleanup, and might need other changes too, I try collecting them from replies. As this will change the constitution, if we ever go and vote on it, it will need a 3:1 to win. (see Constitution 4.1.2) Oh, note. While this is written as a GR, this is a discussion proposal only. I'm *not* calling for seconders with this mail. Thats also the reason for the reply-to/mail-followup-to header going to -project, please respect them. General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). Practical changes: Taking the definitions of the latest GR we had, Current Developer Count = 1021 Q ( sqrt(#devel) / 2 ) = 15.9765453086705 Quorum (3 x Q ) = 47.9296359260114 this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), considering that a GR affects more than 1000 official Developers and uncounted amounts of other people doing work for Debian, I think its not too much. Especially as point b only requires 15 people, 3 times the amount than now, in case there is a disagreement with the DPL, TC or a Delegate. -- bye, Joerg Please, not the graphviz one again, I only just finished the therapy I had to start after I read it the first time. I'm sure this one was written by some sort of non-human entity. I would go for lawyers. pgp1EZ1bRL2eH.pgp Description: PGP signature
Re: I hereby resign as secretary
On 11603 March 1977, Manoj Srivastava wrote: I am hereby resigning as secretary, effective immediately. :( Sorry to hear that. Whoever is your follower *will* have a hard time. As to the people who emailed me that they are putting together a petition for the DAM to have me removed from the project, I hear you too. I am going to spend the next few days evaluating how important the project is to me, and whether I should save you the bother or an expulsion process. There haven't been such a request yet. Honestly, I can't imagine strong enough arguments to open such a process. While there certainly has been a lot of discussion around the last vote and its ballot and whatnot, that alone wouldn't, IMO, suffice to forcefully kick you out of Debian. I do hope you continue working in Debian, even if the work you chose will be very different to the one you did in the past. -- bye, Joerg exa look i can't afford to to any more work without becoming a DD pgplZgoPmhyYX.pgp Description: PGP signature
Vote results for vote 002?
Hi, just out of curiosity (somehow I'm affected :) ): When do you plan to provide us with the results of the vote that was supposed to end 23:59:59 UTC on Sunday, 14th Dec, 2008? In the past (IIRC) it was always nicely a few minutes after the vote ended, at least a preliminary result / notification. Also, according to http://ikibiki.org//blog/2008/12/15/Secretary_epic_fail/ the vote is still open and accepting ballots. Cite: --8schnipp-8--- This is an acknowledgement for your vote [record msg00356.raw] for the vote Project membership procedures sent in on Mon, 15 Dec 2008 08:37:16 +0100, with the subject Re: Final call for votes: GR: Project membership procedures … Your vote has been recorded as follows … I note that this is not your first vote. The time now is Mon Dec 15 08:08:06 2008 Thanks for your vote. --8schnapp-8--- Hope you are going to sort out every little ballot that got send to late? The website also wants updates, but thats way less priority (it has an up to 4h? delay anyway) Thanks! -- bye, Joerg Some NM: main contains software that compiles with DFSG. [hehehe, nice typo] Of course, eye mean complies, knot compiles. Sum typos cant bee caught bye spelling checkers. pgpD1svaz8IA9.pgp Description: PGP signature
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
On Tuesday 28 October 2008 00:21, Joerg Jaspert wrote: So, for the sanity (if any is left), could the proposer and all its sponsors, agree to not have an immediate vote on this, as it *WONT* do anything except creating needless work? You could give them an incentive to do so... WTF do you think did I do with my mail? Would you please start to *read* before you reply? -- bye, Joerg From a NM after doing the license stuff: I am glad that I am not a lawyer! What a miserable way to earn a living. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possible amendment for Debian Contributors concept
As long as Joerg doesn't agree with that, I don't see why we should drop the immediate vote or the GR itself. Then please explain what the immediate vote will gain, besides *NEEDLESS* work for the secretary (running it), needless work for everyone (to vote)? There is 0 need for the immediate vote, and insisting on it is nothing else then wanting to hurt Debian more. -- bye, Joerg pasc man pasc the AMD64 camp is not helped by the list of people supporting it pasc when nerode is on your side, you know you're doing something wrong -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
On 11551 March 1977, Charles Plessy wrote: I would be more than happy if a discussion between the different poles of opinions would start, with focus on convergence. This GR effectively blocks any [motivation to have a] discussion. -- bye, Joerg A.D. 1492: Christopher Columbus arrives in what he believes to be India, but which RMS informs him is actually GNU/India. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DAM has no competency to make changes to membership structure
On 11551 March 1977, martin f. krafft wrote: The changes announced the 22nd of October on the debian-devel-announce mailing list (Message-id: [EMAIL PROTECTED]) are suspended [§4.1(3)]. This suspension is effective immediately [§4.2(2.2)]. I do not understand why we need to do this at all. According to [0], Joerg has been empowered to create and remove developer accounts according to the New Maintainer procedure. He has not been empowered to introduce new membership classes or restructure membership in any other way. 0. http://lists.debian.org/debian-devel-announce/2008/04/msg7.html You are wrong. Both in the term of DAM has no competency to do this and in the delegation itself. Note that the above is jut making something clear(er) which hasnt been that before. I was delegated DAM years ago by Martin, the relevant mail is http://lists.debian.org/debian-project/2004/12/msg00277.html The proposed changes are outside of the delegate's competencies. You are wrong. The changes I propose are all well within the DAMs competency. -- bye, Joerg #debian.de @ OFTC (01:38) michael hui, hier wird sonntags gechattet :) (01:39) maxx ja, aber nur zwischen 1:35 und 1:45, wenn der Sonntag der 1. im Monat ist :) (01:39) Sahneschnitter wasn hier los? activity :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- a1ea0fab-9ff7-4466-a951-99c712df8192 [ ] Choice 1: Decision on membership reform stands until GR decided [ ] Choice 2: Decision on membership reform delayed until GR decided [ ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- This ballot is wrong. It is *not* a membership reform. -- bye, Joerg That's just f***ing great, now the bar for being a cool guy in free software just got raised. It used to be you just had to write a million lines of useful code. Now you've got to get a subpoena from SCO to be cool. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for Proceedural Vote: Suspension of the changes of the Project's membership procedures.
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- a1ea0fab-9ff7-4466-a951-99c712df8192 [ ] Choice 1: Decision on membership reform stands until GR decided [ ] Choice 2: Decision on membership reform delayed until GR decided [ ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- This ballot is wrong. It is *not* a membership reform. Suggested wording then? None at all, drop the immediate vote. As I already explained none of this is implemented yet. None of this will be implemented within the next few weeks. So, for the sanity (if any is left), could the proposer and all its sponsors, agree to not have an immediate vote on this, as it *WONT* do anything except creating needless work? It's more than enough to have the normal vote procedure run. Of course the secretary has to accept this, as its not written down in constitution, but as this immediate vote is a NOOP, no matter what the outcome is, it would only save them work to accept it. -- bye, Joerg 00:00:11 LupusE goebelmeier: http://ftp-master.debian.org/new.html - warum steht hier 'mplayer'? ist das eine whishlist? pgpSY0Gz6a8v7.pgp Description: PGP signature
Re: Q: All: Account creation latency
On 11327 March 1977, Pierre Habouzit wrote: We need to break that logic. I would like to talk with James and try to convince him to create accounts as they come. It's well known that small task (when they take less than 5 minutes) are usually best done on the fly instead of accumulating them. And if Joerg notices that accounts are created quickly, it will also help him process them more regularly instead of reviewing AM reports by batches. FWIW Reviewing an AM report and an application is nothing near a small 5 minutes task. I believe it's rather 30 minutes of work per applicant if you do it seriously enough. Creating an account should though (meaning I don't know if it is, but I see no valid technical reasons for it not to be). Depending on the quality of the report (which doesnt mean quality of AM or NM, also amount of mails and quoting style the people use and stuff like that), its between 30 and 60 minutes. If one does a reject you can count at least 2 hours, as you then need to write a good reason for it. And that shouldn't be a small task, ever. -- bye, Joerg exa There is no point in trying to fix bugs if I won't have an account. Sorry. pgpuYo2uRTRBd.pgp Description: PGP signature
Re: Constitutional amendment: reduce the length of DPL election process
On 11099 March 1977, Holger Levsen wrote: Thank you for the 542th Seconded. on this proposal. We don't even need to vote any more :-) Seriously, could we have this change without voting? Sure, if everyone with a key in the current keyring, ie. including those MIA, sends a seconded (and annoys buxy with it), then, MAYBE, then, one could think about such a stunt. Otherwise its changing the constitution, so nice thought but not possible imo. -- bye Joerg GyrosGeier SCSI benötigt drei Terminierungen, eine am einen Ende, eine am anderen Ende, und das Leben einer Ziege über einer schwarzen Kerze pgpNOxPVQEHCa.pgp Description: PGP signature
Re: Constitutional amendment: reduce the length of DPL election process
On 11099 March 1977, Raphael Hertzog wrote: Seconded. Thank you for the 542th Seconded. on this proposal. We don't even need to vote any more :-) That said, once we reached the 5 DD who seconded (+2/3 more just to be sure in case of bad signatures), it doesn't bring much to send further seconds IMO. But they also don't hurt to have, and its nice to see lots of people agreeing to something. Ok, they may hurt the secretary, Manoj will have a fun time listing all of us seconders. :) -- bye Joerg cryogen gender is something i'll never really get either cryogen (hmm, that looks bad out of context) pgpHQoRDwHShm.pgp Description: PGP signature
Re: Constitutional amendment: reduce the length of DPL election process
On 11097 March 1977, Anthony Towns wrote:
=
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is None
Of The Above.
8. The Project Leader serves for one year from their election.
=
Seconded.
--
bye Joerg
[Kaffeemaschinen und Babies]
Funktioniert aber so ähnlich: Du füllst oben was rein und unten kommt's braun
raus...
-- Martin Würtele
pgpXga5fF7Fjd.pgp
Description: PGP signature
Re: The Debian Maintainers GR
On 11096 March 1977, Anthony Towns wrote: And there's the usual spin. Not everything's about who has power over whom, Joerg. At least try to have the courage to stand up in public for what you do in private. I dont have a problem with it being public. I have one with someone just making something public that was private *without even asking if its ok*. Huge difference. -- bye Joerg Free beer is something that I am never going to drink and free speech is something that people are never going to be allowed to. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The Debian Maintainers GR
Hi The following is basically what I wrote in my blog a few minutes ago, but IMO should also be on -vote, as thats the place where vote stuff is handled, and noone can expect people to read blogs or planet... The DM GR = So, let's join the postings about the currently running Debian maintainers GR. The short text of this post is _I am against the_ _proposal as it is right now and think it does more harm than good_ and so I did vote for Further Discussion. See below for a bit more about my reasoning, or just skip if you are already bored. :) The current proposal does look like a yay, we have an idea thats not really thought through. And we do not want to get it into the currently existing procedures, that would involve more work and discussions. And anyway, everyone is ranting about the current procedures anyway, so lets take that bad mood against it to get this done. (And yes, this is a bit exaggerated, so don't take it personal, please). As you may have noticed I wrote that I am against the current proposal when it first was on vote. I was mostly on vacation back then and didnt want to read the whole thread, so I stayed mostly quiet. I am not against the DM concept itself. I am against it being seperate to the existing NM procedure. For me a proper solution *has* to be integrated with the existing procedures, not seperated. The main reasons why some support this proposal seem to be 1. Slow NM process 2. Someone doesn't want to go through NM 3. Someone doesn't want to be in the Debian community Slow NM process --- I am part of this, and not a small one. And yes, I feel (very) bad about it, but already think about ways this can be changed, after I got the current backlog done. Anyway, for this DM thing my backlog isn't the main reason that people feel NM is slow. It seems to be the general I have to wait for an applicant and then answer to a lot of questions and between that wait and wait and wait. True. People have to wait at some points, and those waiting periods can be frustrating. We should do our best to eliminate those waiting places. The other point is that of the lot of questions. Yes, we have a really big set of questions in the templates, that cover a whole lot of the possibly areas a future Developer can work in. And most of those questions got added after a large set of existing Developers should that they completly do not know something. That way the templates are constantly growing and still intend to give the future Developers the possibility to learn about things in Debian they might never have heard about. And there is the thought that, if you read about a topic and had to answer to it in the past, you will at least remember that there is something if you encounter it in the future. *But* - there is also the fact that an AM is NOT forced to use the templates for their process. AMs are, and have always been, free to do the process on their own. There are some questions every AM *has* to ask, but thats a minority. If you look at the templates you will spot the needed ones easily. Other than those every AM can freely do whatever he wants to do with his applicant (as long as the applicant agrees to do that stuff and its legal :) ). The AM only has to keep the following in mind: Both, FrontDesk and DAM, usually do not work together with the applicant. They might have heard the applicants name at some point, in some bugreport or some packages Maintainer: field. But they usually did not interact with them. Which means that the AM has to make sure that FD and DAM are able to build up their opinion of the applicant *just by reading the mailbox of the AM-NM communication*. Which usually means: read between 20 - 70 mails of a communication someone else had before you decide if someone should or should not enter Debian. (Leaving alone checking packages.qa, lintian, bug lists and a bit of google). Someone doesn't want to go through NM - Erm. Well. Then use sponsors for your packages. Or is it because you think NM is too hard? NM isn't that hard, everyone that can read and write english texts (even if the english is bad) and use google *is* able to pass NM. (For the bad english - if you fear joining NM because of that: Well. If I go and reread my own report from back when I joined - ugh. I hate my english. And I know native people *still* hate my english texts, its named en_GANNEFF for a reason. :) It is not necessary for your English to be perfect; you only have to be able to make yourself understood. If an AM doesn't understand what you wrote they can simply ask for clarification). DM also doesn't help for people that don't want to pass NM. They have to pass the advocate, the ID check and the same minimum set of of questions NMs have (as written a bit above). So you already have a large part of NM for the future DMs. Someone doesn't want to be in the Debian community
Re: Debian Maintainers GR Proposal
On 11057 March 1977, Anthony Towns wrote: [ In case some of the stuff below is already answered in different mails - pointing me at them is enough. I just had no time to read all of them, way too large thread. :) Thanks. ] The Debian Project endorses the concept of Debian Maintainers with limited access, and resolves to I wonder what currently not existing problem this should solve. * that the applicant provides a valid gpg key, signed by a Debian developer (and preferably connected to the web of trust by multiple paths). * that at least one Debian developer (preferable more) is willing to advocate for the applicant's inclusion, in particular to the fact that the applicant is technically competent and good to work with. For NM there is also: If the NM *only* has a signature by the advocate, he needs to get one more at least. Where one more means global web of trust connection, not neccessarily DD. Ie NM foo with advocate bar, and only key sig is bar - get more sigs. All additions to the keyring will be publicly announced to the debian-project list. Yay, floods. * the Debian Account Managers have requested the individual's removal for any reason. joke Yay. No milk from him during last DebConf. I like this. :) /joke Im not sure that this helps. You still need sponsors, as you cant upload NEW packages. You even need them if you take over another package. So it doesnt replace the sponsoring system. IMO it would be better to try and find a good set of guidelines for DDs wanting to sponsor people, not trying to get more people able to upload stuff. What this also does is getting you out of touch with your (possible) sponsors, as now you let them upload once, advocate you, then you upload following versions yourself. A year later you have a new package and need to find a sponsor again, beginning from point zero. And also - how do you want to handle the case that someone might be in uploaders field of other packages already, because he is doing lots of work there and so co-maint, at the time of applying as DM? I mean, do you ask all other package maintainers if they would be ok with them possibly able to upload their packages now, without being a DD? Or is this a dont care, and if it happens lets remove their rights thing, waiting for a possible fuckup and acting on it then? -- bye Joerg mechanix anyone from the MIA team around? tbm? Ganneff sounds nice. how long do you have to be MIA to get into that team? :) mhp you need to have a pgp key, I suppose. and no gpg one, and only a bo box Np237 yes, but it must be expired pgp11dqD6tR6g.pgp Description: PGP signature
