On Tue, 19 Nov 2024 11:20:57 +0100, Marc Haber wrote:
> That being said, your answer might be on
> https://wiki.debian.org/DebianReleases/PointReleases
> or on the result page of your favorite search engine when you ask it for
> Debian Point Releases.
Cf. also the announcement of the last point r
/PointReleases
or on the result page of your favorite search engine when you ask it for
Debian Point Releases.
Greetings
Marc
On Tue, Nov 19, 2024 at 09:42:39AM +, Shashank B Shetty wrote:
> Hi Team,
>
> Attached are the list of packages that Debian repositories recommended to
> up
Hi Team,
Attached are the list of packages that Debian repositories recommended to
update for our server's post 1st Nov 2024 but none of them are showing in the
Debian security advisory portal . Kindly help us understand the same whether
all the packages recommended are to be installed or
g on? I don't see any bugs on the Ubuntu
launchpad, and I have no idea when the cutoff happened. Has it happened?
Yes. Ubuntu is fully frozen. Release is imminent (April 25).
https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649
So... How are we supposed to be taking care of &quo
esn't make it into the Ubuntu release? Case in point. I'm upstream for
several projects (mrcal, for instance) that use a simple build system
(mrbuild). These are both packages in Debian. Due to an uninteresting
change to an unrelated package (python3-numpy), mrcal started to FTBFS
at so
On Wed, Jun 29, 2022 at 1:46 PM Ravi Dwivedi wrote:
> Since the below mentioned analysis of Debian's security, and that too
> compared to other distros, is not very well-known outside of Debian
> project
honestly i don't believe it's even widely known *in* the debian project
[quite how damn good
e technology the
size of the developer pool, comprising the web of trust, is both much
smaller and also controlled by one Corporation: Canonical. Canonical
says "jump", the developers ask "how high".
> take Suse, Fedora etc: their RPM packages break the chain of trus
> they get one and only one chance to do something that stupid.
So the answer is that we have no way of preventing a developer from
intentionally sabotaging a package in any / as many ways as they choose and
the only risk to them is losing their uploader access after the fact?
>the response is sw
On Mon, May 23, 2022 at 7:59 PM Adam McKenna wrote:
> You are talking about a deterrent though. I think the question is,
> what if someone cares more about their political cause than
> retaining their uploader access?
they get one and only one chance to do something that stupid.
> What if someo
> anyone stupid enough to abuse their position may only do so once, at
which point their GPG key is revoked.
You are talking about a deterrent though. I think the question is, what if
someone cares more about their political cause than retaining their
uploader access?
What if someone's keys are
pool, comprising the web of trust, is both much smaller
> and also controlled by one Corporation: Canonical. Canonical says "jump",
> the developers ask "how high".
>
> take Suse, Fedora etc: their RPM packages break the chain of trust by
> failing to prop
> i did the analysis (took 3 weeks)
Do you have a publication of that analysis? I was thinking the same
about the organization of Debian for some time but never did analysis
or compared it to other distros.
Also I like to add that reproducible builds are an excellent addition
to the mechanisms yo
general, upgrading to newer versions of packages for no reason
other than that they exist is not a good practice. You should have a
reason for wanting a newer package than what exists in Debian
testing. I recommend that if you do have such a need for specific
newer packages, you install them individ
Ulrike Uhlig writes:
> On 26.09.19 08:03, Ansgar wrote:
>> What does stop the recommendations to be outdated in a year or two?
>> Given the long and slow process to gather them, there will probably be a
>> long and slow process to change them; that discourages actually changing
>> them (too high ba
Hi Holger,
On 24.09.19 15:21, Holger Levsen wrote:
> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>> For several of these recommendations if I cannot get consensus, I will
>> call for a GR myself.
>
> TBH, I'm not thrilled to read this, though of course it's in your rights
> to d
y be a
basis. It will easier to change an existing piece of documentation than
to research and rewrite it from scratch. And yes, documentation needs
the same kind of maintenance as packages themselves :)
Cheers!
Ulrike
Enrico Zini writes:
> On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:
>> But I think having recommendations available when people are new, when
>> they are looking for what to do when writing new tools, when the trade
>> offs don't matter, is really important. I think it's important e
h
> that it's worth time for a quick vote (and I do believe we can
> efficiently handle GRs).
I agree with your message, and I'd like to expand on "when people are
new". I probably don't qualify as new in Debian, and I maintain some
package outside of teams. For those
Mo Zhou writes:
> Is the recommendation working well under most circumstances?
> I mean, different teams have already made their conventions
> at these point, such as go team, rust team, nvidia team, etc.
> These team designed "local" recommendations always adapt
> well with special property of th
> "Mo" == Mo Zhou writes:
Mo> As you said, recommendations are merely recommendations. Debian
Mo> developers customed to their own workflow may not necessarily
Mo> follow the recommendations. However, the recommendation makes a
Mo> difference for newbies or newcomers, if thei
On 2019-09-25 07:15, Sam Hartman wrote:
>> "Scott" == Scott Kitterman writes:
>
> >> For several of these recommendations if I cannot get consensus, I
> >> will call for a GR myself.
>
> Scott> What do you think is important enough in this area that you
> Scott> would rather
On September 24, 2019 11:15:33 PM UTC, Sam Hartman wrote:
>> "Scott" == Scott Kitterman writes:
>
> >> For several of these recommendations if I cannot get consensus, I
>>> will call for a GR myself.
>
>Scott> What do you think is important enough in this area that you
>Scott
On 2019-09-25 05:32, Bernd Zeimetz wrote:
> On 9/24/19 3:21 PM, Holger Levsen wrote:
>> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>>> For several of these recommendations if I cannot get consensus, I will
>>> call for a GR myself.
>>
>> TBH, I'm not thrilled to read this, though
> "Scott" == Scott Kitterman writes:
>> For several of these recommendations if I cannot get consensus, I
>> will call for a GR myself.
Scott> What do you think is important enough in this area that you
Scott> would rather have people not contribute to Debian if they
Scot
On 9/24/19 3:21 PM, Holger Levsen wrote:
> On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
>> For several of these recommendations if I cannot get consensus, I will
>> call for a GR myself.
>
> TBH, I'm not thrilled to read this, though of course it's in your rights
> to do that.
Hi,
On 9/24/19 8:45 AM, Thomas Goirand wrote:
> Why would it be unacceptable that the whole of the archive be maintained
> in Git using Salsa? Wouldn't it be much nicer for everyone?
basically because sometimes it makes sense to have packages on github
(or gitlab, ...), close (or
On September 24, 2019 12:10:39 PM UTC, Sam Hartman wrote:
>> "Bernd" == Bernd Zeimetz writes:
>
>Bernd> On 7/23/19 7:31 PM, Thomas Goirand wrote:
>>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using
>>> Git for packaging.
>
> Bernd> why is that a reason for a G
Hello,
On Tue 24 Sep 2019 at 08:10AM -04, Sam Hartman wrote:
> So, I agree that a GR would be the wrong approach if we thought that we
> could get to a consensus strong enough for the policy editors.
>
> I also agree that the policy editors have the technical authority to use
> a different (non-c
On Tue, Sep 24, 2019 at 08:10:39AM -0400, Sam Hartman wrote:
> For several of these recommendations if I cannot get consensus, I will
> call for a GR myself.
TBH, I'm not thrilled to read this, though of course it's in your rights
to do that. (I'm afraid such GRs would cost a lot of time which co
> "Bernd" == Bernd Zeimetz writes:
Bernd> On 7/23/19 7:31 PM, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using
>> Git for packaging.
Bernd> why is that a reason for a GR? its a question for the policy
Bernd> editors.
So, I agree t
t all.
>
>> 3- Mandating using Salsa as a Git repository.
>
> If that would really pass a GR, I'll start to remove packages from
> Debian
Why would it be unacceptable that the whole of the archive be maintained
in Git using Salsa? Wouldn't it be much nicer for everyone?
Cheers,
Thomas Goirand (zigo)
s a GR, I'll start to remove packages from
Debian
>
> I do believe #1 will pass easily, but that it's useless without #2, and
> there is some kind of uncertainty. For #3, I'm not even sure we should
> vote for that, I probably even prefer it not to be voted for mys
On 8/27/19 10:25 AM, Norbert Preining wrote:
> Hi,
>
>> Norbert, I'm very annoyed by your wording. "Having an agenda" reads like
>> if I was writing out of malice, on purpose, just to annoy you. That is
>
> No, having an agenda is that you have a clear target which you want to
> achieve.
That's
ld strongly recommend (i.e. require an explanation
> > why not) for NEW packages.
> As per our discussion in Debconf, we're attempting to remove Python 2
> from Bullseye. So, I decided to commit myself to try to do one Python 2
> removal per day. Doing so, I often encounter very ba
Hi,
> Norbert, I'm very annoyed by your wording. "Having an agenda" reads like
> if I was writing out of malice, on purpose, just to annoy you. That is
No, having an agenda is that you have a clear target which you want to
achieve.
> Reality is that you have no such opinion, you are just (rightl
On 8/27/19 2:06 AM, Norbert Preining wrote:
> Hi
>
> On Mon, 26 Aug 2019, Thomas Goirand wrote:
>> forced to either register on the said non-free platform, and use a
>> workflow which I very much dislike. It's either that ... or I just
>> ignore the VCS fields, and the VCS becomes outdated, missin
On Monday, August 26, 2019 6:01:05 PM EDT Thomas Goirand wrote:
> On 7/26/19 6:53 PM, Scott Kitterman wrote:
> > It's true it's not extinct, but it's close. It's only used by several
> > dozen packages now. If someone wanted to push to get dpatch completely
&
ance that it will never get updated. That's really
You are mixing unresponsiveness of the maintainer with non-free
platforms, and I am sure you do that on purpose to press your own agenda
to force everyone to salsa.
Even on salsa there are (I am sure, because I have seen them before)
package
On 7/26/19 6:53 PM, Scott Kitterman wrote:
> It's true it's not extinct, but it's close. It's only used by several dozen
> packages now. If someone wanted to push to get dpatch completely out of the
> archive this cycle, I think it would be perfectly reasonable.
cy only
> recommending / preferring the proposed changes. Furthermore I accept
> that the policy should strongly recommend (i.e. require an explanation
> why not) for NEW packages.
Consider this...
As per our discussion in Debconf, we're attempting to remove Python 2
from Bullseye. So
general topic but since you mention it: Yes I
> remember dpatch -- it's not phased out, I just encountered it a few
> days ago.
It's true it's not extinct, but it's close. It's only used by several dozen
packages now. If someone wanted to push to get dpatch comp
On Fri, Jul 26, 2019 at 11:40:31AM -0300, Andy Simpkins wrote:
> Hi all
(...)
> /Andy
Thanks Andy for putting that into words, I completly agree with you.
--
tobi
re an explanation
why not) for NEW packages.
Clearly, maintained packages that do not match the proposed
new VCS & Layout will be harder &/OR require additional effort from
people that only understand this new work flow to to work on. However
these packages are being maintained by p
On Wed, 24 Jul 2019 12:23:42 +, Scott Kitterman wrote:
> We are
> perfectly capable of phasing out obsolete workflows without a
> hammer like a GR (remember dpatch).
Unrelated to the general topic but since you mention it: Yes I
remember dpatch -- it's not phased out, I just encountered it a
what you wrote downthread about possible to use 1.0 native
packages: yes,
> 3- Mandating using Salsa as a Git repository.
Again I think this proposal fails to account for corner cases, as an
example on top of what other have talked about: this could end up
affecting what can go into non-free. T
At this juncture
none exists. The idea of solving this via GR seems to me like an attempt to
avoid doing that work.
I'm curious who from amongst those pushing for this is volunteering to put all
the QA maintained packages in git (or should those be removed)? If you are
going to mandate this, then I think those are the only two options.
Scott K
❦ 24 juillet 2019 21:29 +00, Scott Kitterman :
>>> This entire discussion feels to me like a small group of developers
>>> trying to tell the rest of us "my way or the highway". We are
>>> perfectly capable of phasing out obsolete workflows without a hammer
>>> like a GR (remember dpatch).
>>
>>W
* Vincent Bernat:
> Because without uniformity, we make it harder for people to contribute.
> I have already mentioned Fedora that provides everything in git with CI
> enabled, ability to contribute with pull requests, but that's far the
> only proponent.
Fedora still uses VCS-in-VCS, so it's not
On Wed, Jul 24, 2019 at 12:23:42PM +, Scott Kitterman wrote:
> Since use of a public VCS isn't universal among free software projects,
> the implication is that one could take a non-free upstream tarball, dump
> it into git on salsa and magically make it free. I think this is a
> ridiculous co
On Wed, Jul 24, 2019 at 09:20:07AM -0400, Tiago Bortoletto Vaz wrote:
> On Wed, Jul 24, 2019 at 09:01:34PM +0900, Norbert Preining wrote:
> > (Or, heretic voice, maybe because it is easier to
> > throw people out when everything is standardized?)
>
> Norbert, it's not the first time in recent emai
On Wed, Jul 24, 2019 at 8:56 PM Holger Levsen wrote:
> On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote:
> > tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this?
> no, its too early to standardize on layouts.
And whether or not it is time (I find myself agreeing wit
On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote:
>
> tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this?
no, its too early to standardize on layouts.
--
tschau,
Holger
---
On 7/23/19 7:31 PM, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
>
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.
>
> 3- Ma
On 7/24/19 6:31 AM, Norbert Preining wrote:
> So be it, but don't put *your* bothering onto others. I am bothered by a
> lot of things, too, and I don't ask you to be bothered the same way.
Even if you dismiss Github, replace it by $foo, and explain to me why I
should register there because you ca
On July 24, 2019 1:16:37 PM UTC, Vincent Bernat wrote:
> ❦ 24 juillet 2019 12:23 +00, Scott Kitterman :
>
>> This entire discussion feels to me like a small group of developers
>> trying to tell the rest of us "my way or the highway". We are
>> perfectly capable of phasing out obsolete workflow
* Bastian Blank:
> On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
>> On 7/23/19 11:59 PM, Adam Borowski wrote:
>> > Big fat enormous NO! gbp is a workaround for the biggest evil in our
>> > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the
>> > impression t
On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote:
> Big fat enormous NO! gbp is a workaround for the biggest evil in our
> packaging: quilt. Watching pro-git-only talks on the Debconf, I got the
> impression that if we dropped the VCS-in-VCS approach, there'd be no need
> for most of
On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
> On 7/23/19 11:59 PM, Adam Borowski wrote:
> > Big fat enormous NO! gbp is a workaround for the biggest evil in our
> > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the
> > impression that if we dropped the VC
On 24.07.19 17:38, Fabien Givors wrote:
> Le 24/07/2019 à 15:16, Vincent Bernat a écrit :
>> Without a GR, the outcome is decided by a shouting contest. A GR seeems
>> great to know if people are a majority or not.
> A GR is not just a poll.
Yup. I personally see little chance this goes through.
) Do I accept, whatever the result of i), to make it mandatory for all
submitted packages?
I'm not sure most would agree to ii) unless they support the option
chosen in i)
What if the chosen standard is far from perfect?
It's been said that the vcs² approach of gbp+quilt is more of a
w
> Do you ask me to increase my work load to at least 300% only because of some
> standardization procedure for the minuscule chance that I am suddenly
> abducted by aliens?
No, it’s not about being abducted by the aliens, but there are other more
realistic factors
that might get any developer to
just don’t have a time and somebody
> > else needs to fix your packages, then it’s a heap of unnecessary
> > trouble to go through because of someones “personal” preferences.
>
> Sorry, I spent about 15 years packaging TeX and friends - and I spend
> most of my Debian time with
❦ 24 juillet 2019 12:23 +00, Scott Kitterman :
> This entire discussion feels to me like a small group of developers
> trying to tell the rest of us "my way or the highway". We are
> perfectly capable of phasing out obsolete workflows without a hammer
> like a GR (remember dpatch).
Without a GR,
On July 24, 2019 10:43:57 AM UTC, Phil Morrell wrote:
>On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
>> i detest unwarranted, imposed, uniformity. i *love* consistency. we
>have
>> had consistency in the distribution for ages. we don't need uniform
>> workflows.
>
>It's not
On Wed, 24 Jul 2019, Ondřej Surý wrote:
> > so, why isn't it enough to recommend those things?
>
> Because you are not the only developer in the whole world?
> And when you disappear or just don’t have a time and somebody
> else needs to fix your packages, then it’
> so, why isn't it enough to recommend those things?
Because you are not the only developer in the whole world?
And when you disappear or just don’t have a time and somebody
else needs to fix your packages, then it’s a heap of unnecessary
trouble to go through because of someones “
On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote:
> i detest unwarranted, imposed, uniformity. i *love* consistency. we have
> had consistency in the distribution for ages. we don't need uniform
> workflows.
It's not (always) about mandating workflows, see Ian's careful
distinctio
Vincent Bernat wrote:
> While not having any official position in either of these projects, I
> was able to contribute easily to both of them because they use a
> standard workflow: no need to read tons of documentation.
There is some truth in this, but I'm not sure the proposal is directly
addres
eady brought up reasons against this, but I just
wanted to mention that the Haskell Group doesn't use a gbp layout for
all of it's packages. Converting all the packages to gbp would mean a
lot of work for the conversion and would probably result in less
convenient workflows for the team once
have
> had consistency in the distribution for ages. we don't need uniform
> workflows.
>
> what good can come from reducing diversity and actively probibiting
> flexiblity?
Other people can more reliably fix your packages.
> and why do you insist on micromanaging the wo
On Wed, 24 Jul 2019 11:23:07 +0200, Vincent Bernat writes:
>> so, why isn't it enough to recommend those things?
>
>Because without uniformity, we make it harder for people to contribute.
i detest unwarranted, imposed, uniformity. i *love* consistency. we have
had consistency in the distribution f
On Wed, Jul 24, 2019 at 02:23:26PM +0500, Andrey Rahmatullin wrote:
> > > If we're not willing to force people to use debhelper, forcing them to
> > > use git and
> > > salsa seems much more extreme.
> >
> > +1
> >
> > let's first, if at all, get the mandatory use of debhelper into policy
> > wh
On Wed, Jul 24, 2019 at 10:49:05AM +0200, Daniel Baumann wrote:
> > If we're not willing to force people to use debhelper, forcing them to use
> > git and
> > salsa seems much more extreme.
>
> +1
>
> let's first, if at all, get the mandatory use of debhelper into policy
> which is much more imp
❦ 24 juillet 2019 17:07 +10, Alexander Zangerl :
> well, i do exist. i have a few packages that aren't vc'd, and i don't see
> any need to change that. while i don't mind git, but i'd hate to be _forced_
> to use salsa and gbp.
>
> so, why isn't
On 7/24/19 7:29 AM, Harlan Lieberman-Berg wrote:
> If we're not willing to force people to use debhelper, forcing them to use
> git and
> salsa seems much more extreme.
+1
let's first, if at all, get the mandatory use of debhelper into policy
which is much more important.
Regards,
Daniel
Norbert Preining writes:
...
> I am personally not upset at all,
On reading back what you wrote, I see that the impression I'd somehow
gained has no basis in fact, so I'm sorry for even suggesting it.
Perhaps it was just the brief flurry of "Reply to every email" behaviour
that set some unconsc
On Wed, 24 Jul 2019, Alexander Zangerl wrote:
> On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes:
> >You may be responding on behalf of people who turn out not to exist.
>
> well, i do exist. i have a few packages that aren't vc'd, and i don't see
> any n
On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes:
>You may be responding on behalf of people who turn out not to exist.
well, i do exist. i have a few packages that aren't vc'd, and i don't see
any need to change that. while i don't mind git, but i'd hate to
to being located in China and often away from personal
device. We have one in our team. The respective packages are still
mentined as old svn, not existing any more.
Do you think they have time and energy to reading this here and comment?
I am personally not upset at all, I just find it not a goo
ads as mandatory, we can always do a mass NMU. Ugly, but
possible.
> 2- Mandating using the "gbp patches unapplied" layout for Git, as this
> seems to be the most popular layout, and that we need some kind of
> consistency.
While this is how most of my packages are, because they&#
Norbert Preining writes:
...
> Fine with me, strongly recommend git - anyway, it is already a fact that
> it is the de-facto standard, so this is a non-argument. My argument is
> for those developers who might have other ways/interests.
Would it not be worth waiting for them to respond to this i
Hi Thomas,
> Then use one?
I do use, but several people I know don't.
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
How do you want to handle permissions? So there is a supe
On 7/23/19 11:59 PM, Adam Borowski wrote:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
>> packaging.
>
> Good. Especially if we can then drop quilt.
>
>> 2- Mandating using the "gbp patches unapplied
Steve McIntyre writes:
>>3- Mandating using Salsa as a Git repository.
>>
>>I do believe #1 will pass easily, but that it's useless without #2, and
>>there is some kind of uncertainty. For #3, I'm not even sure we should
>>vote for that, I probably even prefer it not to be voted for myself,
>>tho
t; 3- Mandating using Salsa as a Git repository.
>
> Or perhaps we could have a service mirror official git repos for packages
> hosted elsewhere?
I second kilobyte's amendment. Except the part about dropping .orig,
somewhat sadly.
Put more seriously: #1 I'd agree with, #2 I think
when Red Hat released
their kernel sources that way?
I'd say we should drop .orig and _forbid_ gbp.
> 3- Mandating using Salsa as a Git repository.
Or perhaps we could have a service mirror official git repos for packages
hosted elsewhere?
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ I've rea
Michael Banck writes:
> On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>> This probably has been floating around for some time. IMO, enough time
>> so that we start to discuss $subject.
> Why is this a GR and not a policy proposal?
Policy changes require strong consensus, and i
On Tue, Jul 23, 2019 at 04:47:32PM -0300, Michael Banck wrote:
> > This probably has been floating around for some time. IMO, enough time
> > so that we start to discuss $subject.
>
> Why is this a GR and not a policy proposal?
The policy documents the majority practices, which I think cannot be s
Hi,
On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
> This probably has been floating around for some time. IMO, enough time
> so that we start to discuss $subject.
Why is this a GR and not a policy proposal?
Michael
> Most other distributions I know about seem to have only the packaging
> information (debian/*) and not the upstream source in their version
> control system. So more people might be familiar with this; it also
> also makes tree-wide changes to packaging much easier ;-)
Is there a tooling around
Thomas Goirand writes:
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
> to all packages.
That wouldn't be changed by having all repositories on Salsa. You would
need
f we need exceptions, we can take care of them in the GR text, and even
make the rules for such exceptions explicitly fuzzy. However, I believe
this will concerns a very small amount of packages.
Cheers,
Thomas Goirand (zigo)
> On 23 Jul 2019, at 15:11, Thomas Goirand wrote:
>
>
> The idea is to be able to use unified tooling. Currently, we can't for
> example easily do a mass-commit on all packages. Or apply a new CI test
> to all packages. And that's even without considering the entr
all?
Then use one?
> I don't see that mandating git has any reason besides the "appeal to
> popularity", which at least in critical thinking circles is commonly
> seen as fallacy.
The idea is to be able to use unified tooling. Currently, we can't for
example easily
can still push to Salsa too. I don't know the
first thing about Fedora, but they have everything in one place [0] and
I can take a look, browse through history, it seems I can contribute
with just a PR and all packages have the CI plugged in.
[0]: https://src.fedoraproject.org/
--
Use library functi
Hey Thomas!
On Tue, Jul 23, 2019 at 07:31:11PM +0200, Thomas Goirand wrote:
>
>This probably has been floating around for some time. IMO, enough time
>so that we start to discuss $subject.
>
>Before starting any type of text for such a GR, I'd like to hear you
>folks. What are your thougts about a
o the VcsGit specified repository.
git is as everyone knows completely distributed, so using it locally
without a remote is viable.
Even till now I know too many packages where the released versions and
the one in the VcsGit are widely apart. Do you want mandating certain
push behaviour of devel
Hi
On Tue, 23 Jul 2019, Thomas Goirand wrote:
> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for
> packaging.
I don't see how we can mandate git. What if I do *not* use any vcs at
all? And I know enough projects that run on svn, hg, and other vcs.
I don't see that mandating
hs/years from now, where we will be 100% sure that
absolutely all packages will be hosted on Salsa (or another system we
decide to migrate to) with the same Git layout, and how easy it will be
(for example) to add some kind of CI/CD for all packages.
Cheers,
Thomas Goirand (zigo)
I don't know if many packages have them, but there is a privacy:: debtag that
for potential privacy concerns and other anti-features. Synaptic should be able
to show them.
On May 21, 2019 9:16:53 AM EDT, npdflr wrote:
>Hi,
>
>Would you recommend me or debian users to go through
1 - 100 of 562 matches
Mail list logo
