Re: General Resolution: Declassification of debian-private list archives
On Wed, 30 Nov 2005, Debian Project Secretary wrote: Propose that the Debian project resolve that the process defined in the Proposal will be applied only for the future content of debian-private mailing list. I for myself see no real technical benefit in publishing the archive. So the ratio of use and effort (for those people who do the work) does not make any sense to me. So if there *really* are some DDs who volunteer to spend their time on old postings it is fine for me but because I think there are much more valuable tasks to do for the benefit of Debian I just will not vote intentionally. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Tue, 13 Mar 2007, Pierre Habouzit wrote: Well, I've read Frans post with a lot of interest, and it seemed to be a quite good rewording of Sam's platform :) Well, sure. Sam and Gustavo are at my favourite places. ;-)) Perhaps I should not have used an "if there would be any" if I know there are such people but I hoped others would give explicite statements about this issue. Thanks for the hint anyway Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Tue, 13 Mar 2007, Frans Pop wrote: [quoting http://lists.debian.org/debian-project/2007/03/msg00062.html ] ... IMO setting up an RT system will not fundamentally solve any of this, but will at most make it more manageable. The only way to solve this is by having new blood in the teams, people who will take on the most boring and routine tasks with enthusiasm because it is new and who bring fresh ideas and the energy to implement them to the teams. Amen. I seldomly read such precise and explicite words that describe the main problem in Debian. Each paragraph was well written and I just cuttet the quote short. If there would be a DPL candidate that would explicitely express the intend to make it his main task to change this situation I would rank him top most and everybody who ignores this problem will be ranked below "None of above". Kind regards Andreas. PS: No need for continuing cross posting debian-project and debian-vote but I wanted to make people aware of this very interesting posting on project. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
Hi, just a very ruogh idea (I never dived into the theory of voting) which IMHO sounds apropriate for our case. At first we need a set of volunteer candidates. Let's assume we have ten candidates for a team of seven people: A, B, ... J. Now let people do a negative selection and vota "against" candidates that they do not want into the set of people. Assume candidate C, I and H got most negative votes the other ones are elected. This could be a little bit harsh for C, I and H personally, but IMHO it is an apropriate way to easily select a team of equal people. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ideas about a GR to fix the DAM
2007/11/17, Anthony Towns <[EMAIL PROTECTED]>: > I don't think there's anything to be done until the technical things are > solved. Demonstrating that a DM keyring can be maintained by a team would > be helpful to show that the DD keyring can be maintained by a team, but we > haven't done that yet. I agree with you that making sure that technical means will really work is important before we start to tackle the social problem. > I don't think anyone else (outside of Debian) has > either. (As far as convincing James goes, jetring has the further problem > that it's a bunch of perl and shell scripts; and he's a dead-set python > addict these days -- but at least jetring's designed such that there's > nothing stopping us from writing a compatible replacement in python) I completely disagree that the personal preference of a programming language should dictate the technical means we should choose. I'm really happy that James does not prefer say PL/I and we would be forced to clone an existing software in this or any other language. > > 1. James doesn't feel he is a delegate, because he predates the > > constitution (it awfully sounds like a ???the rules convenientely > > only apply to others??? btw). This is just strange. Is there any quote or evidence for such kind of thinking? > The real problem is that James actually has good reasons for why a lot > of proposals for fixing things won't actually work well. If he didn't > have a history of sound judgement, it'd be really easy to just ignore > whatever he thought and do something different. There is no doubt that James has a profound judgement. The question is whether there is nobody besides James who is able to judge similarly and even if so why James does nothing against this situation and shares his knowledge. > You can improve things by: > > - making things more fun and rewarding (so people are more inclined > to dedicate more time) > > - making things easier (so each person can do more things) Full ACK. > - having more people able to do each thing (eg, more DAMs, > or making it easier for multiple AMs or other DDs to help an > individual applicant progress) Isn't this the point of this thread? Isn't the reason why this is not implemented for several years clearly detected? > In any event, getting angry about it has certainly been tried lots of > times before, I don't think it's achieved much improvement to date. Right, just getting angry does not solve anything. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ideas about a GR to fix the DAM
2007/11/19, Anthony Towns <[EMAIL PROTECTED]>: > On Sun, Nov 18, 2007 at 11:16:59PM +0100, Andreas Tille wrote: > > I completely disagree that the personal preference of a programming > > language should dictate the technical means we should choose. I'm > > really happy that James does not prefer say PL/I and we would be forced > > to clone an existing software in this or any other language. > > Well, I'm really happy that you can't write something in PL/I and force > me to use it to do my work, too. It goes both ways. Wrong. We are talking not about _you_ or a single person, but a group that should use and continue development. I see no reason why this group should adopt to the programming habits of a single person. It sounds like we are to much used to the idea that there is a chair that is occupied by a single person. If there are existing tools that might solve a problem we should not ask the person that is sitting on a specific chair whether he likes the programming language the tool is written in. If the wool works and we are perfectly able to form a group that has one or two members that are competent in this programming language it is perfectly the way we should go. > I don't see the point in rewriting jetring in python (or doing anything to > convince James he should be using) at the moment, because I think it needs > to be tested in a more controlled situation first. Compared to testing > and proving the concept, though, a rewrite in python seems less effort > than arguing about it. Sure. But have you ever met a "normal" person that thinks programming geeks are a very strange flavour of mankind because they tend to replace working thing A by another thing B doing the same job just because they do not like the programming language of A. I'm afraid those "normal" people have a point. > Though of course, I'm personally a bit biassed > towards trusting python programs more than mixtures of bash and perl, too. If there wouldn't be a solution I would start with Python. If there is a working solution that would fit my needs I would use it. > You've seen my comments on this, and presumably my references to mails > about James views (both my explanation [0] and his [1]). Doesn't that already > show that there're others besides James who judge similarly, and that > James has shared his knowledge? > > [0] http://lists.debian.org/debian-project/2007/02/msg00204.html > [1] http://lists.debian.org/debian-project/2007/02/msg00226.html Well, this [1] is quite exactly to years old and says: I think in the long term, keyring maintenance should obviously be done by more than one person. and thus raises the question in what scale "long term" is meant. The continuos discussion shows that a status report every second year might be a nice thing to have to keep fellow developers who deserve a certain level of information up to date. > > > - having more people able to do each thing (eg, more DAMs, > > > or making it easier for multiple AMs or other DDs to help an > > > individual applicant progress) > > Isn't this the point of this thread? Isn't the reason why this is not > > implemented for several years clearly detected? > > AFAICS it seems much more about expanding the powers and > responsibilities of one individual than distributing them amongst > multiple individuals. That comes under "removing dependencies" or > "making it easier", not adding more people. I admit I do not understand this deduction. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ideas about a GR to fix the DAM
2007/11/20, Anthony Towns <[EMAIL PROTECTED]>: > No, I _am_ really happy that you can't write something in PL/I and force me > to use it. Trust me on this. Well, I trust you on this. ;-) (BTW, PL/I is not bad - it was my first programming language and had some nice features.) What is wrong is the assumption that there is any sense in expecting a group of people following the prefered programming language of a single person to replace a tool that has the single drawback to not fit the preference of this person. So if I not even can force you as a single person to use my prefered programming language how can you think that another person could force other free software developers to do so? > We might be able to form a group and create a tool with such properties, > but it will take time. It takes longer if people sit around complaining > about how it's someone else's responsibility to take the initiative. It > isn't as good if you refuse to take the opinions and concerns of > experienced and knowledgable people into acount. Here we go again: Isn't this the canonical hen - egg - problem of Debian authorities? > I'm a pretty experienced programmer, and personally I value my own > opinion of whether a rewrite is worthwhile or not over someone who's > more normal merely because they're a less experienced programmer. > > You don't solve social problems by refusing to make reasonable compromises. > Having the software be written in a way that's comprehensible and able to > be modified to suit the needs of the people who are going to use it seems > emminently reasonable to me. Well, people sounds like plural to me. Wasn't you arguing to rewrite something to fit a single persons preference? This and only this is my point. Other people anounced to accept the existing tool in the language it was written in. > I suspect you can get a hint from: Well, communication is not about fetching hints but stating clearly what is going on. > > The > > continuos discussion shows that a status report every second year might > > Status reports like, say: > > http://lists.debian.org/debian-devel-announce/2006/12/msg00010.html > http://lists.debian.org/debian-devel-announce/2007/03/msg00018.html > > ? Yes, these reports are fine and we are happy about them. Unfortunately they do not cover the topic of turning single person tasks into team tasks and this is what we are talking about here. (Or did I missed something?) > ... > Does that make the deduction more understandable? Thanks for the clarification. Even if I'm not happy with this situation I probably have to accept it for the moment. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ideas about a GR to fix the DAM
2007/11/21, Steve Langasek <[EMAIL PROTECTED]>: > Your message has inspired me. I'm sending this email to let you know that, > since I see an open bug on the fortunes-de package, it's my conclusion that > you need more help maintaining it, so Adam Conrad and I are working on an > updated version that we will upload when it's ready. BTW, the packaging > will be redone using "tada", a reimplementation of yada in tcl which already > solves this particular bug. I don't imagine you'll have any problems with > this choice since it's a perfectly good tool, but even if you do you're only > a single person and there are two of us, so we're going to do it anyway, so > your choices are to use it as a comaintainer or to step down and let us do > what we want without you. :) Great. Would you ask for an alioth project where we can check in those changes. I'm not that keen on fortunes-de that I would not happily share the "workload". Well, even if your example is not really catchy I've got the idea. But I admit I'm not convinced. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2024: Call for nominations
Hi, Am Fri, Mar 08, 2024 at 09:24:15PM +0100 schrieb Debian Project Secretary - Kurt Roeckx: > The new project leader term starts on 2024-04-21. The time line > looks like: > > | Period | Start | End | > |+-+---| > | Nomination | Saturday 2024-03-09 | Friday 2024-03-15 | I'd like to nominate myself to serve the Debian community as DPL for one year. Kind regards Andreas. -- http://fam-tille.de signature.asc Description: PGP signature
Re: Candidates question: politics and Debian
Hi Thomas, Am Sun, Mar 10, 2024 at 05:36:57PM +0200 schrieb Thomas Koch: > A question to DPL candidates > > It seems (to me?) that more and more areas of our lives become political and > controversies on such topics more aggressive. Or people stop talking with > each other. I share this observation. > How would you as a DPL try to lead a community that focuses on producing a > great distribution without getting divided on controversial topics? I'm not really sure in how far you consider the first statement relevant to the question. If your focus is on political controverses I have a clear statement: Make sure off-topic messages will be reduced to a bare minimum on Debian channels (maximum is one message to invite people to a non-Debian channel and mark this invitation [OT]). If the discussion about technical topics that are relevant for Debian might become controversal this is no problem as long as participants of the discussion are following our Code of Conduct[1]. This is something we once agreed upon and I consider it very important. > (I hope it's not violating rules to pre-post a question before the campaign > period?) Just answering after the campaign period started. Kind regards Andreas. [1] https://www.debian.org/code_of_conduct -- http://fam-tille.de
Re: Candidates question: politics and Debian
Hi Gerardo, Am Tue, Mar 19, 2024 at 09:38:26AM +0100 schrieb Gerardo Ballabio: > Andreas Tille wrote: > > > How would you as a DPL try to lead a community that focuses on producing > > > a great distribution without getting divided on controversial topics? > > > > I'm not really sure in how far you consider the first statement relevant > > to the question. If your focus is on political controverses I have a > > clear statement: Make sure off-topic messages will be reduced to a > > bare minimum on Debian channels (maximum is one message to invite people > > to a non-Debian channel and mark this invitation [OT]). > > Limiting off-topic posts is obviously agreeable, but there's more than > just that. > > Another facet of the question is: do you think that Debian should > support and/or take action on "good causes" that aren't part of its > stated mission (and that some people, including some DDs, might > disagree on being "good")? > > For example (by no means an exhaustive list, feel free to add): > - should Debian aim to reduce its carbon footprint and/or optimize > software for that goal? If this question is whether we should target for less power consumption I consider this topic as perfectly non-controversal and part of our mission statement. I can't imagine any user wants to spent more money on energy to run a Debian system or might be happy about seeking for the next power plug to recharge the laptop battery. Probably also people who do not believe in the need to reduce the carbon footprint will be interested in less energy consumption and I consider this as part of our mission statement. > - should Debian support and/or actively drive initiatives to increase > diversity in Debian Developers, or in the software industry in > general, or in the world at large? I hope my platform was clear enough that I'm in favour of increasing the diversity in Debian. This is not off-topic inside Debian. Regarding the software industry in general or the world at large I think Debian is not the right association to target these goals. Its a great thing if Debian contributors are working on this and I will applause this on a personal level. But this is nothing I consider my task as DPL nor do I think we should discuss this topic on Debian channels. As I tried to express: Pointing to some outside channel in some message marked OT to inform people is OK. > - should Debian take any measures (boycott, suspend or expel > developers, refuse to consider as a host for Debconf...) against > countries that are perceived by some as "behaving bad" -- as examples > related to current events let me just mention Russia and Israel? We are an international project and I do not think that any contributor can be blamed about the country of origin. Please be more verbose if my answer is not sufficient for your question. Since you mentioned DebConf: The DebConf team has to care for the safety of all attendees. I trust their experience in running a DebConf in drawing the correct decision regarding this. I can warmly recommend to join the DebConf team to get involved into the discussion about this. > - (this is an issue that once hit me personally) should Debian enforce > the use of a particular language with respect to gender issues? I consider our Code of Conduct as sensibly and sufficiently worded. Our language should be kind and respectful. I do not consider these attributes as "particular language". Kind regards Andreas. [1] https://www.debian.org/code_of_conduct -- http://fam-tille.de
Environment friendlyness, diversity (Was: Candidates question: politics and Debian)
Hi Paulo, I'm changing the subject to match the content of your question. Am Tue, Mar 19, 2024 at 04:01:12PM -0300 schrieb Paulo Henrique de Lima Santana: > In your page, you wrote: > > "I would encourage everyone to minimize air travel whenever possible. > Fortunately, I've noticed a tendency among Debian community members to > prefer land travel over flights anyway." > > How about travels between continents, and traveks in regions/continents > without the same train network you have there in Europe? First of all you might like to watch the video from last DebConf[1]. The statements I gave inside the discussion has not changed. I'm perfectly aware that flying is not good and we should avoid it. My personal experience is that flying for some "sensible purpose" is hard to evaluate. Just to give a private example: My flights to Vietnam (+ some luck and DebConf15 in Heidelberg) have finally led to the situation, that I have two adopted daughters from Vietnam who are living now in my house. One of my daughters joined me in my effort to plant trees[2]. How do want to calculate the total CO2 footprint from flights compared to the trees that are planted here? This example is totally unrelated to my DPL statement but should demonstrate the problem: The somehow calculable CO2 consumption per seat in a plane can be wrong with quite some error. My current travel plan to DebConf24 is: 1. Find a single flight that connects Germany with South Korea 2. Find train connections a) from my hometown to the airport in Germany (which is definitely not the nearest one) b) from Incheon (Seoul) to Busan (4-5 hour train ride) That way I replace two local flights by train rides and I would like to encourage people to do so. I have a personal no flights in Europe policy and I'm sure that my position as DPL does not include telling anyone how to travel. I just want to express what kind of flights I consider acceptable for me and how you can interpret my statement in my platform. > > I hope my platform was clear enough that I'm in favour of increasing the > > diversity in Debian. > > I read you page yesterday but I would like to know what ideias do you have > to increase gender representation and geographic diversity? > > I'm sure everybody is in favor to increase diversity, but what can be done > in practice? First of all I consider a kind and inviting environment important in any case. I tried to answer what else can be done in the paragraph "Tiny tasks". In my discussions with some women I know from DebConfs I learned that it might be helpful to define tasks that are requiring small slices of time. I referenced this in the paragraph "Lower barriers" with: For instance, I've encountered the argument that in many cultures, women have less leisure time ... You might check that I'm honest about this by verifying my DPL platform git inside the tools dir[3] where I'm currently developing some (not yet finished) scripts) to get-missing-tests and get-random-bug. Depending from the time my DPL tasks might leave me (which I really can't estimate) I would like to guide newcomers kindly to do some dedicated QA work inside Debian and by doing so have some look into "hidden corners". Its just an experiment where I'm personally keen to see what outcome this might have. I'm continuously in close contact with some women in Debian (including Sruthi) who I met at several DebConfs . I highly evaluate their opinion and trust their insight. To come back to the traveling topic above: I would not have met those women without flying to DebConfs. Any further ideas are highly appreciated. Kind regards Andreas. [1] https://debconf23.debconf.org/talks/80-face-to-face-debian-meetings-in-a-climate-crisis/ [2] https://fam-tille.de/baeume_pflanzen/ German only, but life translation will work. [3] https://salsa.debian.org/tille/dpl-platform/-/tree/master/tools?ref_type=heads -- https://fam-tille.de
Re: Question to candidates: How do you plan to manage finances/accounting?
Hi Nilesh, Am Fri, Mar 22, 2024 at 09:23:12AM +0530 schrieb Nilesh Patra: > I am interested in knowing about what the current candidates think about > accounting bits in Debian and how they think about spending the money. I admit my knowledge about how Debian money is spent is currently low and incomplete. Here is a list of things I know / have heard about: 1. DebConf (and MiniDebConfs) In my perception the money usage for DebConf is transparet enough I have no idea about MiniDebConfs. 2. Smaller in person meetings (Bug squashing parties, team sprints) Sprint organisers have to estimate their budget and need confirmation. Confirmed budget is payed. I have no idea whether those data are published somewhere. 3. Infrasturture hardware I was always happy to see that it worked from my mere developer point of view and did not read the reports about this but I know there are some reports. 4. Hardware for developers I once profited from a Debian sponsored laptop in exchange for some review[1]. I know that other DDs also got hardware which is for different reasons interesing to make sure Debian runs properly. I have no idea whether there is some list about this (in terms of transparent usage of the money) 5. There is probably way more missing in this list. > As I have read and from time to time observed, the finances in the project > do not have a lot of transparency and there are updates posted > semi-occasionally > on -private and sometimes in DPL talks. Jonathan also wrote about it in one > of their > previous campaigns. I would love to be transparent about money. Currently I have no idea how time consuming this process compared to DPL tasks in general might be. I'd love to get help here which is also a way to increase transparency if more eyes are looking onto this topic. > Itd also be good to know if there's a plan on where the budget > shall be best spent. I have no idea how to measure "best" usage objectively. I strongly believe that in person meetings are very important so I consider the money for item 1. and 2. of my list above spent well and would encourage people to organise those events which should be supported by Debian money. Its probably without question that we need good infrastructure hardware. If bottlenecks might be spotted which can be fixed quickly with existing money I'm all for it. > I would like to know if the candidates for this term have any plans about it > or any thoughts > in general. In general I think that people donating money to Debian expect their money to be spent for the progress of Debian (rather than filling up our bank account[2]). I'm also open to exploring new ways to allocate funds. I'm hopeful that we can derive some positive insights from the Debian Developer's Survey on the Usage of Money in Debian[3]. Personally, I'm open to discussing whether to compensate contributors for important tasks that either nobody wants to do or lacks people with sufficient time capacity to undertake those tasks. I recall the various pros and cons raised during past discussions on this matter, but if people believe it's time to initiate a fresh discussion, I'm very receptive to that. BTW, I don't believe that only the DPL can initiate such a discussion. But for sure I'm very open for suggestions and will support any initiative to make Debian better. As a very personal note what I think about money: In my eyes money has a great power to divide people. Discussion about it is usually heated and it is hard to find a good consensus due to very different perspectives onto that matter specifically since there is hardly a technical proof what is right and what is wrong. This makes a great difference to other decisions we have to draw inside Debian. > Both of your platforms have only a (very) vague idea about it and I'd like to > know more > specifics about it. If you want to know more details please be more specific in your question. > PS: I urge _only_ the candidates to reply to this mail 😀 I'm personally interested into specific proposal how people consider money well spent and might answer these in different treads (since Nilesh wants only replies from candidates). > Best, > Nilesh Kind regards Andreas. [1] https://fam-tille.de/debian/frame.work.html [2] https://www.theregister.com/2020/09/10/debian_project_address/ [3] https://lists.debian.org/debian-devel-announce/2023/04/msg1.html -- https://fam-tille.de
Re: Question to candidates: new legal entity for Debian worldwide
Hi Joost, Am Fri, Mar 22, 2024 at 06:51:48AM +0100 schrieb Joost van Baal-Ilić: > There has been discussion of having one new legal entity representing > the Debian project worldwide. What are the candidates opinions on that? Could you please add some pointers to recent discussions about this. I've found some 20 year old thread[1]. Our constitution says: SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. I've also found some discussion about the legal entity of DebConf in past years[3]. My guess is you are not refering to any of those points. Any pointers to recent discussion are welcome. I'm aware about the EU legislation regarding Cyber Resilience Act, Product Liability Directive and CSAM Regulation but I have no idea whether our answer should be becoming a legal entity. Its as always in Debian: We are a Do-o-cracy. The person who does the job can decide what gets done. Those who really strongly believe that a legal entity is the answer to major problems in Debian might run this effort, find consensus to run a GR changing the consitution - whatever seems to be necessary. If we do not find competent volunteers this will not happen. Personally I decided to become a physicst and not a lawyer since I consider the laws of physics simple, easy to describe and perfectly able to verify in practice. This is all very distinct to the laws we have given ourself in society and I'm no expert in the latter. Thus I simply feel not comfortable in giving statements about things I do not full understand. I personally see and (hopefully) understand lots of technical problems which I would like to tackle. Since the time I can dedicate to the job is not unlimited I will decide to do things I feel competent and thus more efficient. I will not stop others solving additional problems and if those people manage to convince me that it is important for Debian I might support this. Kind regards Andreas. [1] https://lists.debian.org/debian-devel/2004/12/msg00647.html [2] https://www.debian.org/devel/constitution.en.html#item-9 [3] https://lists.debian.org/debian-project/2014/04/msg00070.html > PS: I am eagerly awaiting a platform from > Sruthi Chandran . Up to now there still is the old one at > https://www.debian.org/vote/2021/platforms/srud . https://www.debian.org/vote/2024/platforms/srud -- https://fam-tille.de
Re: Question to candidates: How much available time would you have for DPL work?
Hi Nilesh, Am Fri, Mar 22, 2024 at 03:47:08PM +0530 schrieb Nilesh Patra: > I have worked with both Andreas and Sruthi in some capacity in different teams I'm hereby use the chance to thank you again for your great work increasing my personal time for other things quite a lot. ;-) > so I have some idea about about the turn-around time for both (usually quick). > > In Debian, responding to something in around a week is normal (anf good), > however, some > DPL tasks would likely come out as urgent+important and would require > you to revert within 24h. Usually I should be able to respond in 24h. However, my plan is to delay important DPL statements *intentionally* to 1. Consult trusted and experienced DDs about the topic 2. Sleep over it > How effectively do you think you'd manage something like this? I can't seriously answer this question in advance. > Do you also intend to change something w/ respect to the current time you're > spending > on Debian? I plan a massive change in my Debian work to shift from uploading and bug fixing to DPL tasks. > Do you intend to re-org the time you spend into technical work (for andreas) I have informed the attendees of Debian Med sprint *before* I even was drafting my platform. I'm observing some increased dedication inside the team and I'm as well happy as thankful for this. I wrote some e-mail to Debian R team[1]. I admit I consider the R-pkg team as non-functional since I'm de-facto the only uploader[2] (since Dirk E. does not consider himself a team member and his uploads are not the team maintained packages). I'm concerned about the fact that there is very low response to my mail. We definitely need some contributor who takes over routine-uploads to keep the R stack up to date. > or outreach/community/AM team activity (for srud) into DPL tasks? To be honest: This is a question I had to myself several times and I really hope that my answer is not to strongly in contrast to reality. Kind regards Andreas. [1] https://lists.debian.org/debian-r/2024/03/msg0.html [2] http://blends.debian.net/liststats/uploaders_r-pkg.png -- https://fam-tille.de
Re: Question to candidates: Addressing Bandwidth Challenges in Debian
Hi Nilesh, Am Tue, Mar 26, 2024 at 12:26:00AM +0530 schrieb Nilesh Patra: > It is no secret that most (probably all?) teams (delegated and otherwise > packaging/developer teams) in Debian struggle with limited > developer time and almost everything in Debian needs help. > In quite a few teams that I've seen and also been a part of, there > are only 3-4 people sharing a bulk of workload, sometimes > it is even worse and there are 1-person teams too -- teammetrics stats > can shed some light on it[1]. Thanks for refering to teammetrics which is one of my pet projects on one hand and an example for the problem on the other hand since I'm more or less running it alone. In contrast to other more important 1-person teams this is not a cruxial one, luckily. It also does not cut much from my time since I don't to some development work in it - just keep up and running what was done in a GSoC project. > This imbalance can lead to exhaustion, burnouts, et. al. and having > a low bus factor also poses an issue for stale packages/development > in the corresponding teams when the people doing a lot of work > there become busy with RL and can't dedicate much time. I addressed this in paragraph "Building redundancy" of my platform (but avoided the term "bus factor" using other known reasons for leaving the project). > Do you have any plans to address this or any strategies so the workload > could be somewhat better managed making this sustainable? I will try my best since I consider this a cruxial problem in Debian. I personally see one tasks of the DPL to spot tasks in Debian that are not sustainable in the sense you wrote and I'm happy about hints. My first step would be to talk to those 1-person "teams". But the issue might be complex and might be even caused by the volunteer based organisation of Debian. Let me give two personal examples (none affecting really critical things inside Debian). Positive example: I'm extremely happy that the Debian Med team is showing increased acticity by other team members after I nominated myself for DPL. I consider this as great fruits of our cooperative work to form a healthy team over 22 years and I'm really happy about this. Regarding the 1-person teams I think step zero is that the single team member admits that there is a problem. Example: Unfortunately in R pkg team where I'm doing the vast amount of work this did not worked. My mail where I admited to have no time[2] has lead to two further confirmations of time constraints. But I think at least step zero is done. (Advertising: Maintaining R packages is in most cases very easy. The process to upgrade packages as well as to package dependencies is de facto automated. If you are using R please join the team.) In general I believe that a DPL is limited in effectiveness if people don't to that step zero. It seems that within Debian, there are individuals with exceptional technical skills who may also experience a syndrome where they feel they are the sole individuals capable to do certain tasks. This might make step one even harder: Document what you are doing, seeking actively for more team members and teach them kindly. This step is time-consuming, especially for individuals with significant time constraints. Investing time without a clear vision of success poses a challenge - ensuring that the new team member can effectively handle the pending tasks while also committing to the role for a long time to make it really sustainable. I have no good ideas how to solve this dilemma inside our volunteer organisation. I know that Freexian is paying people for LTS support. This is nice. For the Etch release we had quite a discussion about paying release managers. I know lots of pros and cons about paying people from Debian funds. I think it is better if we could convince companies to pay Debian developers and permit them to use their payed time to spent on Debian tasks than paying single persons from Debian funds. To give some example: The 32bit time_t 64bit transition is done to support special hardware applications. Companies who are depending from ARM 32bit support could hire people who care for ARM 32 ports inside Debian. I consider this some win-win-situation. It might be worth trying to browse the list "Who is using Debian"[3] to explain those companies or the list of sponsors of DebConf, tell them about issues we could fix if they would hire someone with the dedicated job to work on this problem inside Debian. BTW, I see jobs in Debian which are not tackled at all (=0-person teams?). There could be somehow a team that works actively to speed up Debian trends (thanks a lot to Lucas Nussbaum for maintaining this[4]) and work down the list of "code smells". I did so from time to time and found: 1. Packages that show no visible sign of maintenance in need of beeing salvaged[5] 2. Unattended but easy to fix bugs 3. Packages that could/should be probably be removed without harm bu
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi Thomas, Am Wed, Mar 27, 2024 at 12:24:30AM +0100 schrieb Thomas Goirand: > As you know, there's a large amount of money sleeping in SPI account for > Debian. Do you have ideas on how to spend it? While I admit that I'm not well informed about the status of the acount currently I'm perfectly open to interesting suggestsions. In general I think donators want to see their money spent for the progress of Debian and not for filling up some bank account. > Would you be ok spending 100k USD on buying hardware for a new Debian cloud, > for example? I've always volunteered to operate it for Debian, but it never > went through, because I haven't spent time to find where to host it and so > on, but highvoltage liked the idea. Do you like this idea? Do you think it'd > be useful for Debian? While I personally have no use case for this I'm perfectly open for spending money on this and love to discuss this either on debian-project or debian-private (if private discussion seems to be appropriate). However, I see an important requirement to consider this money well spent: We need a team who cares for the maintenance of this cloud. I do not think that we can simply add to the workload of DSA. And I want it to be a real team and not a 1-person team. > Also, I found very annoying that we don't have enough buildd, or that the > reproducible build project doesn't have as much hardware as they would like. > Would it be ok to spend another 100k USD for this kind of things? I'd happily spent money on infrastructure we really need which includes buildd and reproducible builds. I'm also fine with stregthening Debci and Salsa CI if needed. But also here the question is: Just permitting the usage of money is one thing. We also need people to do the actual grunt work of buying, installing and maintaining the hardware. If this is granted I'm perfectly fine with it. > For some packages of mine, the current shared runners are too slow to even > run time-based tests of openvswitch for example... What about the Salsa CI? As I mentioned above I'm happy to make Salsa CI more performant. > Couldn't we pay some cloud providers to have faster shared runners? It > wouldn't be hard to hook them. Paying some cloud providers to host shared runners for us might be one answer to my requirement that there are actual people who care and not only money thrown at some hardware. It needs to be well thought / discussed what services can be delegated to some cloud providers and what needs to be Debian hosted. For Salsa CI I do not see any constraints since its just building publicly accessible code. Kind regards Andreas. -- https://fam-tille.de
Re: Question to candidates: what are your quantitative diversity goals and metrics?
Hi Roberto, Am Wed, Mar 27, 2024 at 08:26:06PM -0400 schrieb Roberto C. Sánchez: > QUESTION TO THE CANDIDATES: what are your quantitative diversity goals > and metrics, and what are the rationales behind those goals and metrics? > > Some context: > ... > In the last GR there were 1004 voting DDs. Based on those figures, a > geographically representative population of DDs would include 175 DDs > from China, 175 DDs from India, and 42 DDs from the United States (and > so on down the line). Nice visualisation of the problem. > a very slight bias towards more males) [1], with "transgender people and > other gender minorities, who comprise an estimated 0.3–0.5% (25 million) > of the global population" [2]. Using the above figure of 1004 DDs, a > balanced Debian population could be 500 male DDs, 499 female DDs, and 5 > DDs who identify as transgender or another gender minority. Based on Same here. > Again, these are merely examples. I am interested in how you define > diversity and what metrics and goals you derive from that definition. We are all aware of the issue you are eloquently illustrating. I will not make false promises and give any metrics I intend to reach as DPL. The reason behind the current metrics are well known problems in our world. As DPL I do not have the power to make the world a better place. The DPL task is making Debian a better place for discriminated people and I love to work together with Sruthi on this - no matter who will be elected. Kind regards Andreas. -- https://fam-tille.de
Re: Question to candidates: what are your quantitative diversity goals and metrics?
Hi Robert, Am Thu, Mar 28, 2024 at 07:30:51AM -0400 schrieb Roberto C. Sánchez: > ... > In any event, rather than infer what you might believe, I thought it > more respectful and helpful to ask you give some insight into how you > shaped your view so that those who consider voting for you might > understand how you would like to reshape the Debian project. Since you are repeatedly asking for measures I might like to add that I'm very keen on giving *everybody* a fair chance to contribute. Our platform for contribution is Salsa. One of my measures is how many packages are maintained on this platform. I sometimes make UDD queries like: udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike '%Roberto%anch%' or uploaders ilike '%Roberto%anch%') and (vcs_url not like '%salsa%' or vcs_url is null) order by source; source | maintainer |uploaders | vcs_browser +--+-+--- bmagic | Athena Capital Research | Roberto C. Sanchez | cpuset | Roberto C. Sanchez | | libmongocrypt | Mongo C Driver Team | Kevin Albertson , Roberto C. Sanchez , Kyle Kloberdanz | luabind| Roberto C. Sanchez | | mongo-c-driver | Mongo C Driver Team | Kevin Albertson , Roberto C. Sanchez , Kyle Kloberdanz | https://github.com/mongodb/mongo-c-driver/tree/master mysql++| Athena Capital Research | Roberto C. Sanchez | quickfix | Athena Capital Research | Roberto C. Sanchez | sparsehash | Athena Capital Research | Roberto C. Sanchez | (8 rows) While you have other packages maintaines on Salsa udd=> SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and (maintainer ilike '%Roberto%anch%' or uploaders ilike '%Roberto%anch%') and vcs_url like '%salsa%' ; count --- 10 (1 row) BTW, thanks for maintaining 18 packages in Debian and thanks even more for having the majority on Salsa. However, I'm honestly curious about the motivations behind your decision to not use Salsa regarding the apparent lack of opportunity for broader contributions to the packages you are maintaining. You are by far not the only maintainer in this aspect but I'm interested in specific reasons of people who care about an open environment. I'm particularly interested in hearing your perspective on this matter, especially in light of my own proposal outlined in the "Lower Barriers" section of my platform. So if you want one metric I'm keen on then it might be this one: udd=> SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url like '%salsa%' ; 33703 udd=> SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ; 2368 I would like to push the latter number below 2000. You can help me in doing so in 8 cases if you agree with me that it helps newcomers to have a common platform for development on Debian. Kind regards Andreas. -- https://fam-tille.de
Re: Question to candidates: what are your quantitative diversity goals and metrics?
Hi Salvo, Am Fri, Mar 29, 2024 at 09:49:24AM +0100 schrieb Salvo Tomaselli: > 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. > > It used to be sourceforge, galileo from my university (salsa didn't even > exist > then), google code, github and lately I'm slowly moving everything to > codeberg. I admit this is some valid reason. Looking at udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike '%Tomaselli%' or uploaders ilike '%Tomaselli%') order by source; source| maintainer | uploaders |vcs_browser -++---+ album | Salvo 'LtWorf' Tomaselli| | https://salsa.debian.org/debian/album album-data | Salvo 'LtWorf' Tomaselli| | https://salsa.debian.org/debian/album-data explosive-c4| Salvo 'LtWorf' Tomaselli| | https://codeberg.org/ltworf/explosive-c4 fortunes-it | Salvo 'LtWorf' Tomaselli| | kasts | Salvo 'LtWorf' Tomaselli| | https://salsa.debian.org/debian/kasts localslackirc | Salvo 'LtWorf' Tomaselli| | https://github.com/ltworf/localslackirc parolottero | Salvo 'LtWorf' Tomaselli | | https://github.com/ltworf/parolottero python-netsnmpagent | Salvo 'LtWorf' Tomaselli| | python-xtermcolor | Salvo 'LtWorf' Tomaselli | | relational | Salvo 'LtWorf' Tomaselli | | trabucco| Salvo 'LtWorf' Tomaselli | | typedload | Salvo 'LtWorf' Tomaselli| | https://github.com/ltworf/typedload vasttrafik-cli | Salvo 'LtWorf' Tomaselli| | https://codeberg.org/ltworf/vasttrafik-cli weborf | Salvo 'LtWorf' Tomaselli | | xinetd | Salvo 'LtWorf' Tomaselli | | https://salsa.debian.org/debian/xinetd (15 rows) I seee you maintain 4 packages on Salsa (great!), 5 packages for the said reasons somewhere else and 6 packages do not contain any vcs_url. Do you have a plan to lower the entry barrier for the latter 6? Kind regards Andreas. -- https://fam-tille.de
Re: Question to candidates: what are your quantitative diversity goals and metrics?
Hi Louis-Philippe, Am Fri, Mar 29, 2024 at 02:41:44PM -0400 schrieb Louis-Philippe Véronneau: > We're getting a little sidetracked here, but that's not the case: While its sidetracked from the original question I'm happy that this came up here and I learned two good arguments (from Russ and yours) for using Salsa. Kind regards Andreas. > "4. What can be hosted on salsa? > > The answer is simple: As long as it is opensource and/or can be included in > Debian, it is fine to use salsa. If in doubt, ask. " [1] > > [1]: https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau > ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org > ⠈⠳⣄ > -- https://fam-tille.de
Re: Question to candidates: what are your quantitative diversity goals and metrics?
Hi Soren, Am Fri, Mar 29, 2024 at 01:00:36PM -0700 schrieb Soren Stoutner: > Personally, I am one of only two Debian Developers that I know of living in > Arizona. So, from a local geographic diversity perspective, I would like to > see a few more Debian Developers that I could meet up with face-to-face. In > that regard, I am actively trying to recruit people I know to get involved in > Debian. Those efforts can take a while to play out, but I would hope that > over > the next 2-3 years I can recruit at least 1-2 people and mentor them through > the process of becoming Debian Developers. If the question is that specific I can give some clear answer: I'd support forming a local group by taking over travel expenses for some in person meeting. I do not think that a DPL platform (which in my case was considered lengthy by some people) has room for listing those kind of specific details. > Separate from efforts to recruit Debian Developers in general, I am a self- > employed small business owner. Currently, I do not have any employees > besides > myself. However, if current plans materialize, I would hope to add a few > employees over the next couple of years. When that happens, part of my > employment contract would be that I would like them to dedicate up to 5 hours > of paid company time per week to work on any part of Debian that interests > them. The hope would be that they would eventually become Debian Developers > and that they would continue their association with Debian even if they left > my company’s employ. Very cool plan. I love to read it and wish you good luck in it. > This second part relates more to the discussion about recruiting more people > to Debian in general (as opposed to any specific diversity goal) as well as > the > discussion about paid contributions to Debian and trying to get companies to > sponsor employee time working on Debian. Interestingly, this issue may be more relevant than you assume. At DebConf15, Margerita Manterola shed light on pertinent statistics, revealing that the representation of women in Free Software lags behind that of the broader IT industry. Within Debian specifically, this gender gap is even more pronounced compared to the already underrepresented status within the Free Software community at large. While I don't know current figures, the prospect of recruiting individuals with a predisposition towards inclusivity from the wider IT sector could potentially bolster the presence of non-male developers within Debian. Moreover as you said yourself your plan sounds pretty effective to work on the discrimination of people in Arizona. > Returning to the Roberto’s question, as both candidates have made this a part > of their platform, I would hope that they could make a simple statement along > the lines of, “These are the specific groups I see underrepresented in Debian > (perhaps even with some specific numbers about how underrepresented they are) > and these are the specific things I would like to do to improve their > representation (perhaps with some specific metrics as to what they think can > be > accomplished during their term as the DPL).” I can not give any metrics and I see no reason in spending my time on exact numbers. IMHO the paragraph "Diversity" of my platform is out of question. > I do understand that maybe their > statement looks more like, “These are the specific groups I see > underrepresented. I don’t have any idea of how to fix that, Please read my platform again which contains phrases like "As a potential solution, we might ..." > but I think it is > important and as the DPL I would be open to any ideas from members of the > project and would be committed to investing time and appropriate resources to > implementing any good ideas that surface from those suggestions.” You surely have read my sentence "I am committed to facilitating discussions with knowledgeable experts, to actively seek solutions to these challenges." at the very end was misinterpreted by you as refering to the previous paragraph but I consider this a general statement also regarding to diversity problems. IMHO my platform contains the things you are asking for. > I don’t think the DPL has to have all the answers going it. Definitely and I do not pretend to have answers for all questions. > But I would hope > that Roberto’s excellent question and his consistency in noting that it > hasn’t > yet been answered, would be helpful in directing the entire conversation > towards concrete things we can implement to improve the situation. I promptly gave the answer: "I will not make false promises and give any metrics I intend to reach as DPL."[1] Kind regards Andreas. [1] https://lists.debian.org/debian-vote/2024/03/msg00053.html -- https://fam-tille.de
Re: Question to candidates: what are your quantitative diversity goals and metrics?
Am Fri, Mar 29, 2024 at 02:10:07PM -0700 schrieb Soren Stoutner: > Does anyone have a link to the information Margerita shared or information > from other sources about the number of women contributing to Debian compared > to Free Software in general? Having specific numbers is a helpful first step > in > addressing the problem. I was seeking for the video in preparation of my platform but the DebConf15 website was non-functional at the time when I was searching and I was unable to guess from the list of DebConf videos[1] which might be the right one. I also asked Margarita in person and she did not remembered where she had found that numbers at that time. Kind regards Andreas. [1] http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15 -- https://fam-tille.de
Re: Question to all candidates: Bits from the DPL?
Hi Lous-Philippe, Am Tue, Apr 02, 2024 at 04:05:21PM -0400 schrieb Louis-Philippe Véronneau: > Jonathan's latest "Bits from the DPL" entry reminded me of how much I like > those :) > > What are your thoughts on the format? > > If you are elected, do you plan to publish regular "Bits"? If not, how do > you plan to communicate with the rest of the project with regards to the > work you are doing? Quoting my platform: I intend to maintain a daily log in a public Git repository, provided the information can be shared with a public audience. Additionally, I will send a monthly summary to debian-devel-announce to keep you informed about my activities and progress. I was told in private that a daily log in Git might be a bit tough but I hope to manage. I consider it a good preparation for the monthly Bits. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: What are your technical goals
Hi Marc,
Am Tue, Apr 02, 2024 at 10:12:56PM +0200 schrieb Marc Haber:
> There are many people who see Debian as a technology project, with the
> technical goal of producing The Universal Operating System.
>
> What are you planning to do to Debian from a technical and technological
> point of view? What do we well, where do we suck on the technical site?
I see a big problem that we do not follow common standards. While we
have some teams with strict policies setting those standards internally
to a different level of strictness there is no Debian wide consensus
about things like
A. Packages should be maintained on Salsa
B. Lets use dh (if possible - I was told there are exceptions)
C. Commit to latest packaging standards
D. Make more than one person responsible for a package
E. General QA work of contributors not mentioned as Maintainer /
Uploader
[I will reference these items below by their letters]
I'm addressing this in the paragraph "Packaging standards" of my
platform. I'm also very concerned about packages who don't get
any attention any more ("smelly packages") which has two major
reasons:
1. We do not have contributors with free capacity to care for
problems in other peoples packages
2. Even if we had those the strict ownership of packages pevents
that new contributors can step in. When reading the paragraph
about NMUs in developers reference[1] this is probably
sensible for actively maintained packages - but what about
those packages which do not show any activity for years?
> If we do suck in some technical points, what are you planning to do to
> improve those things?
I would love to see that maintaining packages on Salsa becomes mandatory
and I wonder what might be the best way to approach this. We might
start with some GR about it. But perhaps it is better to start talking
to people. I use UDD as my reference and since I want to hear your
personal opinon I'm just querying for your packages. Its definitely not
about you personally - just a nice example.
I notived you are maintaining
select count(*) from (SELECT DISTINCT source, maintainer, uploaders,
vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike
'%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url like '%salsa%')
tmp;
20
packages on Salsa in various teams. Great! You also have
udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources
WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike
'%Marc%Haber%') AND vcs_url not like '%salsa%' order by source;
source| maintainer |
uploaders | vcs_browser
--+--+---+--
apg | Marc Haber |
| http://git.debian.org/?p=collab-maint/apg.git;a=summary
console-log | Marc Haber |
| http://git.debian.org/?p=collab-maint/console-log.git;a=summary
dnstop | Marc Haber |
| http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
policyrcd-script-zg2 | Marc Haber |
| http://git.debian.org/?p=collab-maint/policyrcd-script-zg2.git;a=summary
(4 rows)
I verified on Salsa that all those are imported to debian/ name space on
Salsa (which is also great - I have seen lots of other packages who are
not imported to Salsa). It would help if you could sooner or later
consider uploading those packages. When seeking for other reasons I've
found 11 bugs via
udd=> SELECT id, package, source, arrival, severity, title FROM bugs WHERE
source IN (SELECT DISTINCT source FROM sources WHERE release = 'sid' and
(maintainer ilike '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND
vcs_url not like '%salsa%');
which I will not list here to not lengthen this mail. My guess is you
are aware of this but have reasons / time constraints to not act for the
moment. What would you think if someone would push the following
commits and uploads to unstable:
1. Fix vcs_url + vcs_browser (A.)
2. Fix some bug(s) (E.)
3. Runs Janitor / routine-update which changes (C.)
4. Converts to dh (if not yet which I did not checked) (B.)
5. Turn d/copyright into machine readable form (if not yet which
I did not checked) (C.)
6. Finds a team where the package fits into moves the repository
to that team space and moves you to Uploaders (D.)
Assume you will be asked about those changes but you have no time
to answer (for whatever reason). What of those changes is OK for
you and how long would you expect the potential contributor to your
packages to wait until taking action?
> What is your position about technical leadership?
IMHO we could gain/keep technical leadership if we would manage to apply
our technical standards to all the things w
Re: Question to all candidates: What are your technical goals
Hi Marc,
Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
> On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> > I see a big problem that we do not follow common standards. While we
> > have some teams with strict policies setting those standards internally
> > to a different level of strictness there is no Debian wide consensus
> > about things like
> >
> > A. Packages should be maintained on Salsa
> > B. Lets use dh (if possible - I was told there are exceptions)
> > C. Commit to latest packaging standards
> > D. Make more than one person responsible for a package
> > E. General QA work of contributors not mentioned as Maintainer /
> > Uploader
> >
> > [I will reference these items below by their letters]
> >
> > I'm addressing this in the paragraph "Packaging standards" of my
> > platform. I'm also very concerned about packages who don't get
> > any attention any more ("smelly packages") which has two major
> > reasons:
> >
> > 1. We do not have contributors with free capacity to care for
> > problems in other peoples packages
> > 2. Even if we had those the strict ownership of packages pevents
> > that new contributors can step in. When reading the paragraph
> > about NMUs in developers reference[1] this is probably
> > sensible for actively maintained packages - but what about
> > those packages which do not show any activity for years?
>
> I think this can't just be seen by looking at the statistiks. Many small
> packages do their job and don't need constant attention as long as they
> still build and work.
I agree that pure statistics is not telling the whole story. However,
those statistics give some feeling about the issue which for sure needs
to be verified on case-by-case basis. I can assure you that I usually
inspect the list of smelly packages[1] whether there are hits for my
name (currently one false positive and one package where I'm forced to
use cdbs) but also look for packages I might be able to salvage from
there. I've found some impressive hits for this purpose in the past
that are supporting my point besides stupid statistics.
> ...
> Those three packages I decided not to put work into until there is a
> technical reason for doing so. I do have all three on the radar and they
> will properly move to salsa and be modernized once there will be a
> change to the code or an RC bug regarding packaging. Until then, I have
> more important things to do.
Thanks for going into detail about these which I neither wanted nor
expected in this granularity. I had no doubt that there are more
important things for you. I honestly tried to investigate by using
these examples is the following: In case there might be people out
there who have time and energy to fix this kind of things, how can we
enable them to take this work from your shoulders to enable you
concentrating on more important stuff.
> policyrcd-script-zg2 I should modernize and upload. A few people seem to
> actually use this, and it helps getting rid of the discussions whether a
> distributio should start a daemon right after package installation
> (which we do, and Red Hat based distributions don't, causing irritations
> by people accustomed to Red Hat working with Debian). You got a point
> here.
As I said I did not wanted to make a point about your maintainership.
I simply wanted to discuss existing examples instead of statistics.
> Those bugs are either wontfix, or already fixed in git (not yet uploaded
> because cosmetic), or neglected, right.
I personally tend to upload when I've fixed some bug in Git (even when
cosmetic) to remove noise from BTS. In the said cases it would
specifically helpful to fix VCS information since it is very important
information for other Debian contributors. Before uploading I usually
run `routine-update -f` which is just upgrading to latest standards by
calling Janitor tools and does some other changes to keep up with latest
packaging standards semi-automatically.
> > What would you think if someone would push the following
> > commits and uploads to unstable:
> >
> > 1. Fix vcs_url + vcs_browser (A.)
> > 2. Fix some bug(s) (E.)
> > 3. Runs Janitor / routine-update which changes (C.)
> > 4. Converts to dh (if not yet which I did not checked) (B.)
> > 5. Turn d/copyright into machine readable form (if not yet which
> > I did not checked) (C.)
> > 6. Finds a team where the package fits into moves the repository
> > to that team space and moves you to Uploaders (D.)
I forgot
7. Add autopkgtest
> 1-5 are just fine. That's what gi
Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi, in the light of the previous discussion I have a question to all voters. Due to bug #1066377 more than 30 testing removal warnings hit my mailbox today (I stopped counting after 30). While the Debian Med package clustalo is the only package that's responsible for this due to its Build-Dependency from libargtable2-dev there is quite some dependency tree inside Debian Med team also affecting packages relevant for COVID-19 etc. This small lib is not a key package which is important for all things I'm writing below. Its used as Build-Depends by 6 other packages. Our always busy team member Étienne Mollier provided a patch 10 days ago (thanks again Étienne). The package had its last maintainer Upload -- Shachar Shemesh Sat, 16 Jul 2016 20:45:15 +0300 (Shachar in CC) and a NMU -- Holger Levsen Fri, 01 Jan 2021 17:15:04 +0100 (reproducible build, no changes - in other words no problems since 2016). However, the BTS view of Sanchar might hinting for some inactivity when looking at two RC bugs in other packages: #965787 privbind: Removal of obsolete debhelper compat 5 and 6 in bookworm #998987 [src:privbind] privbind: missing required debian/rules targets build-arch and/or build-indep As I wrote to Marc here on this list also the explicit hint to Shachar: Its not about blaming you - I just want to analyse the current situation to act properly. Given that you had no capacity to respond to two bugs that are RC since 2 years makes me wonder how long I need to wait for your OK to a team upload I'm proposing below. I'm perfectly aware that we as volunteers can't be blamed about those things. I simply want to find new ways how to deal with those situations appropriately. Am Thu, Apr 04, 2024 at 12:38:34PM +0200 schrieb Andreas Tille: > > > > > > A. Packages should be maintained on Salsa > > > B. Lets use dh (if possible - I was told there are exceptions) > > > C. Commit to latest packaging standards > > > D. Make more than one person responsible for a package > > > E. General QA work of contributors not mentioned as Maintainer / > > > Uploader > > > > > > > > > 1. Fix vcs_url + vcs_browser (A.) I moved the package to salsa[1] and added VCS fields > > > 2. Fix some bug(s) (E.) I applied the patch from Étienne. > > > 3. Runs Janitor / routine-update which changes (C.) I was running `routine-update -f` > > > 4. Converts to dh (if not yet which I did not checked) (B.) I removed debian/autoreconf.* files which were unneeded with latest dh compat level (and routine-update is doing this). > > > 5. Turn d/copyright into machine readable form (if not yet which > > > I did not checked) (C.) Secure URI in copyright format > > > 6. Finds a team where the package fits into moves the repository > > > to that team space and moves you to Uploaders (D.) I simply sticked to debian/ since I have no idea what team might fit. > I forgot > 7. Add autopkgtest I admit I did not spent time into this. > > 1-5 are just fine. That's what git is for. Either fork the project, > > commit changes, file an MR, or (dor a repository inside the Debian/ > > space), commit to a branch, file an MR. > > Thank you for your opinion. It is very valuable for me to learn what > people consider acceptable. I assume you would consider 7. fine as > well. I guess this is fulfilled. > > Personally, I do prefer having the last word to say what gets into > > the master/main branch and I'd like to at least be consulted before an > > upload. > > If no team is specified this is definitely default behaviour. Shachar is in CC of this mail. > > I might look like a rotten maintainer when you look at my oldest > > packages, > > Absolutely not. When digging into the said resources I have seen way > worse. I'm not here to blame anybody. I'm seeking for solutions. Sorry again for just picking this example which is attached to you (Shachar). I neither wanted to blame Marc about anything in my previous mail nor you in this mail. Its simply the kind of thing that is creating a lot of stress in our team. I could follow the normal NMU procedure but I do not consider this a sustainable solution. It took me about 10-15 min in my lunch break to bring the package into a shape, where other people are able to commit in a convenient way (Salsa, latest packaging standards). > > 6 I would find too intrusive without talking to me first. It's a slap in > > the face, I would probably drop the package as a kneejerk reaction. > > Talking to you is mandatory. I know you for a long time as helpful and > responsive on mailing lists. But assume we are talking about someone > who does not r
Re: Question to all candidates: What are your technical goals
Hi Luca, Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi: > > As far as I know other major distributions do not undertake the time_t > > 64bit transition (whether this marks leadership or not is questionable > > but it will make us the leading distribution on those architectures in > > future). > > Of course they are, most of the important work lately has been done by > SUSE for example, to replace legacy components that will hopelessly > break in 2038. Of course they have an advantage in not having to carry > around dead architectures, so it's easier. Thank you for the information. > > I think we are doing a good job regarding CI with adding autopkgtests > > (but we could do even better for sure). I'm not informed about the > > status of CI in other distributions and whether there exists something > > like Salsa CI. I'm positively convinced that Debian has reached a level > > of complexity which makes CI tests mandatory for every important package > > and I would love if we could do the lead here. > > OpenQA is used by other distros, both Fedora and SUSE use it. Fedora's > source control system has a CI integrated with it that is similar to > the one we have. Packit is even starting to make its way in upstream > projects's CIs, we use it in systemd for example, so that upstream PRs > also build and test Fedora packages in Fedora images. We do the same > with Debian and autopkgtest btw. Thanks again. As I admitted in my platform I'm not well informed about other distributions but I'm willing to become better informed to be able to learn from others. > > > That's the price we currently pay for being not a commercial entity, > > > > I fully subscribe to this statement. > > I don't think commercial entities have anything to do with this. > Fedora is not a commercial entity (please, no FUD about RH) and yet it > can take decisions and implement them just fine. It's entirely a > question of self-organization and what rules we decide for the > project. Please don't get me wrong: I do not consider Fedora a commercial entity. I simply subscribe the statement that we are facing some problems in Debian since we are not a commercial entity. > > I need to admit that I (currently) don't know much about Fedora (but I > > hope I could fix this in the near future). At Chemnitzer Linuxtage I > > took the chance to talk to OpenSUSE and Nix about organisatorical > > solutions. There was no booth by Fedora I could show up. > > In short, Fedora project members elect a technical committee, FESCO. > Project members can submit proposals to this committee for > project-wide changes, which votes on whether to approve them or reject > them. If they are approved, the committee and the proposer are > empowered to enact the changes distro-wide - whether individual > package maintainers like them or not. An approved proposal can fail > and be rolled back for technical reasons (e.g.: unexpected issues crop > up at implementation time), but not because random package maintainers > practice obstructionism because they don't like the decision. If you compare this to Debian what exactly is your proposal to change for the better? Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Scott, Am Thu, Apr 04, 2024 at 12:42:11PM + schrieb Scott Kitterman: > I'm interested to understand what you think this has to do with the DPL > election or the role of the DPL within the project? I would like to learn what options I have to realise paragraph Packaging standards of my platform. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Thu, Apr 04, 2024 at 01:04:49PM + schrieb Holger Levsen: > On Thu, Apr 04, 2024 at 02:59:34PM +0200, Andreas Tille wrote: > > I would like to learn what options I have to realise paragraph > >Packaging standards > > of my platform. > > I also think this feels a bit like abusing the election audience for a > topic Fair enough. I personally have seen the campaigning period as a way voters might learn how I intend to work. You can take my message also as my style of leadership to ask in advance to get some picture. > which should be discussed on -devel outside campaigning. I confirm debian-devel is the right place to discuss this issue in detail and for sure I would move (or better reopen) the discussion there. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: What are your technical goals
Hi, Am Thu, Apr 04, 2024 at 09:55:33PM +0100 schrieb Luca Boccassi: > On Thu, 4 Apr 2024 at 21:30, Salvo Tomaselli wrote: > > > > > In practical terms, it would probably be made easier if it was > > > mandatory for all packages to be on Salsa, either in the 'debian' > > > namespace or in a team namespace (but not under individual users). > > > > Realistically, even if you decide "everything is now team maintained", if > > there is only 1 person who cares about a certain package there won't be any > > team member doing anything about it. This is perfectly true and I've seen quite a lot of team maintained packages that are effectively touched by one team member only. You might like to compare the graphs of maintainer per package of Pkg Perl team[1] where the majority of packages is maintained by 4-6 people, DPT [2] where the majority of packages is maintained by 2-4 people and Debian Science team[3] where we have de facto a single maintainership per the majority of packages. The differences are divers and need extra discussion. Specifically you can't compare specialised scientific software with general language packages used in many dependencies. However, I tend to think that the difference between Pkg Perl and DPT are partly caused by the culture inside the team. In three teams I was involved we basically forked Pkg Perl policy which was wide open to team wide changes. In contrast to this the DPT policy had some de-facto non-team option and it caused some friction (to say it extremely short) to drop this[4]. What I want to say is: The pure *option* to have more than one person touching a package makes quite a difference. For sure its no guarantie that this will happen. (And I'm really curious what will happen in Pkg R team if I might stop my work there for one year[5]. > > So having it on salsa or whatever won't > > really do much, besides being annoying for people who have to change their > > workflow for no reason. > > Sure, but this is in the context of project-wide changes discussed above. This argument is even stronger innfavour of team maintenance. Beeing asked about technical lead here: We are possibly lagging even more in maintenance way behind other organisations. Using Git should be default these days. Changing the workflow to point to Salsa instead to somewhere else should be not that dramatically annoying for everybody given there are good reasons to do so. > > Also let's not forget that it is expected for people who are not DD to > > contribute to debian, and they can only create repositories on salsa under > > their own name (for good reason, mostly). > > Such contributors need a DD sponsor, which means access can be granted > to individual repositories. ACK. Kind regards Andreas. [1] http://blends.debian.net/liststats/maintainer_per_package_pkg-perl.png [2] http://blends.debian.net/liststats/maintainer_per_package_python-team.png [3] http://blends.debian.net/liststats/maintainer_per_package_debian-science.png [4] https://lists.debian.org/debian-python/2024/02/msg00052.html [5] https://lists.debian.org/debian-r/2024/03/msg0.html -- https://fam-tille.de
Re: Question to all candidates: What are your technical goals
Am Thu, Apr 04, 2024 at 02:41:00PM +0100 schrieb Luca Boccassi: > > Please don't get me wrong: I do not consider Fedora a commercial > > entity. I simply subscribe the statement that we are facing some > > problems in Debian since we are not a commercial entity. > > I think the framing is slightly misleading: it's true that a > commercial entity with a hierarchical structure would not have the > same issue, but the point I am making is that there's nothing stopping > a non-commercial entity from having a structure that allows the same > decision-making and executing, as proved by Fedora. Well, do you think well-respected members of our community who disagree with a change of structure are "nothing"? In preparation of my platform I started kind of a test ballon inside DPT where I spotted something I considered wrong inside the team policy and suggested a change[1]. There were a lot of positive responses and finally the change was accepted. But even before this happened we've lost two major contributors[2] (leaving more or less silently) and [3]. I confirm I made mistakes in this process and hopefully learned from it. So we have to deal with people and changing a structure that has evolved over >30 years might be harder than in the case of other distributions with a different history. IMHO changing a structure is harder than creating one from scratch. > Hence, it's not > just the fact that Debian is not a commercial entity that leads to the > status quo, but the combination of not being a commercial entity > _plus_ precise and explicit choices about project governance. I'm kindly inviting everybody to join me in drafting a GR about this (no matter whether I might get elected or not). > > If you compare this to Debian what exactly is your proposal to change > > for the better? > > For starters there needs to be a decision on whether the status quo is > fine or change is needed. That is non-obvious, I have my opinion but > others will have theirs. It would mean the end of "my package is my > fiefdom", and a move towards collective maintenance. I share this opinion 100%. > From the organizational point of view, it would require a GR to change > in the constitution to enshrine the power to take technical decisions > and make them happen into a constitutional body - the CTTE will > probably say "no no no not us, please, no", but I'm pretty sure that's > exactly where such power should reside, especially because they don't > want it. I fail to see the logic in this "especially because they don't want it" but I agree that I see the potential decision making body in the CTTE. To say it clearly: It should by no means be DPL (and I hope your logic does not apply to this statement as well. ;-P ) > A procedure to submit proposals for discussion with the whole > project should be established (we already have the DEP process for > example), that ends with a vote of the decision makers body. And once > the body makes a technical strategy decision, them or whoever they > want to empower, can go and make it happen, without having to walk on > eggshells and dance around sacred cows - the time to dissent and > discuss is _before_ the decision is made, not _after_. To stick to one example I gave in an other thread on this list: Assuming we decided to move all packages on Salsa, I could start importing packages that are not on Salsa and upload these starting from the day after this decision without asking the maintainer? > In Fedora every > proposal must include a criteria to allow declaring that the game's a > bogey and plan to rollback, in case something goes wrong, but this is > again decided by the decision makers body. Interesting detail which is probably not feasible for every decision (since its hard to imagine how to roll back a "move all packages on Salsa" decision). > In practical terms, it would probably be made easier if it was > mandatory for all packages to be on Salsa, either in the 'debian' > namespace or in a team namespace (but not under individual users). ACK > Then perhaps for each approved decision, until the project is > completed the implementer(s) would automatically get write access to > all teams namespaces to push the changes - as MRs because reviews are > good, but with the powers to merge them too. Sounds sensible. > I'm getting ahead of myself, but hopefully you get the idea. I perfectly get the idea since I basically subscribe this for years. Kind regards Andreas. [1] https://lists.debian.org/debian-python/2024/02/msg00052.html [2] https://lists.debian.org/debian-python/2024/03/msg00043.html [3] https://lists.debian.org/debian-python/2024/03/msg00118.html -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Fri, Apr 05, 2024 at 09:55:56AM + schrieb Holger Levsen: > On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: > > [...] I could follow the normal NMU procedure but I do not consider > > this a sustainable solution. > [...] > > I did not uploaded my work but I would like to know what action is > > considered acceptable by the voters. I repeat that the package is no > > key package for which I would not consider what I did above. Please > > simply fill in the form: > > > >[ ] Its not acceptable, don't do that > >[ ] We should discuss this on debian-devel, possibly do some GR > >before things like this are permitted > >[ ] Wait one week before uploading > >[ ] Wait one day before uploading > >[ ] Just upload provided you care for any break your action might > >have caused. > >[ ] ??? > > > > What do you think? > > rereading this, I must say I think "wtf". > > please *do* follow the NMU procedures or salvage the package. (or leave it > alone.) Salvaging would mean to set a new maintainer. I could make the Debian Med team new maintainer since we are obviously affected and we are packaging several preconditions. Do you consider this better than debian/ space? > also: (NMU-)uploads to DELAYED/15 are great. Sorry, I do not feel my time well spent on just curing a symptom (unfixed RC bug) via NMU instead of addressing the underlying cause that the package is maintained by a single person. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Tobias, Am Thu, Apr 04, 2024 at 07:59:56PM +0200 schrieb Tobias Frost: > > There is the possilbity to salavage the packagei [1], but that of course will > only work if the person agrees to take over maintainance and add their name to > Uploaders: or Maintainer: [2]. I want to be able to immediately respond to future problems in this package. I'm fine with putting Debian Med team as maintainer, but not my personal ID (maximum as Uploader since I do not have any personal packages). Do you think this would be the appropriate action (which I personally would even prefer over debian/ space)? The conservative criteria are fulfilled. Kind regards Andreas. > The package can be put into a team's umbrella at the ITS time. This > does not need an explicit OK, though the maintainer can veto. > > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > https://wiki.debian.org/PackageSalvaging > > [2] This is a feature, the ITS procedure has been designed exactly that > way, to avoid that people just do an upload and drop the package > immediatly afterwards, as this will likely only upset the current > maintainer without long-term benefits to the package - kind of to > avoid the reaction Marc predicted. > If taking over the maintaince is not the goal, remember NMU allow > one to fix almost every bug, also wishlist bugs are regularily in > scope. And bugs can be filed, if needed. > Some Background story: > https://lists.debian.org/debian-devel/2018/07/msg00453.html > > -- > tobi -- https://fam-tille.de
Re: Q to Andreas: weaknesses and challenges outside packaging?
Hi Lucas, Am Fri, Apr 05, 2024 at 08:56:42AM +0200 schrieb Lucas Nussbaum: > Hi Andreas, > > In your platform and answers to questions here, I feel that you mainly > focus on the visible side of Debian for the public, that is, the > distribution we produce. > > However, the role of the DPL is a lot about working on fixing all the > little annoyances that make it less fun for contributors to work on > Debian. In my experience, that involves a lot of work with "behind the > scenes" teams. > > What is your past experience is that area? None. > And looking ahead, what do you perceive as the main weaknesses of Debian > in that area? What are our main challenges ahead? What are the big > threats that we will likely have to face in the next years? Are there > opportunities we could leverage? These are exactly the questions I would have to you (and other previous DPLs) in case I might become elected. I might realise that I'm absolutely naive about the options I have to change what you call the visible side and get swamped by the things you are mentioning. I tried to address your questions in my platform "What makes me afraid about running for DPL". I received some hints from previous DPLs and I trust I can rely on your past experiences. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: GDPR compliance review
Hi Adrian, Am Fri, Apr 05, 2024 at 12:41:17AM +0300 schrieb Adrian Bunk: > this email has two parts: > A short question where I would appreciate a "yes" or "no" answer from > all candidates, and a longer explanation what and why I am asking. > > > Question: > > If elected, will you commit to have a lawyer specialized in that area > review policies and practices around handling of personal data in Debian > for GDPR compliance, and report the result of the review to all project > members by the end of 2024? No. > Explanation: Explanation for my "No". You wanted a binary answer and you got it. I doubt a binary answer to a complex question that needs a long explanation is appropriate. > One might discuss whether or not Debian should aim at being better than > average in the area of privacy, but compliance with the law is the > minimum everyone can expect. > > Unlawful actions can have consequences, organizations and > individuals might be subject to fines up to 20 Million Euro > as well as compensation for material and non-material damage, > and in some countries also prosecution under criminal law. > > > Many parts of Debians Privacy Policy look questionable. > > For example the rights are not stated, and in addition to this being a > formal problem there is also the question whether for example the Debian > Data Protection team does fulfil the right to request only where > required by law or whether all people around the world are treated > the same. I need to admit I do not understand this example. > The attempts in the Privacy Policy for blanket eternal storage > of data might not pass a legal review, especially when this might > contain sensitive data like sexual orientation or political opinions. I'm not aware that those personal data are stored. If this is really the case you have a point. > I also suspect that the Debian Account Manager and Community Teams > might be abusing people by illegally processing data outside of what > is being permitted by the Privacy Policy. I've reviewed the "State of the Data Protection team" talk from DebConf22[1]. I understand that you can address those suspicions with this team. > I would be glad to hear from a qualified person that I am wrong and that > all handling of personal data by these teams is lawful. If I understand you correctly you want to know my opinion whether Debian should pay some lawyer specialized in data privacy to inspect "all handling of personal data", right? > There is also a personal side for me: > > I am feeling quite unsafe in Debian due to not knowing what data people > in positions of power in Debian who dislike me might have about me, and > I want to request all data about me in Debian. This is also a prerequisite > for exercising the right of rectification of inaccurate personal data if > any data turns out to be incorrect. While I may be somewhat naive, I'm unaware of any positions within Debian that hold the power to harm others. IMHO, the most troubling aspect is your feeling that there are individuals who dislike you. If you really feel unsafe about this situation IMHO the first step should be to talk to some individual you are trusting inside Debian. > I would wish that Debian itself can ensure that all handling of personal > data is lawful, and that GDPR requests are being fulfilled without > problems - like everywhere else. I'm not particularly well-versed in GDPR issues, but I would imagine that there must be a justified suspicion before seeking legal counsel. > Other places with DDs also have laws protecting personal data > (at least California, China, Brazil, South Africa, Singapore). > > I am asking specifically about GDPR since that affects me directly, but > either during the GDPR review or afterwards it would of course be good > to also obtain legal advice whether there are additional requirements > in other jurisdictions. To qualify my previously stated 'no' I'd rather say: No, except you come up with some more specific example (feel free to do this in private and if you like in our common mother language). Alternatively, the urgency of the issue might be highlighted by several other developers to bring my attention to the severity of the problem. Kind regards Andreas. [1] https://debconf22.debconf.org/talks/39-state-of-the-data-protection-team/ -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Scott, Am Thu, Apr 04, 2024 at 01:12:45PM + schrieb Scott Kitterman: > On April 4, 2024 12:59:34 PM UTC, Andreas Tille wrote: > >I would like to learn what options I have to realise paragraph > > > > Packaging standards > > > >of my platform. > > Obviously the DPL has an outsized voice in Debian. When the DPL says > something, it will tend to get more attention within the project. I agree with "more attention" but I doubt attention is some specific power. > Beyond that, what specific powers of the DPL will help you realize this goal? > In other words, why do you need to be DPL to do this? Quoting myself: I consider the DPL as a "Leader with no power" so no specific powers. I'd possibly like to profit from the higher level of attention that might motivate others to join the discussion. Thus I might have a better chance to moderate this discussion (but I might be wrong here). Private reason: I will be motivated to dedicate time into this process which I have spent all the years more on packaging and QA work. Kind regards Andreas. -- https://fam-tille.de
Re: (last minute) Question to both candidates: CRA+PLD, similar regulations, and Debian
Hi Santiago, Am Fri, Apr 05, 2024 at 03:21:48PM -0300 schrieb santiago: > ... > Non-commercial FLOSS products/projects do not have to comply with CRA. > However, I think there could be an impact in the industry regarding the > adoption and use of Debian. > > What are you thoughts on the subject? > > Should Debian help those commercial downstreams to fulfill the > requirements? I would like to discuss this complex topic with people who are involved more deeply into this topic. I consider the current person-power within Debian insufficient for taking on additional tasks. Thus, even though we may have the intention to assist, the implementation remains challenging. I'm uncertain whether commercial downstreams might allocate resources towards legal expertise to find ways to adapt the law situation or explore alternative strategies to address this situation. Kind regards Andreas. > [CRA] https://www.europarl.europa.eu/doceo/document/TA-9-2024-0130_EN.html > > Thanks for running for DPL to both of you! > > -- Santiago -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Holger, Am Fri, Apr 05, 2024 at 10:42:35AM + schrieb Holger Levsen: > On Fri, Apr 05, 2024 at 12:26:03PM +0200, Andreas Tille wrote: > > > also: (NMU-)uploads to DELAYED/15 are great. > > Sorry, I do not feel my time well spent on just curing a symptom > > (unfixed RC bug) via NMU instead of addressing the underlying cause > > that the package is maintained by a single person. > > so you value your values and needs higher than our shared and agreed values. I do not think that we agreed upon how volunteers might spent their time. There is a patch in BTS for the said bug and I take the freedom to not NMU. At the time of writing it seems every other developer prefers to do other things than uploading the patch. No idea how you conclude from this fact to some values I'm weighting differently. What I want to find out is: Are the values we agreed upon meeting todays needs or not? Is the developer community interested in some change I might start or not? Please take this discussion as my way to find some pain points in the discussion to act more sensibly on debian-devel once we might talk about new ways. > noted. > > (also, pressuring people to accept more co-maintainers can have serious > side effects as became very visible last weekend with xz upstream...) Seems that case makes a great argument which is pretty popular these days. I'd love to have some explanation in how far it matches the example I gave. I have no means to pressure anybody - neither to make a maintainer accept contributions nor any co-maintainer to provide any contribution. My point is to enable better chances for cooperation between people we trust anyway. > Make facts great again. Yeah! Kind regards Andreas. -- https://fam-tille.de
My stance on single-person maintainership
Hi, on debian-private which I can't quote here I was asked, whether I would continue 'going for forced “team” maintenance'. My answer was as following: I stick to the sentence of my platform: 'If you think single maintainership of packages is the right way to cope with future problems for Debian you should probably rank me below "None of the above".' I don't see both statements equivalent. My statement is about a vision voters are sharing (or not). Your statement is about forcing something that neither can be forced nor has the DPL any power to force something (per constitution). What I like to accomplish as a first step is drafting a GR about the mandatory usage of Salsa as some first step to enable some effective way in "Building redundancy" (the paragraph which contains the sentence above). Scott asked on debian-vote: What specific powers of the DPL will help you realize this goal?[1] I might like to add to the answer I gave to this question: Probably all other work as DPL might rather keep me away from working on this. However, I like to encourage interested people (and due my campaign I sensed a lot of interest), to draft a sensible GR about this topic. Your choice you consider me below NOTA right now or vote "Further discussion" later. I consider the mandatory usage of Salsa important to accomplish Debian wide changes. Janitor is nice, its polishing things but I see way more potential. Just assume NMUs of time_t 64Bit transition could have operated on Salsa by pulling everything from there, do automated changes and also pushing back what was uploaded. This could have saved all parties involved quite some time. Five years ago Michael Stapelberg has explained the disadvantages of the "Change process in Debian". I fully subscribe what Michael wrote and I did not noticed any relevant change since that time. Other advantages like tag2upload, a defined CI process etc. come to mind. I think we all agree that Git is a great collaboration tool and we have Salsa as platform that can stir fruitful cooperation. I'd be happy if we could all agree that the consequent usage of Salsa has technical advantages for everybody. In short: While I personally prefer team maintenance I see the mandatory usage of Salsa just as a precondition for this with some additional advantages no matter how many people are working on some package. I rather like to build the foundation for some future DPL who might share my mindset about teams by at the same time standardise the way we handle our source code for extra profit. Since I've frequently seen the XZ case as a dead beat argument against co-maintenance: If XZ had been maintained by more than one person from the outset, it would have been less susceptible to attacks leveraging social pressure, preventing someone from stepping in at an inopportune moment. The fact that you can tweak the case as an argument for both sides might show that it does not really help here. I don't want to hide that I'm personally in favour of team maintenance since I have made overwhelming positive experiences with this - and there were also some negative experiences. Kind regards Andreas. [1] https://lists.debian.org/debian-vote/2024/04/msg00016.html [2] https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ [3] https://lists.debian.org/debian-r/2024/03/msg0.html -- https://fam-tille.de - Ende weitergeleitete Nachricht - -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi again, Am Sat, Apr 06, 2024 at 09:26:25AM +0200 schrieb Tobias Frost: > > I want to be able to immediately respond to future problems in this > > package. I'm fine with putting Debian Med team as maintainer, but not > > my personal ID (maximum as Uploader since I do not have any personal > > packages). > > > > Do you think this would be the appropriate action (which I personally > > would even prefer over debian/ space)? The conservative criteria > > are fulfilled. > > Yes, (if your name is in Uploaders:) this is is fine. I've filed ITS bug #1068561. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Thu, Apr 04, 2024 at 10:14:59AM -0700 schrieb Soren Stoutner: > On Thursday, April 4, 2024 5:32:45 AM MST Andreas Tille wrote: > >[ ] Its not acceptable, don't do that > >[ ] We should discuss this on debian-devel, possibly do some GR > >before things like this are permitted > >[ ] Wait one week before uploading > >[X] Wait one day before uploading > >[ ] Just upload provided you care for any break your action might > >have caused. > >[ ] ??? > > Given the circumstances, I think waiting one day before uploading is > appropriate. > > I also feel that asking this question on this list is appropriate. It is > insightful in helping me understand how Andreas would approach being the DPL, > thus informing my vote. Summarising my question about how to deal with an example RC bug that affects some dependency tree of some team: 1. Prefer NMU which solves the problem quickly. I do not volunteer to do this since I do not consider it sustainable in the said situation. 2. Prefer package salvaging (which I did now #1068561 but its a lengthy process that will trigger another series of testing removal warnings in between) 3. Two responses would agree to an alternative way which are not backed up by any procedure we agreed upon so I will not do this. I wonder whether we can use this as some input to simplify / shorten the salvage process or whether we should move on as before. Additional remark: When reading the PackageSalvaging FAQ[1] I realised that my way to talk about examples might be considered finger pointing no matter whether I write that this is not intended. I understand I was wrong here and I'm sorry about doing so. I do not intend to do this in future any more. Kind regards Andreas. [1] https://wiki.debian.org/PackageSalvaging#FAQs -- https://fam-tille.de
Re: [RFC] General Resolution to deploy tag2upload
Hi, thanks to all for this GR. I like tag2upload in principle. The only thing I'm a bit scared about is that it simplifies uploading something that was never built before on the local machine. Sure, this can be done with source-only uploads as well, but tag2upload makes it even easier. Maybe I missed it in the long thread and I need to admit that I have not read the docs, thus the explicit question here: Is the package undergoing some CI test (maybe not only building but also autopkgtest which I'm doing locally for any package I'm uploading) before it is forwarded to dak? Thanks again for all your work Andreas. -- https://fam-tille.de
Re: [RFC] General Resolution to deploy tag2upload
Hi Sean, Am Thu, Jun 13, 2024 at 04:53:56PM +0800 schrieb Sean Whitton: > > thanks to all for this GR. I like tag2upload in principle. The only > > thing I'm a bit scared about is that it simplifies uploading something > > that was never built before on the local machine. Sure, this can be > > done with source-only uploads as well, but tag2upload makes it even > > easier. > > I don't believe it makes any difference. We already have 'dgit > push-source' which will do a source-only upload with a single command > invocation. And if 'dgit push-source' errors out, that's equivalent to > tag2upload failing to upload and e-mailing you. That means some package build process is done before the source package is forwarded to dak and sends some e-mail back? > No, there is nothing additional being done. > > Now we have salsa CI, though, we have various good options for automated > pre-upload testing. I know we have this. My point is that tag2upload users might forget to use it before using tag2upload service. I simply want to make sure that tag2upload is not another way to upload anything that does not build on buildservices. Kind regards Andreas. -- https://fam-tille.de
Re: [RFC] General Resolution to deploy tag2upload
Hi Ian,
Am Thu, Jun 13, 2024 at 12:47:35PM +0100 schrieb Ian Jackson:
> Andreas Tille writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > That means some package build process is done before the source
> > package is forwarded to dak and sends some e-mail back?
>
> Only a source package build.
Thank you for the clarification.
> > I know we have this. My point is that tag2upload users might forget
> > to use it before using tag2upload service. I simply want to make
> > sure that tag2upload is not another way to upload anything that does
> > not build on buildservices.
>
> I'm afriad that tag2upload is precisely another way to do that.
>
> That's because that's how uploading works now, and tag2upload is
> another way to make an upload. Uploads must be source-only nowadays
> (in most cases). So there is, by design, nothing in the existing
> setup that ensures that a maintainer built binaries.
That's correct.
> (I get the
> feeling that you're not happy with this situation, but that's how
> Debian is now, and I think it's a jolly good thing.)
I wanted to clarify whether this is the case. At least I would see the
potential in tag2upload to do some intermediate step. I do not really
know whether its worth burning lots of CPU cycles for an extra binary
build since I trust my fellow developers to do what they are expected to
do. However, there might be situations where people might make mistakes
or really assume that something builds after a really slight, but
breaking change.
> You might argue that tag2upload makes this worse because it makes it
> easier to perform uploads. It certainly *does* make it easier to
> perform uploads. That's a big part of the point.
I perfectly understand this. If I would consider this bad or good I
would have said so. I'm simply lacking experience who many broken
source-only uploads are hitting dak and we will see whether this number
might increase in case tag2upload might become established (which I
hope).
> I think this can only be a *downside* if you think it is a good
> thing that uploading is difficult.
>From a user perspective some intermediate binary build wouldn't be more
difficult, thought. I think we could make things more safe by the
expense of extra power consumption and for large packages (which could
be white-listed) extra delay. This is by no means any pro or con
argument. Just wanted to throw in that idea for comments.
Kind regards and thanks for all the effort in tag2upload
Andreas.
--
https://fam-tille.de
Re: [RFC] General Resolution to deploy tag2upload
Hi Russ, Am Thu, Jun 13, 2024 at 01:54:16PM -0700 schrieb Russ Allbery: > > It would be nice to not do this on the tag2upload server, though, to > maintain some security separation. ACK. > Given all of that, I think it would be more promising to look into a > deeper integration with Salsa to check if the Salsa CI has succeeded, as > discussed earlier in this thread. That would also match common upstream > practice in Git-first development where the workflow for generating the > release artifact depends on all of the tests passing through the normal CI > mechanism. As I said I did not read this thread in total (neither will I manage to do so soon) but I would really welcome Salsa CI integration into tag2upload. It sounds perfectly sensible to me in many ways. Kind regards Andreas. -- https://fam-tille.de
How is the original tarball obtained in tag2upload
Hi, just a question which I hope was not addressed before in this long thread I have no chance to follow completely. If it was just answered simply point me to the archive (or alternatively the tag2uplod doc is its described there): In many teams we keep the metadata about the orig.tar.$COMPRESSION tarball in pristine-tar branch. In most cases this works flawlessly but I've observed some exceptions and read about potential problems with pristine-tar. How is the problem to get the original tarball solved in tag2upload? Kind regards Andreas. -- https://fam-tille.de
Any reference of ftpmaster does not want to accept tag2upload (Was: [RFC] General Resolution to deploy tag2upload)
Hi folks, answering to some "random" mail in this thread since I do not manage to follow everything. My pragmatic thought when browsing my malbox is that I'm honestly wondering how many source packages the contributors in this thread could have created manually in the time that was used to write those emails. Its possibly the price we have to pay for some progress. IMHO we should make really sure the return of (time-) investment should be less than 10 years. So what about a short-cut in this discussion? Am Sun, Jun 23, 2024 at 10:16:38AM -0700 schrieb Russ Allbery: > So far as I know, no one in this discussion has ever asked for the FTP > team to deploy tag2upload. The only hard request of the FTP team is to > not block uploads made with it. If the FTP team refuses to do any work > whatsoever on anything related to tag2upload, it is still possible to > deploy it (with some assistance from other teams such as DSA, of course). I would really love to see some mails / logs of discussion between tag2upload developers and ftpmaster team. Is there any chance that we could bring the involved parties in one (virtual) room and discuss the thing directly? I'd love to serve as moderator in this room (with my DPL hat on). Kind regards Andreas. -- https://fam-tille.de signature.asc Description: PGP signature
Re: tag2upload, reproducible .orig and dfsg repacks
Hi Matthias, Am Wed, Jun 26, 2024 at 03:25:34PM +0200 schrieb Matthias Urlichs: > You can feed hashes of the offenders to "git filter-repo > --strip-blobs-with-ids ‹filename›". This operation is idempotent and > deterministic. > > If we add these hashes to a file, let's say d/source/dfsg-filtered, we can > thus reproducibly generate a dfsg-compliant version of whichever upstream > commit or tag we want, and of course generate a tarball from there if > required. Your suggestion sounds sensible. However, I'd prefer if we would not invent a file that might duplicate the content of the d/copyright Files-Excluded field - but this seems to be some implementation detail. Kind regards Andreas. -- https://fam-tille.de
Re: General Resolution: Handling of the non-free section
On Tue, 24 Feb 2004, Debian Project Secretary wrote: >Seconds: 1. Scott James Remnant [EMAIL PROTECTED] > > The next release of Debian will not be accompanied by a > non-free > section; there will be no more stable releases of the non-free > section. The Debian project will cease active support of the > non-free section. Clause 5 of the social contract is repealed. > >Since this modifies the Social Contract, thsi requires a 3:1 > majority to >pass. > > >Seconds: 2. Sean 'Shaleh' Perry [EMAIL PROTECTED] > ... > 9. Scott James Remnant [EMAIL PROTECTED] Does Scott second both?? Kind regards Andreas.
Questions to candidates
Hi, this morning I wrote in private to the DPL candidates but tbm asked me to foreward my questions to debian-vote which I'm doing hereby ... Here are my questions: 1. My concern is to propagate Custom Debian Distributions because I think we should set a stronger focus to the end user. I see Debian as a missing link between upstream developers and end users and Custom Debian distributions are a good way to care for end users. What are your plans according to Custom Debian Distributions? 2. Recently we had some flamewars about concentration of "power" for some people inside Debian. While I'm much more relaxed than many others and save my time for work instead of fighting flame wars I have one certain question here. How do you see the role of James Troup in the project? While I think that he did a great job in terms of finding technical solutions he absolutely fails in communication with people. This starts with the fact that he is known to actively maintain a quite long killfile (accompanied with the ability to ignore requests of people) and ends with the inability to accept critics to his person. While I have no personal problems to cope with those people I noticed that this behaviour of a person who is doing not only one important job for the project does harm to the Debian project in general. I had several private discussions with outsiders. For instance one opinion was that the persion would not apply as New Maintainer as long as James Troup is ruling Debian. (Please note: I do not think that James Troup is really ruling Debian - I was just quoting.) So what are your plans to enhance communication with people on important positions in Debian and how do you think that important jobs might be split onto different shoulders? 3. Do you think Debian should continue to support non-free? 4. Does your normal live allow sparsing time for Debian leadership which seems to include much additional work (perhaps you will not be able to continue on working on your packages) and does your current employer accept your intention. A. Meta-question: Do you know that your jpb as a Debian leader has the consequence to travel in several countries all over the world which might lead to the situation that some countries handle you like a criminal by taking your finger prints? I personally would not like to be handled like a criminal and thus I did not accepted the invitation to a conference in Texas. Thanks for supporting Debian by volunteering for leadership Andreas. PS: I have read the plans of each candidate and know that some of my questions are answered indirectly in some statements but I wanted to ask these question to each of you in the same manner. I do not mind if you answer any of these question via a link to a certain paragraph of your statements.
Re: Questions to candidates
On Tue, 2 Mar 2004, Martin Michlmayr wrote: > I think James is an excellent contributor to the project. I know him > personally, and I can assure you that he is not on a power trip. He > ... Well thanks for the clarification. I just want to make sure that this explanation is given to _everyone_ (not only to me) who might have doubt. My question was rather a concern to make sure to outsiders can see that Debian has no hidden secrets but can discuss his problems open. > something works as expected. You only notice when it suddenly breaks. > So if 95% of communication with James works well, we will never hear > about it. But we hear about the 5% which fails. Damn users ... this is always the same. ;-) > Having said this, I don't think the current non-free removal vote is > being done correctly. If we decide to remove non-free, we have to > provide a good upgrade plan for our users. Thus, I think we should > *first* move non-free to something like non-free.org, encourage people > to use new APT sources list while at the same time supporting the old > APT lines (i.e. still keeping it on Debian mirrors) for a while. Trick question: Do you plan to do this step before or after moving documentation with non-free licenses to non-free. ;-) > While I don't like these practices, I don't consider them off-putting > enough not to visit a country if there's a good reason to go there. > However, this has to be decided on a case by case basis. As far as I > know, EU citizens also don't have to get their finger prints recorded. While this is intended by the law I know that the practice might differ from case to case - but this is very off-topic here. That's why I named it "Meta-Question" and I do not really expected an answer. BTW, Brandon might come into the same trouble when entering Debconf 4 ... Kind regards Andreas.
Re: Questions to candidates
On Wed, 3 Mar 2004, Branden Robinson wrote [ Sorry if I do not answer right inside the thread but the "Reply to" links in the webform do not work as expected and I did not subscribed to the list. Please CC me, if you want to avoid this.] > I'm not sure I can give you the kind of answer you're looking for. Why do you expect me to look for a certain answer. I just had the feeling that some things should be discussed. According to my point of view asking questions is no expression of critics. > > While I think that he did a great job in terms of finding technical > > solutions he absolutely fails in communication with people. > > This is too broad a statement. You are right here (as well as tbm) and I would like to correct my wording to "he often fails in communication with a certain (and quite large) group of people". Sorry for the shortcut. If you ask me if it is more important to get work done or to leave work undone while working on communications skills I'd prefer the first. So I have no personal problems here which you might suspect when writing the first sentence I quotet from your mail. But Debien Leadership is no concern of personal feelings but representation to outsiders. I just wanted to make sure that the future DPL is able to explain things to outsiders the correct way. I just asked this question in reflection to some private mails I've got (and which point I do not really share). > On a more serious note, it's safe to say that there are certainly people > who have had trouble communicating with James in the past. There have > been people who had trouble communicating with Martin Michlmayr, too. > There have been people who had trouble communicating with me. It's hard to live in a real world. ;-) > > and ends with the inability to accept critics to his person. > > This is an overreaching statement. How can you know whether or not he > accepts criticism? That he reacts to it (or not), doesn't tell you what > he does with it internally. There is no open archive of debian-private but I have some mails stored in my private archive which leaded to this conclusion IMHO. Again - I have no personal problem with this as long as work is done fine - but the DPL might have to face this situation. > I think it is polite, to say nothing of expedient, to refrain from > speculating as to the psychological processes of our fellow developers > except as a last resort. But I might have been tricked out by the fact that psychological analysis can't hardly done by e-mail conversation and thus my assumption might be wrong here. > You're making pretty strong statements for someone who claims to have > not been personally mistreated by James. It's fine to be an advocate > for people who do feel that way, but I think such advocacy needs to > stick to objectively demonstrable facts. I pointed the person in question to this URL in the archive. He might comment on. I will not quote debian-private mails in public and so I can not demonstrate here what leaded me to the statements I did. > I am apprehensive about injecting real-world political opinions into > this particular discussion, so if you'd really like to know what I think > of the present U.S. administration, please ask in another forum. I did not want to inject real-world politics here. I know you from Oslo and I have no need to ask about your political opinion. I just wanted to know if the future DPL leader would have problems to travel to one or the other country which might be a constraint to his Debian related work. Kind regards Andreas.
Re: [BALLOT] Leader Election 2001
On 8 Mar 2001, Acting Debian Project Secretary wrote: > NOTES: > > [*] You must email your ballot from your debian.org email address. Hmmm, that might be the problem why my first E-Mail was rejected. But is this really necessary? All my E-Mail addresses are assigned to the key inside the debian keyring. I consider it to be hard to sign my key manually scp it to master and than mail it from there. The policy in our institute requires my internal address ([EMAIL PROTECTED]) as sender. If I'm the only one who is bothered by this requirement just forget it. If there are more people who don't like this "feature" we should try to change it if there isn't any security issue. Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: General Resolution: Handling of the non-free section
On Tue, 24 Feb 2004, Debian Project Secretary wrote: >Seconds: 1. Scott James Remnant [EMAIL PROTECTED] > > The next release of Debian will not be accompanied by a non-free > section; there will be no more stable releases of the non-free > section. The Debian project will cease active support of the > non-free section. Clause 5 of the social contract is repealed. > >Since this modifies the Social Contract, thsi requires a 3:1 majority > to >pass. > > >Seconds: 2. Sean 'Shaleh' Perry [EMAIL PROTECTED] > ... > 9. Scott James Remnant [EMAIL PROTECTED] Does Scott second both?? Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Questions to candidates
Hi, this morning I wrote in private to the DPL candidates but tbm asked me to foreward my questions to debian-vote which I'm doing hereby ... Here are my questions: 1. My concern is to propagate Custom Debian Distributions because I think we should set a stronger focus to the end user. I see Debian as a missing link between upstream developers and end users and Custom Debian distributions are a good way to care for end users. What are your plans according to Custom Debian Distributions? 2. Recently we had some flamewars about concentration of "power" for some people inside Debian. While I'm much more relaxed than many others and save my time for work instead of fighting flame wars I have one certain question here. How do you see the role of James Troup in the project? While I think that he did a great job in terms of finding technical solutions he absolutely fails in communication with people. This starts with the fact that he is known to actively maintain a quite long killfile (accompanied with the ability to ignore requests of people) and ends with the inability to accept critics to his person. While I have no personal problems to cope with those people I noticed that this behaviour of a person who is doing not only one important job for the project does harm to the Debian project in general. I had several private discussions with outsiders. For instance one opinion was that the persion would not apply as New Maintainer as long as James Troup is ruling Debian. (Please note: I do not think that James Troup is really ruling Debian - I was just quoting.) So what are your plans to enhance communication with people on important positions in Debian and how do you think that important jobs might be split onto different shoulders? 3. Do you think Debian should continue to support non-free? 4. Does your normal live allow sparsing time for Debian leadership which seems to include much additional work (perhaps you will not be able to continue on working on your packages) and does your current employer accept your intention. A. Meta-question: Do you know that your jpb as a Debian leader has the consequence to travel in several countries all over the world which might lead to the situation that some countries handle you like a criminal by taking your finger prints? I personally would not like to be handled like a criminal and thus I did not accepted the invitation to a conference in Texas. Thanks for supporting Debian by volunteering for leadership Andreas. PS: I have read the plans of each candidate and know that some of my questions are answered indirectly in some statements but I wanted to ask these question to each of you in the same manner. I do not mind if you answer any of these question via a link to a certain paragraph of your statements. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to candidates
On Tue, 2 Mar 2004, Martin Michlmayr wrote: > I think James is an excellent contributor to the project. I know him > personally, and I can assure you that he is not on a power trip. He > ... Well thanks for the clarification. I just want to make sure that this explanation is given to _everyone_ (not only to me) who might have doubt. My question was rather a concern to make sure to outsiders can see that Debian has no hidden secrets but can discuss his problems open. > something works as expected. You only notice when it suddenly breaks. > So if 95% of communication with James works well, we will never hear > about it. But we hear about the 5% which fails. Damn users ... this is always the same. ;-) > Having said this, I don't think the current non-free removal vote is > being done correctly. If we decide to remove non-free, we have to > provide a good upgrade plan for our users. Thus, I think we should > *first* move non-free to something like non-free.org, encourage people > to use new APT sources list while at the same time supporting the old > APT lines (i.e. still keeping it on Debian mirrors) for a while. Trick question: Do you plan to do this step before or after moving documentation with non-free licenses to non-free. ;-) > While I don't like these practices, I don't consider them off-putting > enough not to visit a country if there's a good reason to go there. > However, this has to be decided on a case by case basis. As far as I > know, EU citizens also don't have to get their finger prints recorded. While this is intended by the law I know that the practice might differ from case to case - but this is very off-topic here. That's why I named it "Meta-Question" and I do not really expected an answer. BTW, Brandon might come into the same trouble when entering Debconf 4 ... Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions to candidates
On Wed, 3 Mar 2004, Branden Robinson wrote [ Sorry if I do not answer right inside the thread but the "Reply to" links in the webform do not work as expected and I did not subscribed to the list. Please CC me, if you want to avoid this.] > I'm not sure I can give you the kind of answer you're looking for. Why do you expect me to look for a certain answer. I just had the feeling that some things should be discussed. According to my point of view asking questions is no expression of critics. > > While I think that he did a great job in terms of finding technical > > solutions he absolutely fails in communication with people. > > This is too broad a statement. You are right here (as well as tbm) and I would like to correct my wording to "he often fails in communication with a certain (and quite large) group of people". Sorry for the shortcut. If you ask me if it is more important to get work done or to leave work undone while working on communications skills I'd prefer the first. So I have no personal problems here which you might suspect when writing the first sentence I quotet from your mail. But Debien Leadership is no concern of personal feelings but representation to outsiders. I just wanted to make sure that the future DPL is able to explain things to outsiders the correct way. I just asked this question in reflection to some private mails I've got (and which point I do not really share). > On a more serious note, it's safe to say that there are certainly people > who have had trouble communicating with James in the past. There have > been people who had trouble communicating with Martin Michlmayr, too. > There have been people who had trouble communicating with me. It's hard to live in a real world. ;-) > > and ends with the inability to accept critics to his person. > > This is an overreaching statement. How can you know whether or not he > accepts criticism? That he reacts to it (or not), doesn't tell you what > he does with it internally. There is no open archive of debian-private but I have some mails stored in my private archive which leaded to this conclusion IMHO. Again - I have no personal problem with this as long as work is done fine - but the DPL might have to face this situation. > I think it is polite, to say nothing of expedient, to refrain from > speculating as to the psychological processes of our fellow developers > except as a last resort. But I might have been tricked out by the fact that psychological analysis can't hardly done by e-mail conversation and thus my assumption might be wrong here. > You're making pretty strong statements for someone who claims to have > not been personally mistreated by James. It's fine to be an advocate > for people who do feel that way, but I think such advocacy needs to > stick to objectively demonstrable facts. I pointed the person in question to this URL in the archive. He might comment on. I will not quote debian-private mails in public and so I can not demonstrate here what leaded me to the statements I did. > I am apprehensive about injecting real-world political opinions into > this particular discussion, so if you'd really like to know what I think > of the present U.S. administration, please ask in another forum. I did not want to inject real-world politics here. I know you from Oslo and I have no need to ask about your political opinion. I just wanted to know if the future DPL leader would have problems to travel to one or the other country which might be a constraint to his Debian related work. Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Yet another list statistics for debian-vote
Hi, as you can read in my lightning talk at DebConf http://people.debian.org/~tille/talks/200808_lightning/ I did some investigation on who is frequently posting on our mailing lists. I now created graphs until end of last year and write a short summary for those lists I regard worth a comment. I'm not CCed to all of this list so if you want to discuss something please keep me in CC. If you want to discuss the results in general just write to debian-project. All graphs and the code that was used to create the graphs are available at http://people.debian.org/~tille/liststats/ If you are interested in a mailing list which was not analysed, just tell me. I was running the scripts on those lists I personally had some interest and those with more than 1000 subscribers. I plan to clean up code and write some doc about it but this will not happen in the next couple of weeks. The graph for this specific list is --- -- http://people.debian.org/~tille/liststats/authorstat_vote.pdf Here we can see the active voting years ... Kind regards Andreas -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Questions about "Winding down my Debian involvement"
Hi to all brave candidates, thanks to you all to volunteer for the DPL job. I wish you all good luck for the elections and the future DPL my best wishes. 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. Besides your general opinion I'm interested in your opinion about some questions that immediately popped up when reading the article. 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.) 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. Kind regards Andreas. PS: I'm not subscribed and while I feel able to read the archive I'd be happy about CCing me. [1] https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ -- http://fam-tille.de
Re: Questions about "Winding down my Debian involvement"
Hi Sam, thanks a lot for your fast reply. On Wed, Mar 20, 2019 at 06:17:00AM -0400, Sam Hartman wrote: > I have read it as well. (I forgot to mention that Martin has obviously read it since it was even linked in his platform. :-) ) > ... > I am disappointed when people leave bitter and disheartened. > I specifically talked about my hopes for reducing that and addressing > some of the decision frustration in my platform. +1 > I'd be happy to drive that discussion if elected DPL. > Could I count on your support in helping write up some of the > explanations of why actually having a policy that anticipated debhelper > would benefit people who work on multiple packages? Yes, you (or whoever wants to takle this) have my support. > Now, I cannot promise a particular outcome: that's for the project to > decide. However, I think even coming tho closure and learning that we > don't want to mandate debhelper >9 would be a huge win. We'd hopefully > learn why people feel that way and we would have closure. ACK. > Andreas> 2. I consider packaging in Git on salsa.debian.org a big > Andreas> move forward to some unified workflow for Debian packaging > Andreas> (thanks to Salsa admins by the way). Do you see any chance > Andreas> to convince maintainers to maintain their packages on > Andreas> salsa.d.o as a recommended development platform. > > That's another discussion I'm interested in driving. > This one was already on my "I bet we want to spend some time there" > list. > I think that discussion will be more involved than the debhelper > discussion. I admit I do not have any idea what discussion will be more involved but I guess both will be tough and I hope a lot of fans of Nonviolent Communication will join. > I'm not going to go into a lot of specifics on how I'd drive that > discussion though. I think I still need to do some of my homework and > talk to people who have driven part of that discussion in the past. I > also think getting to stuck in the details is not the point of the > campaign period. ACK. Thanks again Andreas. -- http://fam-tille.de
Re: Questions about "Winding down my Debian involvement"
Hi Joerg, On Wed, Mar 20, 2019 at 04:17:51PM +0100, Joerg Jaspert wrote: > More unification > in central parts, with the biggest part being packaging, is better. That's actually my point. > 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. Fine for NEW stuff. I could also imagine exceptions for *really* complex stuff. I fail to see any reason why to refuse a patch turning rules to dh for those simple packages just out of personal preference. My point is to stop random personal preferences overriding team maintainable packages that do not have any specific requirements. > > 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). Sounds good but that's one step ahead. > Aside that, yes, the more stuff is similar, the better and easier larger > changes can be done. I'd wish I hat 10 votes to say: +10 > Though salsa or not is a small point here. I'd consider it a first step. > How many > different ways of maintaining a package in git do we have by now? We have migrated a lot of packages from Alioth to Salsa. It would have been a good idea to fix the repository layout before - but that has not been done. I've seen team maintained packages where every single repository I was looking into was slightly different from other packages of the same team. IMHO we should accompany Debian Policy which only covers the user installation view by a Debian Development Policy that focusses all those different options to some convergent way to maintain packages and enables me filing bug report about "Not maintained in Git", "Unusual repository layout", "Not using dh" etc. > 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). Yes, that's my point. DPL could trigger this kind of discussion. Kind regards Andreas. -- http://fam-tille.de
Re: Questions about "Winding down my Debian involvement"
On Wed, 20 Mar 2019 Martin Michlmayr wrote: > At the very least, we should find out why people don't use standard > tooling like debhelper, improve these tools and nudge people towards > them. How would you approach this nudging? > We should definitely recommend it. The question is whether we should > go further than that. Where should we recommend it? What do you think about a "Debian Development Policy" (the more I think about that term which I used in my last mail the more I like it)? Kind regards Andreas. -- http://fam-tille.de
Re: Questions about "Winding down my Debian involvement"
On Wed, 20 Mar 2019 Martin Michlmayr wrote: > (I haven't looked at rsync and this is a general reply.) > > First, find out *why* it's non-standard. Mabye there are good > technical reasons. If so, solutions can be found (e.g. improvements > to debhelper). Maybe it's a case of "it works" and the developer > doesn't want to spend the time to change? If so, you could provide a > patch. Maybe there is unfamiliarity or doubts about debhelper? In > thast case, some explanations or illustrations might help. etc Quoting the article[1]: Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference. No idea whether Michael might reply but CCing him anyway for clarification. I've checked src:rsync in BTS but did not found anything. > I think was thinking the Debian Developer's Reference would be the > appropriate place. > > I also like the term "Debian Development Policy" fwiw. That's the point: For me a reference is a set of suggestions that might be helpful or not. A policy is something we agreed upon and strive to accomplish by using tools like lintian whether something is compliant or not. We could also file bug reports if something is in conflict with that policy. Kind regards Andreas. [1] https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ -- http://fam-tille.de
Re: Questions about "Winding down my Debian involvement"
On Wed, Mar 20, 2019 at 11:13:58PM +0200, Jonathan Carter wrote: > I'm sorry if that's not the answer you were looking for, but that's how > I generally feel about it. I wasn't looking for specific answers. I was just interested in your opinion. ;-) There are different kind of texts in this direction. I simply think this was one that is worth discussing (in contrast to others). > > Besides your general opinion I'm interested in your opinion about some > > questions that immediately popped up when reading the article. > > > > 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.) > > Just checked out that file, and at 98 lines, it's really not that bad > for a really old pre-debhelper-7 style makefile: > > """ > Language Files CodeComment Comment % Blank > - - - - - > make 1 98 18 15.5% 15 > - - - - - > Total 1 98 18 15.5% 15 > 131 > """ > > I've recently adopted packages with worse make files than that and > successfully converting them wasn't too hard. I think the point of the writer which is perfectly in line with mine is not whether the file itself is good or bad. The point was that the maintainer actively refused modernisation due to personal taste. If we think about Debian as a team of 1000+/-x people some specific personal taste can block a lot of good movements. I'm speaking explicitly about my experiences in a way smaller team where several modernisations were initialised by new members and I as the longest standing member of the team adopted modern things. > So, to answer your question, I do think having a wide discussion and > then some final decision for it scheduled would be useful. I wouldn't > want to force dh9+ per sé (people still use CDBS and are apparently > happy with it), but I do agree those old style makefiles are holding us > back. I do not want to turn this into a cdbs to dh flamewar. Before dh 7 Debian Med policy mentioned cdbs explicitly. We moved away to dh now. I'm pretty sure the rsync maintainer would have refused a patch to convert to cdbs as well. Several teams inside Debian have agreed to team policies recommending modern tools to simplify the life of all team members. I'd love to see something like this for the Debian Developer team as a whole. > I think a good way to go about it would be to propose that we have a > recommended (not necessarilly required) set of supported build systems, > and make it a release goal that we update all those really long make > files to anything more modern, supported and easy to work with (well, > basically debhelper :) ). If there would have been any answer I was looking for than it was this one. ;-) > There's an idea I've been playing with in my head for the last few days, > I call it "Fixer teams". These are teams of people that exist for a > small amount of time to achieve a goal and then they disband. > > For example, we'd establish a fixer team that can help people who want > to convert their old-style make files all the way to a modern debhelper, > we do a call for volunteers for that team, and then announce it > somewhere like d-d-a. The fixers can either check irc/mail for people > who request this help, or they could check a bug list and recommend a MR > on GitLab. Whether I'm DPL or not (or a fixer or not), I'm happy to help > anyone who would like to update their package in the meantime. Sounds like an interesting idea. You are talking about the people who *want to convert*. Can you please be more explicit what to do in cases where people: 1) Who explicitly do not want any change. 2) Do not respond (but beeing not officially MIA) (I'm explicitly not "looking for a certain answer I want to hear" - I'm just seeking for good ideas.) > > 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. > > Yes! I do think GitLab/Salsa is one of the best things to have happened > to Debian in recent history. I posted a blog post that touches on some > salsa topics earlier tonight: > > https://jonathancarter.org/2019/03/20/gi
Re: cdbs vs dh vs ...
Hi Lucas, On Thu, Mar 21, 2019 at 09:14:09AM +0100, Lucas Nussbaum wrote: > On 21/03/19 at 08:38 +0100, Andreas Tille wrote: > > > > I do not want to turn this into a cdbs to dh flamewar. May be I failed despite (or because??) I stated it explicitly? I've set "Reply-To" to debian-devel and please if this should be really discussed lets move it there. I'm adding Jonas Smedegaard (as far as I know the only active developer - Jonas please correct me if I'm wrong but Git commits are basically from you) to comment on this topic. Jonas, I remember on one of the DebConfs in the last three years (forgot which one) you told me about your plan about cdbs. May be that's the right moment to comment here. Kind regards Andreas. > > Before dh 7 > > Debian Med policy mentioned cdbs explicitly. We moved away to dh now. > > I'm pretty sure the rsync maintainer would have refused a patch to > > convert to cdbs as well. Several teams inside Debian have agreed to > > team policies recommending modern tools to simplify the life of all team > > members. I'd love to see something like this for the Debian Developer > > team as a whole. > > I think that we lack data about such evolutions (see > https://www.lucas-nussbaum.net/blog/?p=945 about solving that) > > According to lintian data, the current status is: > > udd=> select information, count(*) from lintian where > tag='debian-build-system' group by information order by 2 desc; > information | count > --+--- > dh | 24400 > cdbs-with-debhelper.mk | 2010 > debhelper| 1942 > dhmk | 227 > cdbs-with-debhelper.mk, debhelper| 155 > other| 116 > debhelper, dhmk | 9 > cdbs-without-debhelper.mk| 8 > cdbs-without-debhelper.mk, debhelper | 4 > (9 rows) > > (see also https://anarc.at/blog/2019-02-05-debian-build-systems/ ) > > I uploaded a list with maintainers and packages at > https://blop.info/pub/helpers.txt > (generated with > > select information, maintainer, count(*), array_agg(source) > from sources inner join lintian on sources.source = lintian.package > where tag='debian-build-system' > and information != 'dh' > and release = 'sid' > group by information, maintainer > order by 3 desc; > ) > > Looking at the list, it seems that outside of some teams that > standardize on tools that do not use dh directly (Haskell, Qt/KDE), and > teams that have not yet migrated everything to a new tool (Perl, Java, > OCaml), there's mainly a long tail of packages that are probably quite > outdated. > > The difficult question (not really for the DPL candidates, but they can > answer it ;) ) is: how do we decide that dh is the recommended practice, > and that non-recommended practices get a lintian warning? > > Lucas > -- http://fam-tille.de
Re: Discussion on eventual transition away from source packages
Hi,
+1 for the suggestion of Lucas
-1 for discussing this on debian-vote making it hard to find later
Reply-To set to debian-devel.
Kind regards
Andreas.
On Thu, Mar 21, 2019 at 06:21:15PM +0100, Lucas Nussbaum wrote:
> On 21/03/19 at 16:52 +, Ian Jackson wrote:
> > Joerg Jaspert writes ("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?
> >
> > If we were to abolish the part about uploading traditional source
> > packages, what remains of `dgit push-source' is simply pushing a
> > signed git tag with a conventional name to a designated server, and of
> > course pushing the corresponding commits to a designated git branch.
> >
> > (There is a dgit-infrastructure package which knows how to verify
> > these tags and do the access control for the designated per-suite git
> > branch in the right way: specifically, in an identical way to the
> > existing Debian archive.)
> >
> > In this scenario most of dgit would no longer be needed, because
> > dgit's primary function is to gateway bidirectionally between source
> > packages and git branches.
> >
> > `dgit push-source' (which has frantic paddling ill-concealed beneath
> > its fairly friendly exterior) would be replaced by a tiny shell script
> > in devscripts to do a few checks and then help you make the right tag
> > name and push it to the right place. [1]
> >
> > That place would not be the main salsa master branch of course,
> > because for the reasons you give, because we don't intend to abolish
> > *binary* packages. So there needs to be an explicit developer action
> > to declare a particular set of source code as the one to build binary
> > packages from, for testing and distribution to Debian's users. That
> > explicit developer action would consist principally of making a
> > suitable PGP signature, as now - except the signature would be on a
> > git tag, rather than a .dsc and .changes.
> >
> I think that it would be great to avoid a schema where we have two git
> repositories: the one on the ftp-master side (~ the dgit one), and the
> one on salsa managed by the team. And where the developer has to
> explicitely git push to both locations, and where both locations are
> somehow exposed to users.
>
> 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.
>
> Lucas
>
--
http://fam-tille.de
Re: Discussion on eventual transition away from source packages
So you really insist in hiding this interesting topic on debian-vote rather to switch to debian-devel? Reply-To was set again to debian-devel ... On Fri, Mar 22, 2019 at 09:32:55AM +0100, Lucas Nussbaum wrote: > On 21/03/19 at 18:57 +0100, Joerg Jaspert wrote: > > Also, it will be a drastical change and has many far reaching > > consequences and needs lots of work nefore we are near it. > > I'm probably missing something, but it doesn't sound like a lot of work > to me? It's "just" a service that: > - gets notified of the existence of a git repo + tag to upload > - fetches that git repo + tag > - checks signature / confirm that the GPG key owner is allowed to upload > that package > - build a Debian source package > - uses a slightly different path to accept the source package (because > the .dsc and .changes wouldn't be signed) > > This could exist in parallel to the current upload scheme. > > And it's a terrible idea, but it could even be implemented as a > third-party service, run by a DD that would do that and sign+upload the > source package using the DD's own GPG key. > > Lucas > -- http://fam-tille.de
Re: Questions about "Winding down my Debian involvement"
Hi Jonathan, [sorry for frequently breaking the thread - I'm answering to web-archive] On Wed, 20 Mar 2019 Jonathan Dowland wrote: > Imagine you had a team that, > within the team, had standardised on (say) SVN and cdbs. Whenever that > team picked up a new package, they then used SVN and cdbs for it: > because that was then consistent for the packages within the team. That was the Debian Med team until some point in time - very simple to imagine. :-) However, long long time ago some team members were asking for acceptance to use Git in favour of SVN. The policy of the team was not to stop engaged packagers who want to use more modern tools. Since a long time we allowed SVN and Git as VCS. I even myself used both options depending from the type of package. After the decision for Gitlab I converted probably more than 250 packages from SVN to Git. I did the same for several packages in Debian Science team (which also permitted SVN and Git). The move from cdbs to dh was done several years ago. When we have put cdbs into our team policy it was a great enhancement. The conversion to dh was usually pretty simple. The only reason to stick to cdbs was if some language specific build system was relying on this. For instance GNU R packages were build using a cdbs helper. However, once the helper was ported to dh we re-uploaded all GNU R packages (now in the r-pkg team). What I want to express is: Packaging is not a static thing and tools move on. A functional team should be able to adapt and modernise the used techniques. Packages usually need to be adapted to new Standards-Versions and new tools (like gcc versions, Python3 etc.) So usually there are several good reasons to re-upload packages and when doing so a (working) team has good reason to review the packaging techniques. Kind regards Andreas. -- http://fam-tille.de
Re: Questions about "Winding down my Debian involvement"
Hi Michael, On Wed, Mar 20, 2019 at 10:43:06PM +0100, Michael Stapelberg wrote: > The rsync discussion happened in private mail, so there’s no paper trail of > that, sorry. > > I did supply a patch, as described in the article, and the maintainer > refused it. BTW, this is a good example that its a good idea to have all conversation online - for instance it would have been great to have a wishlist bug report with your suggested patch. (It would make sense even now to submit a tested patch for d/rules of rsync.) Kind regards Andreas. -- http://fam-tille.de
Re: Second Call for votes: General resolution: Sarge Release Schedule in view of GR 2004-003
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 25 Jun 2004, Debian Project Secretary wrote: > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > [ ] Choice 1: Postpone changes until September 2004 [needs 3:1] > [ ] Choice 2: Postpone changes until Sarge releases [needs 3:1] > [ ] Choice 3: Add apology to Social Contract [needs 3:1] > [ ] Choice 4: Revert to old wording of SC[needs 3:1] > [ ] Choice 5: "Transition Guide" foundation document [needs 3:1] > [ ] Choice 6: Reaffirm the current SC[needs 1:1] > [ ] Choice 7: Further discussion > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > -- > The responses to a valid vote shall be signed by the vote key created > for this vote. The public key for the vote, signed by the Project > secretary, is appended below. > -- Remark: The ballot is left blank intentionally because I want to express that I feel incompetent to decide between the options given. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5PsAYDBbMcCf01oRAq/aAKCzy24bH6Xu9lpjhnwoF3AuOL7/FgCfSxhF hSmF/6MfyyyZPdjPn45uX0k= =Aj3j -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Tue, 13 Jul 2004, Josselin Mouette wrote: > recognizing that the AMD64-based architectures are likely to become the > most widespread on personal computers and workstations in a near future, Well, this is kind of to strong wording. I'd replace "most widespread" by "common" - which is important enough to second to all you wrote. > and acknowledging that its users want to take advantage of all this > architecture's features, I'd strongly second that because several users asked for it on the exhibition booth at LinuxTag. IMHO our users deserve that we respect this. > With our current release timeframe, AMD64 is likely to become the most > sold architecture for personal computers way before the release that > will follow sarge. As stated above "the most sold" is also quite strong - "a very common" would be more serious. > If we don't release sarge with AMD64 support, our > users will be very disappointed. ... a noticeable amount of our users ... > The popularity of the debian-amd64 > project just shows what they are waiting for. Seconded. > I'm looking for seconds for this proposal, Done Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Status Quo and the Current Ballot
On Thu, 12 Oct 2000, Hamish Moffatt wrote: > two real results: > * keep non-free, > * remove non-free IMHO this should be offered to a vote-ballot: [ ] keep non-free, [ ] remove non-free Just mark what you want. I can't imagine why whe don't say clearly what the thing is. Just my two cents Andreas.
Re: [BALLOT] Leader Election 2001
On 8 Mar 2001, Acting Debian Project Secretary wrote: > NOTES: > > [*] You must email your ballot from your debian.org email address. Hmmm, that might be the problem why my first E-Mail was rejected. But is this really necessary? All my E-Mail addresses are assigned to the key inside the debian keyring. I consider it to be hard to sign my key manually scp it to master and than mail it from there. The policy in our institute requires my internal address ([EMAIL PROTECTED]) as sender. If I'm the only one who is bothered by this requirement just forget it. If there are more people who don't like this "feature" we should try to change it if there isn't any security issue. Kind regards Andreas.
Re: Debian Status Quo and the Current Ballot
On Thu, 12 Oct 2000, Hamish Moffatt wrote: > two real results: > * keep non-free, > * remove non-free IMHO this should be offered to a vote-ballot: [ ] keep non-free, [ ] remove non-free Just mark what you want. I can't imagine why whe don't say clearly what the thing is. Just my two cents Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2025: Call for nominations
Hi Kurt, Am Sat, Mar 08, 2025 at 11:26:41AM +0100 schrieb Debian Project Secretary - Kurt Roeckx: > Please make sure that nominations are sent to (or cc:'d to) > debian-vote, and are cryptographically signed. I'd like to nominate myself for another term and appreciate anyone else stepping forward to run for DPL as well. You can find my platform online at https://people.debian.org/~tille/dpl-platform/ or in Git (see bottom line of this text). Kurt, thanks a lot for serving as Debian Project Secretary and just let me know what format you prefer. Kind regards Andreas. -- https://fam-tille.de signature.asc Description: PGP signature
Re: Q to nominees: Rough plan on Debian/Ubuntu collaboration?
Hi, Am Sun, Mar 16, 2025 at 03:31:26PM -0400 schrieb M. Zhou: > I noticed that a half of the nominees mentioned strengthening the > collaboration between Debian/Ubuntu. Although I belong to "the other half," I'd still like to share my perspective. I personally have never had a reason to work on anything other than Debian. This is not because I do not appreciate the work of other distributions-whether Ubuntu, another Debian derivative, or something entirely different. Rather, it is simply a matter of efficiency for me to stick to what I know best. I have never subscribed to a "Debian is better than XY" mindset. For me, it has always been: "Debian is better **for me** than XY because it solves **my** problems, and I am extremely efficient with it since I know it in a depth I could never achieve with XY." This has, in some ways, led to a certain "ignorance" in my relationship with other Linux distributions in the past. However, as I wrote in my platform last year[1] under the title 'Reaching Out to Learn', I have since attempted to foster more outreach. I answered the call for papers at both FOSDEM and FOSSASIA with the following proposal: Cross distribution experience exchange As Debian Project Leader, I have often reflected on how other Free Software distributions address challenges we all face. I am interested in discussing how we can learn from each other to improve our work and better serve our users. Recognizing my limited understanding of other distributions, I aim to bridge this gap through open knowledge exchange. My hope is to foster a constructive dialogue that benefits the broader Free Software ecosystem. Representatives of other distributions are encouraged to participate in this BoF-whether as contributors or official co-speakers. My intention is not to drive the discussion from a Debian-centric perspective but to ensure that all distributions have an equal voice in the conversation. This was my way of "sticking to a promise" I made in my platform. Guess what? The proposal was rejected by both conferences. Perhaps I approached it the wrong way-maybe I should have reached out to other distributions first and submitted a joint proposal. Or perhaps there simply isn't much interest in such an exchange. (That said, I have participated in similar discussions at DebConf, where we engaged with derivatives, and I found those conversations valuable.) As for our derivatives, I am deeply convinced that all our direct and indirect users-whether they use Debian itself or one of its derivatives-benefit the most when downstream changes flow back upstream into Debian. I strongly support making this process as easy as possible. > Would you mind expand a little > bit on this, like the rough idea? In particular: > > * What problem needs to be addressed regarding Debian/Ubuntu collabration? While I absolutely believe we should enhance collaboration with Ubuntu-arguably our most successful derivative-I would not limit the effort to just Ubuntu. As I tried to express above, I think the first step is simply to start talking to each other, which often seems to be a challenge in the IT world. > * Rough idea on how the identified issue can be addressed? Unfortunately, not at the moment, as I've already admitted that I lack knowledge in this area. However, I am open to any sensible advice on how to support good cooperation. > Generally I find the DDPO page's Ubuntu column quite helpful. > Sometimes I can see Ubuntu has some patches, but not forwarded > to Debian. Some of these changes can indeed be merged into Debian, > and I did this multiple times. I can confirm that I have a personal policy of applying patches from any derivative within a 24-hour timeframe and uploading them as soon as possible. If these patches come through the BTS or as merge requests, I am more than happy to assist. This is my perspective as a developer. However, if there are ways I can contribute to this process in my role as DPL, I would be glad to help. > Long answers are not necessary. I just want to understand the brief > motivation and goals. Apologies for the lengthy responses. I believe my answers provide insight into my approach to collaboration with other distributions, which may still be of interest. Kind regards Andreas. [1] https://www.debian.org/vote/2024/platforms/tille -- https://fam-tille.de
Re: Q to all nominees: What plan do you have for Debian finances?
Hi Hector, First of all, thank you to you and the other treasurers for carrying out such high-responsibility work that our common project depends on. Your efforts are highly appreciated, and I'm grateful that others take on this role, as I personally would not volunteer for it. Am Sun, Mar 16, 2025 at 08:14:29PM +0100 schrieb Hector Oron: > Hello all, > > Congratulations for all the nominations and thanks for stepping up for this > challenging role. > > I follow up with a couple questions for you: > > 1. Do you know how were Debian funds spent last year(s)? Do you know how > much yearly income Debian has? As Julian mentioned, I do have some advantage in answering this question. However, rather than focusing on what I personally know, I think it is more useful to consider how everyone could more easily access and understand this information. What I can say is that there are monthly reports from SPI, though they are admittedly difficult to interpret. Thanks to the work of Hector and the other treasurers, I have access to graphs illustrating the development of our funds, though I believe these are not publicly available. So instead of simply answering whether I know Debian's yearly income, I'd rather focus on whether we should improve the transparency and readability of financial information-at least for Debian members, if not for the general public. Ideally, the information should be presented in a way that enables anyone interested to answer these questions without needing special access or prior financial expertise. Understanding Debian's financial situation is essential for the DPL, as one of the DPL's responsibilities is making decisions on funding requests. However, it is important to emphasize that the actual financial management-including tracking income, expenses, and reporting-is handled by the treasurers. Their work ensures that Debian's finances are well managed and accounted for, and the DPL relies on their expertise to make informed decisions. For a long time, financial decision-making was relatively straightforward. In his Bits from the DPL talk, Neil once mentioned at DebConf15 that he approved every single funding request he received, and Debian's financial reserves still grew during his term. Unfortunately, these simpler times seem to be over, and the need for careful financial planning has increased. I'd love to be in Neil's shoes, and I hope that future DPLs will see those times return. > 2. If elected DPL, how do you plan to use Debian funds? Which areas > (social, events, I'm not sure how meaningful it is to separate "social" and "events" since any gathering of more than two people inherently has a social component. While technical needs often drive in-person interactions, all our meetings-whether among Debian contributors at (Mini)DebConfs, team sprints, bug squashing events, or release parties-also have an important social aspect. Likewise, representing Debian at broader events such as FOSDEM and FOSSASIA (as international examples) or local ones like Chemnitzer LinuxTage (just to name a few current examples) is, in my view, highly valuable. I would support all these activities as best as our funds permit. > hardware, etc) When it comes to servers maintained by DSA, it seems obvious to me that we should follow the recommended hardware refresh cycle to keep our infrastructure at a modern and reliable level-ensuring that Debian remains what it is. Fortunately, much of our hardware, as well as rack space, is donated or made available at a reduced price. I sincerely hope that our financial situation will always allow us to maintain this without having to make cuts. Sometimes we also support DDs in buying in some way "interesting" hardware, be it open hardware like MNT Reform[1] or to some extend consumer ready RISC-V hardware like Frame.work with RISC-V board. For me it makes perfectly sense to make sure Debian runs on alternative hardware which to some extend matches our values and I would support if Debian developers will make sure that we can support our users who are interested in it. > would you prioritise spending? I do not think it makes sense to imagine hypothetical conflicts between different spending categories like "social" and "hardware." Decisions on spending should be made on a case-by-case basis. What I can say is that I will continue to apply Debian's high standards when making these decisions. Moreover, I can confirm that whenever I have faced important decisions, I have always sought advice from Debian developers who I consider knowledgeable in the relevant area. Looking back, this has always been a good approach, and I intend to stick to this habit. In short: For complex financial decisions, I will consult the treasurers first and also speak with those directly affected by the decision. > Do you have > ideas for improve fundraising (if you think this is needed at all)? I do not think improving fundraising is merely an option-it is a necessity if we
DebConf (Was: Questions for all candidates)
Dear Jonathan, Am Mon, Mar 17, 2025 at 03:01:38PM +0200 schrieb Jonathan Carter: > 3. DebConf > > DebConf is great. I hate the process of getting a visa to travel (often at > least a whole day's worth of admin), and I don't like airports or travel by > plane (which is usually at least two days in each direction). And yet, I > sacrifice about 1% of my year just to get to DebConf, because it's worth it. Thanks you for putting it in these words which I can't do better. > Often though, I feel like DebConf can be better. My biggest wish is to have > more core Debian people there. Often, sessions are planned to discuss really > important and crucial things, but then we don't have the key people present > to really dig into it and bring it forward. At some point I've wondered if > we should invite-by-default certain members of certain teams. Make it clear > that there will be travel and accommodation and food for them if they want > to come. It might not be enough to convince people with children or other > commitments at home, but perhaps it could help a little. I completely understand what you mean. In an ideal world, we could bring all relevant people together in one room, make decisions, and implement them seamlessly. If you're asking whether I have an idea on how to get closer to that ideal within a volunteer project-honestly, I don't. However, I'm very open to discussing potential approaches. > I digress, this isn't about my gripes with DebConf, it's about yours. What > do you think are the biggest problems with DebConf, and if you had a magic > wish or two as DPL to change things, what would that be? If I had a magic wish, I'd use it to bring all the key people into one room-ideally without internet distractions-to focus on urgent issues. But since I don't believe in magic, I know this isn't realistic. To focus on realistic goals: I'd love for more sponsors to recognize the value of our yearly conference and local MiniDebConfs, enabling us to reach more underrepresented groups in Debian. We could likely improve in finding additional support. Ideally, I'd like to lower the threshold for accepting promising contributors, rather than being constrained by financial limitations. See you at DebConf Andreas. -- https://fam-tille.de
Colour of installation media (Was: Questions for all candidates)
Dear Jonathan, this is my last chunk of answers where I'm basically bundling question topic 4. and 5. Am Mon, Mar 17, 2025 at 03:01:38PM +0200 schrieb Jonathan Carter: > 4. Installation media > > It's amazing how much Linux distributions offer in the variations of > installation media (like ISO images) they provide. > > For example, Ubuntu differentiates between a Desktop and Server installation > image. OpenSUSE too and they also have LEAP (a rolling release) and some > distributions also offer immutable install options. In Debian we offer the > netinst iso as the default from our home page, with a link that leads to > larger installation images, live images and cloud images. > > Do you have any opinion on the selection of images that we provide? Is it > optimal? Can we do better? I admit I don't have a strong opinion on this. What matters most is that our images work flawlessly and are easy to use. I often point to my own experience: I once installed Debian in a language I don't understand (Vietnamese) and succeeded without issues-this is my usual response to those who claim Debian is hard to install. In short, I trust the experts who have consistently done a great job. > Are there features that you would consider > missing? I've been wishing for the ability to install and advertise Blends for the last 25 years. It looks like with Trixi, this will finally happen, and that's great news for me! It's another example of how "good things come to those who wait." That said, while I'm really happy with the progress, this has nothing to do at all with my current DPL position. As always, it takes a dedicated volunteer to implement such feature. > 5. Favourite colour > > Ok, I lied, here's an easy question for you, what's your favourite colour? Well, that's not an easy question at all, especially after watching this video: https://www.youtube.com/watch?v=r0jXfwPQW9k My answer is probably: It's a colour I have no name for and thus can't truly see. I would have loved to share a similar video in English or find a sensible translation. It's one of the most mind-boggling videos I've ever watched. > I haven't even read all your platforms yet, so I'll probably post some more > pesky questions later on. Happy to answer more questions. > I hope you have fun during the campaign period! Thank you, your questions were part of the fun. Kind regards Andreas. -- https://fam-tille.de
Community Team (Re: Questions for all candidates)
Dear Jonathan, Am Mon, Mar 17, 2025 at 03:01:38PM +0200 schrieb Jonathan Carter: > Firstly, thanks for stepping up for running for DPL. Says someone who's been serving for four terms in a row. ;-) (And I'd like to take this chance to thank you for that as well.) Thank you for your many questions. I believe they can be better addressed in separate threads, so I’ve split my responses accordingly by adding the topic to the subject line. I hope this works for you. > 1. Community Team > > How do you feel about the Community Team? We have agreed on a Code of Conduct, which, in my opinion, is essential for large communities. It defines rules, and whenever rules exist, someone must ensure they are upheld. This is similar to referees in a soccer game. Like referees, our Community Team members are human and therefore not perfect. However, I am absolutely convinced that things will not work unless players are reminded of the rules. >From my past experience as a DD and DPL, I consider the Community Team to be a highly valuable part of Debian. As our community grows, it becomes essential to ensure that members remain aligned with our shared values, and the Community Team plays a crucial role in this. I highly appreciate their work and dedication. If I knew of a better solution, I would certainly share it, but for now, I believe the Community Team's approach is vital for our continued success. > Is there something you would change? > > Do you have any ideas in how to support them so that they can help our > community better? I'd like to address both questions together, as I see them as closely related. As with any volunteer, community members in Debian often face real-life constraints that can interfere with their volunteer work. Additionally, many of them may encounter challenges they didn't expect when they first joined Debian. This can lead to burnout, especially for those in the Community Team, who are giving their time selflessly. We must not take our volunteers for granted. They might face challenges that can lead to burnout. It is essential that we offer them the support and appreciation they need to continue their valuable work for our project without sacrificing their well-being. As I mentioned in my email about Debian funds[1], I'm deeply convinced that we should reach out to non-IT professionals who might bring their specific skills to Debian in ways that we might not have considered. In the specific case of the Community Team, this could help provide a fresh, IT-neutral perspective. So, if you ask me what I would like to change: consider involving non-uploading DDs with specific roles in the Community Team, to help address the challenges I mentioned above. > I hope you have fun during the campaign period! Looks like fun thanks to your questions. ;-) Kind regards Andreas. [1] https://lists.debian.org/debian-vote/2025/03/msg00042.html -- https://fam-tille.de
VCS (Was: Questions for all candidates)
Dear Jonathan, I'm continuing with your next set of questions for the topic VCS. You can find my answer about the Community team question here[1]. > 2. VCS > > Salsa has been stable for a number of years now, and git is clearly a good > choice of default VCS (even though not perfect or preferred for all). > > How do you feel about VCS requirements in Debian? Should it be required that > Debian packages are maintained in Salsa? It should be required that Debian packages are maintained in VCS (which these days is synonymous with Git) and hosted on a unified development platform. Currently, that platform is Salsa (formerly we had Alioth with the restrictions that made us move away), and if someone develops an alternative that addresses the concerns raised about our GitLab instance, I'd be open to considering it. But for now, our goal should be to host all packages on Salsa since this has proven to be fine in production. If you ask whether this can realistically be accomplished within the next DPL term, my answer is a clear no. I am well aware of the discussions and the objections raised against this plan. However, I believe the benefits far outweigh the drawbacks. These include easier collaboration, especially for newcomers, better tooling for large-scale package changes, greater consistency across Debian packaging, and CI testing. For now, I will focus on migrating packages that remain outside Salsa _for_ _no_ _good_ _reason_-for instance, cases where the maintainer is inactive, and nobody truly cares. Last year I used some UDD query[2] udd=> SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ; 2368 At that time, I stated that I would like to reduce the latter number below 2000. As of today, it stands at 1653. However, it was later discussed [3] that the old query was incorrect. I have proposed a new query [4] that should accurately identify all affected packages: udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND (vcs_url IS NULL OR vcs_url like '%alioth.debian.org%' OR vcs_url like '%git.debian.org%' OR vcs_url like '%svn.debian.org%' OR vcs_url like '%anonscm.debian.org%') ; count --- 2509 At the time of writing this query to the list 2025-01-08 this number was 2930. So something happened in the last 2.5 months and I intend to continue with this. I want to repeat what I stated very clearly last year: If you do not believe that all Debian packages should be maintained on a common Git-based platform, then you should not vote for me. I will not achieve this transition within a single year, but I am committed to paving the way toward it. > How do you feel about dgit As long as dgit is seen as just another interface (like gbp), I'm perfectly fine with it. Ultimately, the choice depends on your workflow. While I personally use gbp, I've seen dgit in action with Salsa, and if it fits the needs of others, that's great. > and tag2upload? >From my perspective, tag2upload offers a modern alternative to the over-30-year-old method we currently use to upload packages. While my current workflow doesn't present any issues that tag2upload might address-and thus I haven't felt a need to use it myself-I see it as a positive step towards modernization. I consider tag2upload part of Debian's ongoing efforts to enhance our processes, and I'm interested to see where it takes us. Finally, it may serve as a stepping stone on the path I intend to pave towards unified Git-based workflows across Debian. > Do you have any ideas about VCS use in Debian that you would promote as DPL? I basically answered this question above, but to reiterate: My strategy as DPL is to join forces with other DDs to move packages to Salsa that have been somehow "forgotten." Many packages that do not have their Vcs fields set to Salsa are even hosted there, but they have not been uploaded by the team maintaining them with updated Vcs fields. I believe this is an easily solvable problem within one additional year. During the Bug of the Day effort, I encountered many cases where not being maintained on Salsa was a minor issue compared to other QA problems. In the responses I received from the maintainers of these packages, the vast majority were positive. > A while back someone told me that they want to NMU one of my packages. It > was maintained in /debian on salsa, so I reminded them that this is > basically collab-maint these days and they did the right thing and just did > a team upload instead. Julian mentioned common package maintenance in how > it's done in Ubuntu. What do you think about the /debian team and would you > want to promote the use of that as DPL? I think the /debian team is a great idea, and I actively use it. As DPL, I fully promote its use. Thank you for pointing this out. Kind regards Andreas. [1] https://lists.debian.org/debian-vote/2025/03/msg00047.html [2] https://lists.debian.org/debian-vote/2024/03/msg00057.html [3] h
Re: Q for nominees: structural reforms to delegations
Hi Jonas, [just following a hint from Sam Hartman to use top posting in such kind of discussions] Please take my deliberate silence as a signal that, as a potential DPL, I am not willing to reinforce a pattern that has been frequently criticized. However, I am happy to answer any explicit question. Kind regards Andreas. Am Thu, Mar 20, 2025 at 08:35:01PM +0100 schrieb Jonas Smedegaard: > > I similarly found the implied question from Branden appropriate, and > hereby second the encouragement for the candidates to express their > opinions on the proposed changes. > > Of course, silence is also a way to express opinion, but I would find > that a troublesome approach for a candidate for Debian Leader to not > even bother to state an opinion on a matter explicitly put forward in > the context of sheding light on the political views of the candidates. > If, as the non-candidate reactions seem ti indicate, this is a horrible > can of worms that I just happen to be ignorant about, then state that - > no need to open the can if you judge that to be too painful (for you or > for me or whatever). > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > * Sponsorship: https://ko-fi.com/drjones > > [x] quote me freely [ ] ask before reusing [ ] keep private -- https://fam-tille.de
Re: Q to nominees: Rough plan on Debian/Ubuntu non-collaboration?
Hi Simon, Am Fri, Mar 21, 2025 at 10:48:08AM +0100 schrieb Simon Josefsson: > Encouraging collaboration between Debian and Ubuntu seems like a good > thing to me since there is a lot of work/code re-use and people overlap > between these projects. As I wrote in my other answer[1] I prefer collaboration with *any* Debian derivative. > Some detailed topics for consideration: > > - Ubuntu uses Snap and the Snap Store, is that something which Debian > should adopt as part of the improved collaboration with Ubuntu? I do not consider this a topic that is relevant for the DPL. Following our Do-O-Cracy principle I expect people who need Snaps to care for the snap infrastructure (which is working as far as I'm informed) as well as say flatpacks. > - Ubuntu has a different system installer than Debian, is merging them > within scope? I also do not think that the DPL should decide about the installer. I'm all for cooperation and seeking for synergies. But this is the decision of the d-i team. > - Ubuntu is aligned with corporate/governmental interests that can have > a preference for non-GPL software. What are the concerns > collaborating along that effort? I'm thinking about replacing > CoreUtils with UUtils, GCC with Clang, GnuPG with Seqoia etc. Same here: If someone decides to suport the said alternatives (as far as I can see these exist) it might be picked up by any derivative. If maintainers of our dreivatives might care for the packages upstream in Debian - great. > - Ubuntu is generally more relaxed about copyright licensing and > software freedom perspective than Debian, and Ubuntu includes and make > use of more non-free content than what is in Debian. Is collaborating > on expanding that in scope for Debian? For me Debian equals to Debian main which contains software released under DFSG free licenses. I don't see any change coming here, neither do I see any good reason for this. I do not consider it as "collaboration" if we might weaken this principle. > - Ubuntu doesn't support some architectures/ports that we have in > Debian, and Ubuntu support/assume some CPU features that Debian > doesn't. Is harmonizing the set of support in scope? I do not see any good reason in droping features from Debian just because one or more of our derivatives does not. We should decide on our own what we are able to support. If we have the person-power to support our release architectures that's great. I absolutely fail to see in which way droping some architecture in Debian will help any derivative. > - Ubuntu has a fixed time-based release schedule, as that something we > should adopt? I like the principle: "Its ready when its ready." The only thing I would love to enhance in our release cycle is that we should strive to have as short as possible time from freeze to release. Kind regards Andreas. [1] https://lists.debian.org/debian-vote/2025/03/msg00043.html -- https://fam-tille.de
Re: Q to nominees: Rough plan on Debian/Ubuntu collaboration?
Hi Julian, Am Wed, Mar 19, 2025 at 05:10:01PM +0100 schrieb Julian Andres Klode: > > No, git-ubuntu imports the unapplied tree, roughly similar to what > gbp import-dsc would do. What will happen if a package has Vcs fields set to Salsa when using git-ubuntu? Is it just cloning the Salsa repository? If yes, would it be beneficial for Ubuntu (and other derivatives) if all Debian packages were hosted on Salsa, or would such an effort have no impact on your workflow? Kind regards Andreas. -- https://fam-tille.de
Re: Re-posed: Qs for DPL nominees: structural reforms to delegations
Hi Branden, thanks a lot for the short and precise questions. Am Tue, Mar 25, 2025 at 12:06:31PM -0500 schrieb G. Branden Robinson: > Thanks to Andreas, Gianfranco, and others for pointing out that my > questions to the candidates would be improved by question marks. > > As Debian Project Leader (DPL), > > 1. Will you remove the words "and Code of Conduct violations" from the > Community Team delegation charter? No, I believe the inclusion of "and Code of Conduct violations" is important for maintaining a clear understanding of the scope of the Community Team's responsibilities. Removing these words could potentially create ambiguity about the team's role in addressing such violations. > 2. Will you articulate a policy that no Debian Developer shall occupy > more than one delegated role at a time? I would gladly suggest this as a general guideline rather than a strict policy. However, this would only be feasible if we had a large pool of willing and qualified volunteers to fill delegated roles, which is currently not the case. Moreover, I do not see a strong need for such a policy as long as holding multiple delegated roles does not create a conflict of interest. > 3. Will you ask any Debian Developers enjoying multiple delegations to > resign from all but one of their choice? No. See my answer to 2. > 4. Will you establish a policy that all delegations made by the Debian > Project Leader shall be renewed no less frequently than once per DPL > term? No, I do not see a need for this policy. Delegations should be made based on the needs of the project, and there is no reason to set a rigid renewal timeline if the current delegates are doing their work effectively. > 5. Will you continue the practice that team delegation announcements > by the DPL implicitly withdraw the delegations of any sitting team > members not mentioned in that same delegation announcement? Yes, I would continue this practice, as it is an established method of communication. Since this is already explicitly stated, I see no need to change it. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: How do you feel about OSI, FSF and LF? (and Debian while we're at it (and AI if you want to))
Dear Jonathan, thank you for another batch of questions. Am Wed, Mar 26, 2025 at 07:48:39AM +0200 schrieb Jonathan Carter: > > How do you feel about organisations such as the Open Source Initiative, After reading the LWN article "OSI election ends with unsatisfying results"[1], my trust in the organization is deeply shaken. The reported governance issues-namely lack of transparency in elections-made me realize that even in the Free Software world, such problems persist. While I don't know how this affects Debian directly, I hope we can continue focusing on our principles to build the best system. Perhaps this also invites reflection on how we uphold accountability in our own processes. > Free Software Foundation I think the FSF is upholding the same values as we do and I appreciate this. > and the Linux Foundation? I need to admit I have no deeper insight into Linux Foundation and can't comment on this question. > We have two candidates who have mentioned their intent to collaborate more > closely with Ubuntu, but should we also be doing more to collaborate with > these? > > In cases where our goals start to diverge from these organisations (or more > accurately, when their goals start to diverge from ours, but bah! I don't > want to lead the question too much), should we be paying attention? Or even > take action? I did not mention Ubuntu in my platform, but I'd like to emphasize that Debian should approach all derivatives equally. Any technical collaboration, such as incorporating useful patches from any distribution, is always sensible. While Debian should remain independent in its decision-making, it is important to stay aware of developments in related projects where relevant. > And pointing the finger to ourselves, how well do you think the Debian > Social contract and DFSG holds up? As a DPL candidate, do you think there's > anything substantially missing? > > https://www.debian.org/social_contract Do you have specific concerns or ideas in mind regarding potential gaps? I admit I have not thought about this yet, but I see the Social Contract and DFSG as fundamental to Debian's identity. I am open to inspiring ideas and discussions on how they might evolve. > Do you think that there are there ways we could do better at those promises > and be a better Debian? I believe our promises are well thought out and form a strong foundation. What matters most is bringing them to life through our actions. While there is always room to improve how we fulfill them, I think Debian, in general, does a good job of staying true to them. > And another bonus question. How do you feel about the general concept of > free software going forward? Is it something that is growing / embraced by > the world (big corporations, software companies, etc), or is the trend to > nerf it and trend towards models such as open-core and exploit it as far as > possible? That's certainly a bonus question, and I believe the DPL has only a marginal influence on these global trends. I've heard different perspectives on the future of free software-some optimistic, some concerned about shifts toward open-core models. What matters most to me is that Debian continues to grow, which I've tried to illustrate in my Bits talk at DebConf. As long as Debian thrives, I take that as a positive sign. > And another because I'm supposed to be driving to work and it's more fun to > type questions than to sit in traffic... how do you feel about how AI is > going? Massive corporations are scraping and processing vast amounts of work > in the commons that gets regurgitated as new and original code. Where do you > stand on this, both ethically and in the context of the future of projects > like Debian? At FOSSASIA, I saw a talk that analyzed this topic to some extent. One of the key takeaways was a graph showing that while commercial AIs are currently more powerful, free AIs are catching up. It will be interesting to see how this trend develops and what it means for projects like Debian. As Einstein supposedly said, 'Predictions are difficult, especially about the future.' Thank you for your questions Andreas. [1] https://lwn.net/Articles/1014603/ -- https://fam-tille.de
