Re: Are Martin and Sam's platforms equivalent?
Sean Whitton writes ("Re: Are Martin and Sam's platforms equivalent?"):
> On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote:
> > 2. Package sponsorship
...
> > There are too few people reviewing packages at sponsorship-requests,
> > but proper and timely reviews would be very important both for not
> > frustrating new contributors and ensuring that new contributors
> > are learning to do high-quality packaging.
I hesitate to bang this drum again, but this would be a great place to
think about how we can use git more.
Ideally, our default sponsorship workflow would *not involve source
packages or orig tarballs at all*.
> The question is whether those processes could be changed such that the
> manpower problem would be less keenly felt. I cannot myself see any way
> to achieve that -- there are tooling issues but improving the relevant
> tools would not significantly speed either queue.
Whenever I do sponsorship I find the task of consuming the bits I have
been provided by my sponsee far outweighs the task of checking what
they have done to the package.
This is seriously exacerbated by the additional friction which occurs
if I have any comment on the package which results in a respin.
If sponsorship was as simple as
git debsponsor clone
cd
git diff dgit/dgit/sid # or maybe git diff upstream/stable-4.12
dgit push-source
then (i) I would want to do much more sponsorship (ii) my sponsees
would get the kind of timely service I can provide for `oh this is a
5 min job' type of task, rather than what I can provide for `this
might take half an hour or it might take two hours'.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bikeshedding
Stefano Zacchiroli writes ("Re: Bikeshedding"):
> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.
>
> DPL candidates: do you agree with this statement?
> If so, what will be your approach to make this a reality?
What git tree format do you mandate ?
Such an imprecation is of little use if "maintained in git on salsa"
means for some packages a giant packaging-only monorepo (like used by
some language-specific packaging teams), for some a git-debrebase or
git-dpm patches-applied tree, for some a merging git branch for use
with 1.0-with-diff, and for some a gbp pq branch.
> (I'm putting on the side, on purpose, the problem of different workflows
> that Joerg has highlighted. Not because it's not a real problem, but
> because I think it's a distraction to discussing/fixing the more
> substantial problem of access rights and package ownership.)
Another answer to this is:
The git server you are asking about already exists. It is called
`dgit.debian.org', not `salsa.debian.org'.
It has the following properties:
* Every package has a corresponding git view via `dgit clone';
when the maintainer didn't dgit push, it is a .dsc import.
* Everyone who uploads a package with `dgit push-source' etc.
already makes it availablevia the obsolete source package archive.
* When you push with `dgit push-source' you make your actual git
branch available to `dgit clone'.
* You can do that iff you can upload the same package to the obsolete
source package archive. Ie the access control is identical.
* You can use gbp pq or git-debrebase or git-dpm, and your git branch
is magically transformed into a uniform immediately-buildable view
for everyone who consumes it via `dgit clone'.
So real answer is: everyone should consider `dgit push' and most
people should be using it. It should be recommended in policy.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Q to all candidates: what is the long-term role of traditional Linux distributions?
Hi Matthew On 2019/04/03 00:22, Matthew Garrett wrote: > Given these upstream shifts, is attempting to package as much software > as possible something that actually benefits Debian and our users, or is > it something that brings us a duplication of effort? I'm not quite convinced that these upstream shifts are as pronounced as you make it out to be. Packaging software in Debian is both beneficial to its users, and a duplication of effort. Some things are a double-edged sword and you have to weigh up the positives and the negatives. I don't think it's a valid "or" question. > If we spent time on building tooling to automatically identify that (say) > installed Go > applications that contain dependencies with security vulnerabilities and > alert users, would that be time better spent than independendly > packaging and maintaining those dependencies ourselves? I think it's up to people who use hacky distribution methods to try to solve the problems that they create, not us. > Are our current priorities the best way to serve the free software > community over the next 10 years? Do you mind being more clear about which priorities you're referring to? Regardless, the answer is likely to be no. I think there will be too much change over the next ten years for any project to have the luxury of having the same exact priorities over such a period. As for our official priorities in terms of our social contract, I hope that those priorities will be the same in 10 years from now. > Would we be better off focusing Debian as a high-quality base for users > who then largely consume software from other sources? I don't think so. However, I do think we can do a lot more to make it easier for users to consume software from 3rd party sources. There has been some good discussions on this topic on this list recently, and its clear that it's not going to be a problem that you can fix by just throwing random quick and convenient ideas at it. Flatpacks, Snaps and AppImages are a reasonable stopgap but they don't come close to solving all the problems that they try to address and also cause new problems. Personally I would rather us focus on bringing Debian's distribution methods to the point where it's second to none. Based on the discussions we've had on this list recently, it certainly seems possible to get there, even if it may take some time. Debian as it exists now is already very usable as a high quality base that can be used to consume 3rd party sources, so if that aspect had more attention and focus, what would you like to see better in Debian as a base system? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Are Martin and Sam's platforms equivalent?
On Wed, Apr 03, 2019 at 12:40:45PM +0100, Ian Jackson wrote: > I hesitate to bang this drum again, but this would be a great place to > think about how we can use git more. > > Ideally, our default sponsorship workflow would *not involve source > packages or orig tarballs at all*. It's too easy to get orig tarballs wrong. Until all or most upstreams have public git with tags, this might be problematic. For this reason, I tend to ask for an upload to mentors.d.n even when provided with a some-random-workflow-git-repo (I especially hate anything related to gbp). > If sponsorship was as simple as > git debsponsor clone > cd > git diff dgit/dgit/sid # or maybe git diff upstream/stable-4.12 > dgit push-source Shouldn't this include actual build, etc? I have sponsored over 1000 uploads, yet not a single time I skipped the build step. Sponsorees don't tend to package libreoffice-sized stuff, and even uploads I otherwise merely rubber-stamp too often miss some obscure B-Dep or something. There's no way I'd upload even an one-line change without a test build + bin-debdiff. And, without a built package, you can't look at lintian. It automates a good part of reviewing. > then (i) I would want to do much more sponsorship (ii) my sponsees > would get the kind of timely service I can provide for `oh this is a > 5 min job' type of task, rather than what I can provide for `this > might take half an hour or it might take two hours'. While git does have many upsides, I fail to see how it'd be better for estimating required effort. For comparison, my workflow is: .--==[ .bashrc ] alias lsdebs='grep ^Package: debian/control |cut -d" " -f2 >/tmp/deb-list' alias diffdebs='for x in `cat /tmp/deb-list`;do c "$x" && apt download "$x" && debdiff --wt "$x"_*deb;done' `-- dget cd lsdebs dpkg-buildpackage -S -d# repack, gen changes cd .. sbuild diffdebs apt source debdiff package_*.dsc|colordiff|less -R This is the point where, having glanced at both diffs, I decide whether to rubber-stamp or to do actual review. Of course folks like Gürkan can pass even complex changes with only a cursory look, newbies and poor-quality contributors get even trivial changes fully reviewed, usual folks are in the middle. What I'd wish for, is some CI that takes sponsoree-provided package, builds it, and provides ready bin-lintian, src-debdiff, bin-debdiff, and the .debs to look over -- but such a tool can be fed a dgit repo just the same as existing mentors .dsc packages. Unless you make dgit fully distributed like "dget from some random URL" is, there's no gain. And, monstrosities like gbp or patches-unapplied make quilt-in-git workflows nastier to review than just comparing two unpacked dirs, the old way. So, if you'd want to make _me_ happy, it would be nice if you could kill quilt dead. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Re: Q to all candidates: what is the long-term role of traditional Linux distributions?
Sam Hartman writes ("Re: Q to all candidates: what is the long-term role of
traditional Linux distributions?"):
> Debian is great at giving you all the parts of what you need to do that
> aren't your primary focus.
This is a great answer.
> I think packaging free software even from languages that have their own
> system is valuable in a lot of ways. First, we have a way of expressing
> dependencies that cross language boundaries well. We have a consistent
> approach to validating licensing that seems better than a number of
> other repositories in terms of respecting the DFSG and/or more generally
> the four freedoms.
We have had a lot of discussions in Debian about language-specific
package managers, and we seem to have some heartache or something on
this topic. Personally I have a somewhat different take.
Compared to (say) NPM or crates.io,
* Debian has a much better answer to the problem of upstream malware
(including the risk of random hostiles taking over packages).
* Debian provides clear Freeness guarantees.
* Debian provides much longer-term stability.
* Using Debian packages means a much lower risk of random shit going
wrong simply because the set of online services, public keys,
etc. you are relying on is much smaller and more cohesive.
* Debian also, sometimes serendipitously, provides a filter which
means that if you're lucky you don't have to wade through as much
crap to find a thing to do what you wanted.
Serious failures due to language-specific package managers - which
place far too much trust in their ill-curated or not-at-all-curated
archives - have become so common that they are not even news any more.
The worst language-specific package managers encourage really poor
practices. Read this excellent article where someone familiar with
incident analysis and remediation tries to look at recent NPM failure
from the pov of Serious People Trying To Stop Bad Shit:
https://www.hillelwayne.com/post/stamping-on-eventstream/
(Additionally, Debian provides a standardised format so you don't need
to learn language-specific tools and so that software from different
languages can be integrated. Our packaging tooling makes that easy.)
So IMO the benefits of Debian are all *really valuable*. But they are
also *work*. Ie, those benefits are the result of the hard work of
our language-specific packaging teams.
When that work is not done, indeed, users have to fall back on random
upstream stuff.
I am all for making it easier for language-specific packaging teams to
do their curation work.
But I don't think it is a problem *for Debian* that there are systems
which look more convenient until you discover that are a tyre fire and
now you are on fire too. I don't think we should emulate them.
One thing that would make this a lot easier would be if we could draw
more users into this curation more easily. Of course curation is a
task requring authority, so will have to depend on status or review.
But it would be nice if, say, after I have done my own techopolitical
review of some thing I found on crates.io, I as a DD could push some
button to say "I approve of this thing with its current
maintainership" and it would be automatically shoveled into sid.
As it is, I would have to learn a lot about not just Rust but also
Debian Rust packaging, and join the Rust packaging team, and so on.
I wouldn't mind promising to keep an eye on the updates on crates.io
and saying yay/nay to them. Provided that saying yay or is very
simple and doesn't involve wrestling a pile of strange machinery.
In a recent project of mine that was too big a yak to add to my herd,
which means that Debian missed the opportunity to capture the value of
my review work.
I think that this problem could and therefore should be solved in a
way which generalises to multiple language-specific package managers.
> And yet people are spending a lot of time curating modules from
> languages that have their own repositories. Yes, I'm sure this work has
> value. I think we should do a better job of letting people know that we
> recognize the value and articulating to ourselves and our users what
> that value is.
I agree that we need to do more promotion of this aspect of Debian's
value.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL
[no need to CC me; I'm subscribed to -vote] Dear Jonathan et al., > > - the elected person gets so squeezed that after their service they just > > prefer to focus in other tasks, > > I agree that an overloaded DPL role can be harmful to both Debian and > the individual in the role. I think it's important for a DPL to take a > step back every now and again and look at the various properties of the > role and ask "Is this working?". If elected, I do plan on filing bugs > against the DPL role if I feel that something can do with improvement. I'd be very interested if you and the other candidates could elaborate on their thoughts in this approximate area. As a bit of background, I've actually written this reply twice before (or, admittedly ones somewhat similar) but it was difficult for it to come across as not appearing churlish or otherwise grumbling about my experiences. However, I hope with this paragraph, readers will read it in its intended context regardless. :) So, in general, I fear that the candidates may be over-estimating how much of the DPL's tasks can be delegated to teams or other individuals. A lot of teams have entirely-legitimate questions before acting (for example, checking over some document) and often check-in with the DPL, asking for advice, guidance or whether the Leader's experience or contacts mean they have been exposed to a novel angle or approach to what they are trying to achieve. This is, of course, eminently sensible and healthy IMHO. More importantly however the majority of tasks that land on a DPLs plate may technically and «prima facie» be delegatable but the total time and energy required to forward it, ensure it is correctly followed-up on, context switch, ping later, forward any replies, etc. etc. etc. regretfully exceed said time/energy of just "getting it done" yourself to begin with. I suppose part of the solution here might be to ensure and promote an atmosphere where teams feel more empowered to push ahead without quasi-approval (as well as ensuring some requests reach the "right" place in the first place) but these are really far harder, long-term goals that would require supreme dedication to even start to move the needle on. I'm afraid I would be somewhat skeptical of any candidate who thought they possess any sort of magic bullet to any of this before being truly exposed to it outside of the abstract concepts I've outlined above. :) Indeed, some of these issues are not /really/ solvable in the sense that I'm not sure I, as a member of the Debian community, would want to be without the option of being able to ask the Project Leader for their connections, experience or plain-old sanity checking before doing something especially if that action might affect the reputation or image of the Project. So, reading this back I am not entirely sure what I'm asking here but I would be interested if our candidates had any thoughts about this. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL
> "Chris" == Chris Lamb writes: Chris> I'd be very interested if you and the other candidates could Chris> elaborate on their thoughts in this approximate area. Chris> As a bit of background, I've actually written this reply Chris> twice before (or, admittedly ones somewhat similar) but it Chris> was difficult for it to come across as not appearing churlish Chris> or otherwise grumbling about my experiences. However, I hope Chris> with this paragraph, readers will read it in its intended Chris> context regardless. :) Chris> So, in general, I fear that the candidates may be Chris> over-estimating how much of the DPL's tasks can be delegated Chris> to teams or other individuals. I consider this one of the big unknowns. I may be more prepared than some of the other candidates in that I think I've had relevant experience from the IETF. Area Directors (and the IETF chair) get consulted in much the same way, so I do think that I have experience understanding what you can and cannot delegate in a large volunteer project. However Debian is unique. I've budgeted a fair bit of time enough that even if I'm not very successful in delegating I can still be successful as a DPL. I will be disappointed if I don't find some way to get more people involved in the work of dispute resolution. Reading between the lines in your bits mails, it sounds like that is something where getting more people involved is important. Honestly though, I cannot actually plan how I could delegate that until I experience it. By working with the anti-harassment team I'm starting to understand what might be possible and starting to understand what role that team can play in the process. Even if I am not successful at delegating that work I think I'll be good at it. However I think longer-lasting changes are possible if we're able to do two things. First, in addition to resolving disputes help people learn new ways of approaching conflict while in the process. Yeah, that means things take even more time at first. Secondly, delegate what we can and over time make that not a one person job. Fortunately the above are incremental: there is value even if I don't fully succeed. Chris> A lot of teams have entirely-legitimate questions before Chris> acting (for example, checking over some document) and often Chris> check-in with the DPL, asking for advice, guidance or whether Chris> the Leader's experience or contacts mean they have been Chris> exposed to a novel angle or approach to what they are trying Chris> to achieve. This is, of course, eminently sensible and Chris> healthy IMHO. It is, but it's also something that a good manager balances. When I go to my boss, he often doesn't directly answer my question. Instead he focuses on empowering me; on answering the part where he does have specific experience but helping me get to a point where I'm able to do more on my own in the future. I'm not as good as he is at that skill, but I do have years of experience mentoring people and empowering them across multiple companies and volunteer projects. I don't have any magic bullets, but where skill, dedication and experience can help with delegations, I think I'm in a good place. Chris> More importantly however the majority of tasks that land on a Chris> DPLs plate may technically and «prima facie» be delegatable Chris> but the total time and energy required to forward it, ensure Chris> it is correctly followed-up on, context switch, ping later, Chris> forward any replies, etc. etc. etc. regretfully exceed said Chris> time/energy of just "getting it done" yourself to begin with. I'd certainly get out of the loop of forwarding replies; redirect better than proxy for time management:-) And yet the rest of what you say--particularly context switching, pinging, following up are all true. Chris> I suppose part of the solution here might be to ensure and Chris> promote an atmosphere where teams feel more empowered to push Chris> ahead without quasi-approval (as well as ensuring some Chris> requests reach the "right" place in the first place) but Chris> these are really far harder, long-term goals that would Chris> require supreme dedication to even start to move the needle Chris> on. I'm afraid I would be somewhat skeptical of any candidate Chris> who thought they possess any sort of magic bullet to any of Chris> this before being truly exposed to it outside of the abstract Chris> concepts I've outlined above. :) Yep, and I think it's the long-term cultural changes we perhaps need. I certainly have been known to have lots of dedication especially when I see small results that might become bigger over time. Succeeding is important to what I want to accomplish in making cultural changes around communication. However,I'm prepared to be a successful DPL even if I don't figure out how to move that needle v
Re: Q to all candidates: what is the long-term role of traditional Linux distributions?
Thanks for asking these questions. I'm *really* interested to see how all the candidates respond (if they do) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL
Hi Chris On 2019/04/03 15:00, Chris Lamb wrote: > On 2019/03/29 16:01, Jonathan Carter wrote: >> I agree that an overloaded DPL role can be harmful to both Debian and >> the individual in the role. I think it's important for a DPL to take a >> step back every now and again and look at the various properties of the >> role and ask "Is this working?". If elected, I do plan on filing bugs >> against the DPL role if I feel that something can do with improvement. > > I'd be very interested if you and the other candidates could elaborate > on their thoughts in this approximate area. > > As a bit of background, I've actually written this reply twice before > (or, admittedly ones somewhat similar) but it was difficult for it to > come across as not appearing churlish or otherwise grumbling about my > experiences. However, I hope with this paragraph, readers will read > it in its intended context regardless. :) > > So, in general, I fear that the candidates may be over-estimating how > much of the DPL's tasks can be delegated to teams or other individuals. I did notice that some candidates (not going to point them out) did put a lot of emphasis on this aspect, I think it may be because it was very topical right around the campaign start date. Having said that, I think if it's possible to even just reduce the DPL workload overall by as little as 10% by shedding some work that can be delegated, then it's worth while spending time on it. > A lot of teams have entirely-legitimate questions before acting (for > example, checking over some document) and often check-in with the DPL, > asking for advice, guidance or whether the Leader's experience or > contacts mean they have been exposed to a novel angle or approach to > what they are trying to achieve. This is, of course, eminently sensible > and healthy IMHO. Yep, I'm 100% with you on that one. > More importantly however the majority of tasks that land on a DPLs > plate may technically and «prima facie» be delegatable but the total > time and energy required to forward it, ensure it is correctly > followed-up on, context switch, ping later, forward any replies, etc. > etc. etc. regretfully exceed said time/energy of just "getting it > done" yourself to begin with. Ack. > I suppose part of the solution here might be to ensure and promote an > atmosphere where teams feel more empowered to push ahead without > quasi-approval (as well as ensuring some requests reach the "right" > place in the first place) but these are really far harder, long-term > goals that would require supreme dedication to even start to move the > needle on. I'm afraid I would be somewhat skeptical of any candidate > who thought they possess any sort of magic bullet to any of this > before being truly exposed to it outside of the abstract concepts I've > outlined above. :) Heh, I hope you don't consider me a «summa stultus» then, because if I couldn't move the needle on that one I would certainly not run for a second term. I'm sure you're aware that a core part of my platform is to address part of the above. At least I can assure you that I don't believe in any magic bullet. I believe it's something that we'll have to work on together systematically as a project. It sometimes feels like there's this mass delusion in Debian, where a large amount of people believe that they have good ideas and that everyone else is against them in implementing those good ideas. This is exacerbated by people who mean well, but instead of looking for reasons to support an idea and build on it, they see it helpful to play devil's advocate to their maximum capacity, which muddles the water and confuses bystanders, and ultimately distracts everyone from the actual issues. Whether it's going to be easy or not, and whether we're going to make huge progress or just little on these fronts is irrelevant to me. What's important is that we try and that we take any small win that we can and build on it. If we're going to have the attitude that community stuff is hard and that we want to have it all or nothing, then we're never going to make any progress on improving our «genius loci». > Indeed, some of these issues are not /really/ solvable in the sense > that I'm not sure I, as a member of the Debian community, would want > to be without the option of being able to ask the Project Leader for > their connections, experience or plain-old sanity checking before > doing something especially if that action might affect the reputation > or image of the Project. My cell phone number is in db, and I invite any DD to contact me on signal or on IRC or by e-mail any time they believe that I could help with anything, especially in the sense if they want a pair of extra eyes on something or to just to soundboard. This will continue to be true if I were to serve a DPL term. > So, reading this back I am not entirely sure what I'm asking here but > I would be interested if our candidates had any thoughts about this. Thanks for t
Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL
On 15361 March 1977, Chris Lamb wrote: So, in general, I fear that the candidates may be over-estimating how much of the DPL's tasks can be delegated to teams or other individuals. [...] So, reading this back I am not entirely sure what I'm asking here but I would be interested if our candidates had any thoughts about this. Umm, lets make it short, for a change: Should there be something often enough that one can consider delegating it *and* there be volunteers for the work and it is something one can delegate, I am certainly up for delegating it. But I don't bet on being able to do that and am prepared to do the work that comes my way... -- bye, Joerg
Re: Bikeshedding
Hello,
On Wed 03 Apr 2019 at 12:51PM +01, Ian Jackson wrote:
> Stefano Zacchiroli writes ("Re: Bikeshedding"):
>> Statement: every Debian package must be maintained in Git on salsa and
>> every Debian Developer with upload rights to the archive should have
>> commit/push right to every packaging repository on salsa.
>>
>> DPL candidates: do you agree with this statement?
>> If so, what will be your approach to make this a reality?
>
> What git tree format do you mandate ?
>
> Such an imprecation is of little use if "maintained in git on salsa"
> means for some packages a giant packaging-only monorepo (like used by
> some language-specific packaging teams), for some a git-debrebase or
> git-dpm patches-applied tree, for some a merging git branch for use
> with 1.0-with-diff, and for some a gbp pq branch.
Yes. The amount of effort that we would need to expend on implementing
zack's Statement seems out of proportion to the benefit, given that it
mandates no particular git workflow.
> Another answer to this is:
>
> The git server you are asking about already exists. It is called
> `dgit.debian.org', not `salsa.debian.org'.
>
> It has the following properties:
>
> [...]
>
> So real answer is: everyone should consider `dgit push' and most
> people should be using it. It should be recommended in policy.
What's so nice about this is that it doesn't require anyone to
fundamentally change their git workflows (with the exceptions of people
who have only debian/ in their packaging repo (and Ian has experimental
patches for that case), and team monorepos).
You can incorporate `dgit push-source` into existing workflows and
achieve what (I think) zack and others want. See dgit-maint-gbp(1) etc.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Bikeshedding
> "Sean" == Sean Whitton writes:
Sean> Hello,
Sean> On Wed 03 Apr 2019 at 12:51PM +01, Ian Jackson wrote:
>> Stefano Zacchiroli writes ("Re: Bikeshedding"):
>>> Statement: every Debian package must be maintained in Git on
>>> salsa and every Debian Developer with upload rights to the
>>> archive should have commit/push right to every packaging
>>> repository on salsa.
>>>
>>> DPL candidates: do you agree with this statement? If so, what
>>> will be your approach to make this a reality?
>>
>> What git tree format do you mandate ?
>>
>> Such an imprecation is of little use if "maintained in git on
>> salsa" means for some packages a giant packaging-only monorepo
>> (like used by some language-specific packaging teams), for some a
>> git-debrebase or git-dpm patches-applied tree, for some a merging
>> git branch for use with 1.0-with-diff, and for some a gbp pq
>> branch.
Sean> Yes. The amount of effort that we would need to expend on
Sean> implementing zack's Statement seems out of proportion to the
Sean> benefit, given that it mandates no particular git workflow.
I disagree.
Would be happy to discuss on -devel after the election.
I've written Ian a detailed reply privately outlining my thoughts on
advantages of salsa even without specifying a git workflow.
Re: Q to all candidates: what is the long-term role of traditional Linux distributions?
On 15361 March 1977, Matthew Garrett wrote: But upstream development is increasingly diverging from our approach. I think that depends a bit in which area you look. Many new software ecosystems are based on external code repositories rather than relying on the distribution, and in several languages it's expected that a project directly include its dependencies rather than relying on external availability. But those software ecosystems also need a stable base that works and allows them to ignore those mundane basics. Given these upstream shifts, is attempting to package as much software as possible something that actually benefits Debian and our users, or is it something that brings us a duplication of effort? We don't need every single possible bit of software packaged. That's neither a useful nor an attainable goal. We need as much groundwork packaged that you can use any of the existing and new coming stuff in an easy, yet still secure, way. And that you can do it on an otherwise stable platform. Which is something Debian does provide pretty nicely (ok, except for releasing way too often and fast, which is a major downside of us). If we spent time on building tooling to automatically identify that (say) installed Go applications that contain dependencies with security vulnerabilities and alert users, would that be time better spent than independendly packaging and maintaining those dependencies ourselves? It may be. As I wrote elsewhere I imagine a Debian that has a Magic Archive (Hey, I got a free magic card there) and is *THE* answer to everything package related, so that anyone in any language environment (nodejs? ruby? python? perl? java? haskell? whatever) who ever goes "And now, how do my users get the crap I wrote?" goes "OH, sure, Debian, I just fill out this $somethingseomething and any user anywhere can *easily* get at it, perfectly integrated in their system with all dependencies magically resolved". Lucky, for me, even with the magic card, I have been vague enough that it fits even here. I do want Debian to be the platform chosen to build other stuff upon. In whichever environment the people building are. Go, Ruby, NodeJS, whatever. A startup that scales up tons of containers and throws them away even faster than their humans. A big business that thinks a new released Linux Distribution every 10 years is the best. Someting in between that can deal with 5 years. Users at home that have featuritis and can't wait for the next tiny dot version to finally install. Now, packaging it all is an effort we really can't sustain. And it really doesn't make sense to have packages where the metadata is larger than the code. So yes, better tooling will be part of the answer. Our advantage, and something that we should try to keep and extend on is our unification and consistency. Say, I want a perl module Foo::Bar, I get it with one command and a predictable name and location and general behaviour. Want a golang something module (just assume its packaged), I get it with the same command and a predictable name. And so on.[1] Are our current priorities the best way to serve the free software community over the next 10 years? No idea how the world will look in 10 years, but if we keep the users as part of our priority, and adapt according to their needs, we shouldn't be far off. And yeah, now someone asks to define users, especially with what I wrote some lines up. Would we be better off focusing Debian as a high-quality base for users who then largely consume software from other sources? I think we should not have just one focus and concentrate on that alone. We should have multiple and continue to try to weight them against each other as good as possible. Footnotes: [1] Sure, right now this requires the "needs to be packaged" part. -- bye, Joerg
Re: Bikeshedding
On 15361 March 1977, Sean Whitton wrote: Yes. The amount of effort that we would need to expend on implementing zack's Statement seems out of proportion to the benefit, given that it mandates no particular git workflow. That's because you are all in way too deep in technical stuff. This is -vote, not -devel. Actually hashing out how it will work and look isn't what these threads here are (should be) about. dgit may even be (part of) the answer when one goes down to the technical work and specs. It may also not be but something new that may be based on concepts of it. Or not. I don't think that can, or should, be defined here and now. -- bye, Joerg
