Hi!
> Arguably, such setup is spam: I is a bot that messes with the bugs but
> is not accountable for its actions, since it is only a one-way
> communication. Sure, I can then investigate the email and figure out
> which non-email side channel might reach the true originator of the
> bot activity,
Hi,
In my experience many of the discussions about packaging workflows on
this list have many misconceptions, which in turn I think stems from
that our tools are a bit challenging to use, and the documentation is
somewhat lacking. Many tend to struggle to figure out how to do
something, and once t
> > Debian has certainly done many things right in the past 30 years, but
> > treatment of new contributors is currently pretty harsh, considering
> > how many cracks and false turns they need to overcome on to become
> > regular contributors.
>
> The impact successive roadblocks can have on new co
> I endorse basically all of this. (I had really hoped to be able to put
> significant effort into modernizing debbugs over the past year or so,
I understand time is always a limitation, but if/when you have time
for debbugs, could you please prioritize reviewing/merging the open
MRs?
I would as
Hi Steve and others with interest in wiki.debian.org!
I wanted to follow up on this thread and advertise that Steve is
running a BoF session about the wiki future at DebConf:
https://debconf25.debconf.org/talks/146-debian-wiki-bof/
I've added some of the people who participated in
https://salsa.d
> >Please don't make strawman arguments. If you read the links I provided
> >and the how Guix folks summarized their needs, you can see that
> >maintaining the e-mail capabilities was one of their main
> >requirements.
>
> I have seen Debian discuss introducing Discourse to replace the
> mailing li
> I would significantly reduce my enjoyment of Debian if we were to move
> away from mailing lists and the BTS. Surely the BTS could be a bit
> more friendly in its advanced features, but new contibutors can simply
> ignore those, and a motivated person mght build a nice web interface
> for those.
Hi!
I came across this post https://issues.guix.gnu.org/76503 in Guix
where they discuss how to improve the contributor experience, and in
particular what technical changes they are doing.
Guix is interesting as they use a clone of Debbugs as their bug
tracker at https://debbugs.gnu.org/cgi/pkgre
On Wed, 16 Oct 2024 at 10:42, Daniel Baumann wrote:
>
> On 10/16/24 18:18, Iustin Pop wrote:
> > Gitea/Forgejo are common recommended solutions for "home hosting", but
> > neither is packaged.
>
> (jftr) I'm currently working with Forgejo upstream to get one last
> feature implemented that we'll
Hi,
> > * Package name: gwh
> > Version : 0.6.14
> > Upstream Contact: Roland Mas
> > * URL : https://salsa.debian.org/lolando/gwh
> > * License : GPL-3+
> > Programming Lang: bash
> > Description : git-buildpackage workflow helper
> >
> > This is a wrap
+Jelmer, who is the maintainer of the metadata specification
> https://wiki.debian.org/UpstreamMetadata
>
> That's pretty much where we are now. This was done in the pre-Salsa time, and
> if people get excited about the concept, I guess that Salsa offers new
> opportunities to play with the conce
> > >> debian/README.source as described in the developers-reference.
> > >
> > > It would be great also to have an easy way to cherry peak from the
> > > upstream
> > > git repository in order to prepare patch series.
> > >
> > > Do we have a tool around DEP-14, which allows this ?
> >
> > Well,
> >Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
> >and that adding a gbp.conf in every package doesn't sound too great for
> >teams that maintain hundreds or thousands of packages...
>
> Yes, please.
That could have been an option 10 years ago when people were creating
> > I think this significantly underestimates the annoyance involved in renaming
> > existing long-lived branches (in that all clients have to re-clone or
> > manually adjust), which is certainly why I generally avoid doing so unless I
> > absolutely have to.
...
> This could even be something that
Hi
> So, it looks like among the largest packaging teams, only the go team,
> the gnome team, and the php team have significantly adopted DEP-14.
>
> Note that this is not a criticism of DEP-14, only an attempt at
> providing numbers about DEP-14 adoption.
I have published similar stats before an
Hi!
I think Soren and Antonio summarized what I am thinking as well. If
there are seemingly unmaintained packages and we have people who are
willing to take care of them and update/refresh them by doing
something between a small NMU and a full-scale adoption, then that is
only positive.
On Wed, 7
> I'm interested in package popularity. I'm aware of popcon
> (https://popcon.debian.org/), but I'm more interested in actual
> downloads.
I am also interested in usage statistics. I feel it is much more
meaningful to work on packages that I know how have a lot of users.
While neither popcon of d
Hi,
> > >For what it is worth: I use `adduser` outside maintainer script.
> > >
> > >I think I'm not alone in that.
> >
> > Useradd has grown most of that functionality in the last two decades.
> > That leaves no space for adduser between useradd and sysusers. At
> > least not enouch space to wast
Hi,
I am not able to reproduce the test failure visible at
https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit5&arch=amd64&ver=5.4.3-2&stamp=1745014062&raw=0
in a local build myself, so I can't help with that. I did however
notice that the size of the resulting packages were quite small
Hi,
> Unfortunatly1 I have to ask this question, as this is not how you and
> (your|the) salvaging team is operating at the moment - IMHO.
>
> I acknowledge, while -- after being scoulted -- the approach how to
> handle ITS' by the team has changed, it continues to move or create
> repos of projec
> > Just out of curiosity, what email client and plugins do you use to
> > achieve your optimal email-based workflow?
>
> I don't see where Wookey made a claim that his workflow was "optimal",
> merely that it was effective for him personally. Debian Developers are
> a diverse bunch and approach p
Hi!
> >But the core of my question here was about the apparent conflict of
> >signing up for LowThresholdNmu as an indication that you are open for
> >collaboration, yet not having the package in VCS, which would make the
> >collaboration easier. I am trying to understand why certain people
> >obj
> NMUing is working on packages that someone else are responsible for,
> without coordinating that work ahead of time, just informing after the
> fact that the changes was done (and then being responsible for any mess
> the changes might cause).
Surely not "without coordinating that work ahead of
Hi,
> > > Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
> > > for a package?
> >
> > Why are you opposed to using Salsa as the VCS for cpuset? You use
> > Salsa for many other packages and Github for some others.
> >
> I am not opposed to using Salsa. As you note, I alre
Hi,
Would Matthias or anyone else active in this discussion be willing to
be the reviewer for
https://salsa.debian.org/debian/devscripts/-/merge_requests/478?
It has been pending for almost two weeks with zero reviews. I don't
feel it would be prudent of me to merge it with no additional eyeballs
How about adding a new header field in debian/copyright
(https://dep-team.pages.debian.net/deps/dep5/) called something like
"Reviews" which would be a list of URLs pointing to whatever public
system was used to record a review?
Then whoever reviews the debian/copyright file has easy access to
rev
Hi,
> > Apparently the problem isn't that no help is needed but that nobody has time
> > to train the new help, citing possible burn-out trying to get answers from
> > the
> > existing members and leaving in disappointment, if not disgust. (My
> > interpretation …)
> >
> > While that's a valid co
Hi!
> Around 12 years ago, I proposed a peer-review system to increase the quality
> of
> the packages in the NEW queue. https://wiki.debian.org/CopyrightReview
For packages that I sponsor, I already do reviews of the
debian/copyright and all other files. These are recorded as Merge
Requests in
Hi!
> > Salsa CI has had for many years the job 'missing-breaks' that
> > complements piuparts by checking that the files a package introduce
> > don't clash with files shipped by any other package in the
> > distribution without having proper Breaks/Replaces in the
> > `debian/control` file. This
Hi!
> Given the above four points, I propose the line from the code of conduct
> quoted above be changed to read:
>
> “There is no expectation that emails sent to the mailing lists are wrapped by
> the sender at a particular column, but those sending emails may wrap them if
> they choose.”
>
>
Hi,
On Wed, 5 Mar 2025 at 10:24, Nilesh Patra wrote:
> On 05/03/25 4:47 pm, Sean Whitton wrote:
> > On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote:
> >
> >> Dear Debian community,
> >>
> >> this is bits from DPL for February.
> >>
> >>
> >> Ftpmaster team is seeking for new team members
>
Thanks for the feedback!
Ideally the script
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/images/scripts/check_for_missing_breaks_replaces.py
would live in the devscripts package and be extended to have the
features suggested in this thread. However, even in its current form
it ha
Hi all package maintainers who use Salsa CI,
Salsa CI has had for many years the job 'missing-breaks' that
complements piuparts by checking that the files a package introduce
don't clash with files shipped by any other package in the
distribution without having proper Breaks/Replaces in the
`debia
Hi!
Sorry, my email client auto-completed as the "developers" mailing list
the one I usually write to, and not the one this was intended to be
submitted at...
Anyway, I am sure there are some Emacs users here too and if you never
heard about Magit+Forge then maybe this was useful info.
> [1] htt
Hi!
I don't use Emacs myself, but I learned last weekend at FOSDEM that
some Emacs users love using the Emacs extension Magit [1] with the
Forge [2] feature to list and review GitHub Pull Requests directly
from Emacs without opening a browser.
Just curious to know if any Emacs users here (Monty?)
Hi!
> > - because it is not easy and fast to migrate and if you do it you have to
> > redo the local repository, if you are alone working on the repository it is
> > not a big problem while if you are many it can create inconveniences
>
> IMO this is the real hurdle.
> Migrating thousands (in the
Hi!
> > I'm going to have to disagree with this part, the whole point of DEP14
> > is that our debianisms are namespaced, so there's no harm in pushing
> > all branches.
>
> Are you really sure that there is no harm in, for example, pushing all
> the 5785 (and counting) branches of https://github.
Hi Rene,
> What should debian/latest be? The latest upstream (pre-)release? Aka what is
> in experimental? Or not even there,
> just preparing stuff for experimental?
This is a good question, as it goes to the core of why DEP-14
recommends debian/latest first, respectively in the debian/unstable
> Is there some way to drill down into groups and then set preferences on
> an individual repo that's not in one's own namespace?
Yes - you can for example open https://salsa.debian.org/debian/openqa
and in the top right corner click on the bell icon, and select
"Watch". That will make you get not
Hi Jonas!
> > If you don't like using Salsa or don't like reviewing Merge Requests,
> > then this call is probably not for you. However, if you want Debian to
> > grow and you want to welcome new contributors, or in general work in a
> > collaborative way towards ending single-maintainer packages,
Thanks everyone for sharing your viewpoints, it is interesting to read!
I feel I need to clarify that I am not a native English speaker and my
intent was to write a polite and honest email. It does not say
anywhere that "you must use debian/latest". I am happy with whatever
the convention is, as l
Hi,
On Thu, 23 Jan 2025 at 17:52, Wookey wrote:
..
> Right. I look at bug reports for my packages (eventually). I have
> never looked at a Salsa merge request in my life. That's just
> /dev/null for my packages. That could change one day, but I don't know when.
Could you give it a try please? Sa
Hi!
Current https://dep-team.pages.debian.net/deps/dep14/ states that the
default Debian branch name is 'debian/latest':
> In Debian this means that uploads to unstable and experimental should be
> prepared either in
> the debian/latest branch or respectively in the debian/unstable and
> debian
Hi!
> I think it would improve collaboration a lot if we could make an effort
> to get salsa projects into one of two states:
>
> * Merge requests are disabled for that project
>
> * Merge requests are actively watched at least as closely as the BTS
We should revisit the decision to have email no
Hi Matthew!
> > Numerous people are posting Merge Requests on Salsa. Please help review
> > them!
>
> I'd much much rather MRs were associated with bug reports; that way I
> only have to remember to check one place for outstanding issues in my
> packages, and years down the line when I wonder "wh
Hi,
> Are discussions at Salsa preserved years down the line?
I don't think there is any special concern to suspect that Salsa or
any other official Debian service would seize to exist abruptly?
GitHub.com and GitLab.com has done a pretty good job at hosting
contents for years and years, hopefull
Hi,
While discussing git-buildpackage use, various DEP-14 branches,
pristine-tar purpose, how to correctly filter/repackage upstream
tarballs in past 6 months I noticed that many people have
misconceptions of what is the purpose of the various branches and how
git merges across them are supposed t
Hi all!
If you haven't noticed, lintian.debian.org has been online now for
almost 4 months.
A special thanks for that goes to Nicolas Peugnet for creating
lintian-ssg that generates the site, and Louis-Philippe Véronneau
(pollo) for taking care of Lintian!
After lintian.debian.org went offline i
> > 938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests
> [..]
> > If you have some spare time for Debian today, please consider
> > collaborating with another maintainer by providing them
> > review/feedback on an open Merge Request.
>
> I gave this, specifically reviewing MRs in th
Hi,
Numerous people are posting Merge Requests on Salsa. Please help review them!
There is no single dashboard to show all Merge Requests for all Debian
packages, but here are the largest teams listed to show how many they
have open (and total count in parentheses):
938 (9657) https://salsa.debi
Hi,
> I've been parsing a few package lists lately for nefarious reasons. Some
> packages have Built-Using or Static-Built-Using tags, which seem to
> serve the same purpose.
>
> Is there a subtle difference I need to be aware of?
I suspect the best summary of the situation is in the attachment i
> please be careful in your efforts to make contributing easier to not alienate
> those who already contribute, sometimes for decades. also: it's rather easy to
> kill motivation but very hard to revive it, once killed.
The above got quoted in the latest LWN, so it may be a sign that the
above vie
...
> Debian should consider allocating some budget like several hundred USD
> per month for the LLM API calls for all members and new-comers' usage.
I don't think Debian should as an organization pay for LLMs. On the
contrary I would expect LLM providers to offer API keys for free to
Debian Devel
Hi!
(cross-posting to mentors as they have most experience on what is
wrong with our current docs)
...
> Even if somebody in Debian community has enough time to overhaul everything
> and create a new documentation, it will become the situation described
> in XKCD meme "standards": xkcd.com/927/ -
> > two things: first, what is a "core component of Debian" is very much up to
> > debate, but I'd be quite surprised if anybody made the case that adequate
> > is.
>
> adequate is run on all 7 binary packages on piuparts.debian.org. I'm
> really
> curious whether this will blow up when piupa
Hi,
> > > This change basically adds the recommendation to use "upstreamvcs" as the
> > > name of the "git remote" to access the upstream repository and it also
> > > documents the possibility to merge the upstream commits in the
> > > "upstream/latest" branch (as proposed by gbp import-orig
> > >
Hi,
> > > While I'd love to see all packages on Salsa
> >
> > I think that being able to host the primary git repository of packages
> > elsewhere is a freedom worth maintaining for many reasons.
>
> No, I don't think this is a good idea, and at my first thought, I
> personally don't see any pract
> That's fair. I maintain a package of a project where I eventually
> moved the upstream codebase into revision control but have been too
> lazy/distracted to do the same for the debian directory (which I
> realistically only update once every year or two). I'm committed to
> importing that into Sa
Thanks for encouragement. I filed
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/411 and will
continue research on libfaketime/datefudge in CI there.
Hi,
> Gioele Barabucci:
> We need different levels of responsibility:
>
> * Nobody cares ⇒ orphan package
> * I care a bit, but I don't have time to handle all the responsibilities
> that a maintainership entail, but try to contact me anyway, I may reply
> ⇒ MISSING LEVEL discussed here
> * I care
Hi!
> This is an update for my previous MBF announcement here:
>
> https://lists.debian.org/debian-devel/2024/05/msg00414.html
>
> I did another test rebuild and found 11 new packages failing
> in the not-so-distant future. I also found another package
> for which the fix was lost and the bug had
Hi!
> Number of packages not on Salsa
> ---
>
> In my campaign, I stated [os1] that I aimed to reduce the number of
> packages maintained outside Salsa to below 2,000. As of March 28, 2024,
> the count was 2,368. As of this writing, the count stands at 1,928
> [os2], so
Hi,
If you have some spare time for Debian today, please consider
collaborating with another maintainer by providing them
review/feedback on an open Merge Request.
There are currently 938 open merge requests in the main Debian group on Salsa:
https://salsa.debian.org/groups/debian/-/merge_request
Hi,
> >> >> i think the barrier is likely to be "i didnt know you could do that?"
> >> >> rather than "how do i use that?"
> >> >
> >> > Salsa CI is and has always been opt-in.
> >>
> >> oops - i meant the oppposite, ie make people have to opt out of having
> >> it run, rather than have to enable
> >> > Salsa CI is a great system for all aspiring Debian packagers to test
> >> > their packages before requesting review from mentors
> >>
> >> > However, as there are still packages not using Salsa CI, I wonder is
> >> > it straightforward enough for everyone?
> >> >
> >>
> >> I think the best s
Hi!
> > Salsa CI is a great system for all aspiring Debian packagers to test
> > their packages before requesting review from mentors
>
> > However, as there are still packages not using Salsa CI, I wonder is
> > it straightforward enough for everyone?
> >
>
> I think the best solution would be to
Hi all,
This list has had plenty of discussions regarding best practices in
packaging. I noticed some of the views stemmed out of
misunderstandings or unawareness of certain easy to use
solutions and techniques exist. Hence, I am glad to see that Guido
just uploaded git-buildpackage 0.9.36, which
Hi,
> Before we move on, please allow me to ask what problem the nproc tool is
> supposed to solve. Of course it tells you the number of processors, but
> that is not a use case on its own. If you search for uses, "make
> -j$(nproc)" (with varying build systems) is the immediate hit. This use
> i
Hi!
Salsa CI is a great system for all aspiring Debian packagers to test
their packages before requesting review from mentors, and also for
experienced packagers to ensure there are no easily testable lapses
before uploading to Debian.
Anyone with a Salsa account can use it. Simply follow the REA
> From
> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group:
>
> The debian group is for CollaborativeMaintenance (the old collab-maint
> on Alioth).
>
> The group is accessible to all Debian developers upon linking their
> SSO Account, and are granted Maintain
> > Commits onto a git repo can be reversed easily (via `git revert`
> > or forced push, if one really wants to), but problematic uploaded
> > packages to the archive are irreversible and might cause broader
> > damages. That is why people are okay with allowing random git commits
> > to Debian gro
> The https://go-team.pages.debian.net/ pages may have some flaws, but one
> key social function is that it establishes the group as a team effort.
> That goal is something to take after. I'm trying migrate my
+1
> pkg-auth-maintainers packages to pkg-security just because
> https://wiki.debian.
> > I changed my personal preference from DEP-0 to DEP0 as I now consider
> > DEP0 the best option based as I have seen so much of RFC822, dep3,
> > dep8 and DEP14 in use in many places. However, that +22 for DEP-0 is
> > pretty large majority so I have to conclude it won.
>
> "it won", yes, but wh
[...]
> Can we agree on calling Debian Enhancement Proposals DEP-N with a dash?
>
> My eyes get sore when looking at commit messages like these:
>
> * cd4d154 DEP 15: initial draft
> * f54478c DEP8: Fix link to current specification
> * 1f20e9d DEP-14: Version -> refname mangling: Escape dots
Resu
Hi,
> [forking to -devel]
>
> On Wed Dec 11, 2024 at 11:15 AM CET, Holger Levsen wrote:
> > On Tue, Dec 10, 2024 at 09:38:57PM +0100, Serafeim (Serafi) Zanikolas wrote:
> > > > On Sat Dec 7, 2024 at 5:15 AM CET, Paul Wise wrote:
> > > > Probably adequate is the logical place for this test, but ade
Hi,
> > While I personally think e-mail-based workflows can be quite nice, the
> > BTS' asynchronous nature did cause me a lot of extra pointless work
> > when I was an outsider attempting to learn the ropes. Being not 100%
> > confident with the system, I way too often found myself waiting
> > mi
Hi and thanks for quick reply,
> > As you know I have been testing dgit and reviewing tag2upload, and to
> > my understanding tag2upload will generate the *.orig.tar.gz tarballs
> > using dgit
>
> (Using 'git deborig', not dgit.)
Right, it is a separate tool in devscripts
(https://manpages.debian
Hi!
...
> - tag2upload will improve the situation with .orig.tar because the
> tag2upload server will always ensure that the uploaded source package
> is prepared using an .orig.tar that dak will be happy with.
> It won't matter what you're using locally for, e.g., the purpose of
> feeding
Hi,
> > Wouldn't another option be to allow for multiple ways to write things,
> > as long as they are consistently written in the same style for the same
> > purpose?
> >
> > I prefer writing DEP 4711 in text.
> >
> > I prefer writing https://example.org/dep4711.txt in URLs.
> >
> > I prefer writ
Hi
On Fri., Nov. 29, 2024, 15:20 Richard Lewis,
wrote:
> > Please also help Guido iterate on git-buildpackage so that it works
> > well, is easy to debug, has good docs etc. Based on discussions in
> > this thread there are a lot of people with misconceptions and
> > polishing the docs would be t
> I believe that Otto's lets-standardize-on-salsa effort is fundamentally
> a good thing. Let's help him flesh out the details.
Thanks!
Please also help Guido iterate on git-buildpackage so that it works
well, is easy to debug, has good docs etc. Based on discussions in
this thread there are a l
Thanks Pirate Praveen for providing the first actual concrete case in
this thread where pristine-tar had some issue!
I noticed an interesting thing about this case:
± origtargz --download-only
pristine-tar: successfully generated
../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
prist
Thanks Gioele for the stats. I noticed that 90% of the votes came in
the first two days.
In this system you can unvote and put your thumbs up on another
proposal if you want to change your mind now after letting the
question sink in for a few weeks, but please make sure you have voted
only on one
Hi!
On Wed, 27 Nov 2024 at 00:47, wrote:
>
> Hi Johannes,
>
> Le 2024-11-22 12:45, Johannes Schauer Marin Rodrigues a écrit :
> > That's what I'm doing. But that works with tarballs not with upstream
> > as git.
> > If upstream (deliberately, so this will not change) has DSFG-non-free
> > content
Hi,
(replying in one email to various comments in past 24h)
> How common debian/gbp.conf points at something else: perhaps gbp's
> defaults are not good, if that many packages need to override them.
First of all may I ask you to not use terms like 'not good' as it may
come off negative towards t
Hi Alexandru!
I suggest you enable Salsa CI for the repository. It will immediately
reveal a couple of errors you have, and give you feedback when they
are fixed. Here is an example of Salsa CI enabled in a Python package:
https://salsa.debian.org/python-team/packages/rdiff-backup/-/blob/debian/la
> > I'm still trying to understand if it's a good idea to contact
> > upstream authors and tell them their software is being worked on to
> > be included in Debian, or not.
..
> So my advice is to go for it, maintaining software in Debian is much
> more fun when there is a positive exchange with th
> [ Requiring two party sign-off on every change ]
> > I wonder if it would make sense to organize some kind of "office
> > hours" for code reviews and code testing best practices and
> > guidance...
>
> As someone working in a very large organization where this is required:
> That's fine in a comp
Hi!
> > I am contemplating if I should also make videos on Debian packaging best
> > practices, or have start a new Matrix channel specifically to help
> > maintainers setup their git repositories correctly and find the optimal
> > git-buildpackage commands for each thing they want to do.
>
> I'd
Hi,
> > and you seem to think adding another Debian specific complex tool will
> > attrack new people? Most people^wcontributors out there know git already,
> > for them a simple git only workflow is *much* more inviting than having
> > to learn gbp *only* to contribute to Debian.
>
> This. Exactl
Hi,
> > > fwiw, I'm also not using git-buildpackage and I don't want to. (Step
> > > learning
> > > curve, too much magic, hard to debug and I dont see benefits for the
> > > packages
> > > I maintain.) I'm also not a beginner. And I love gbp-dch.
> > I think git-buildpackage is great, and I am
> > collecting stats from Debian packages, using for example data points
> > that 13573 packages in Debian have explicitly a debian/gbp.conf file
> > already.
>
> I guess those data points include how many packages use salsa, with
> various Gitlab features enabled.
>
> Since various Gitlab features
Hi!
> > I published a complete rewrite of the earlier draft as:
> >
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/12
> > DEP-18: Encourage Continuous Integration and Merge Request
> > based Collaboration for Debian packages
> >
> > If you are in favor of having this as a
Hi!
> fwiw, I'm also not using git-buildpackage and I don't want to. (Step learning
> curve, too much magic, hard to debug and I dont see benefits for the packages
> I maintain.) I'm also not a beginner. And I love gbp-dch.
I think git-buildpackage is great, and I am a happy user. However, it
too
Hi!
> With all the recent talk about increasing the use of git for
> packaging, I'd like to address one thing: git-buildpackage is very
> complex to use. As an alternative, I'd like to propose a simpler
> setup:
..
> sick of it and I can tell you it only makes me want to ignore you. If
> you ask
this way of working, and hopefully doing it in a way that it
does not stifle work for maintainers who prefer to continue their
single-maintainer habits, so nobody feels at loss.
On Tue, 27 Aug 2024 at 19:13, Otto Kekäläinen wrote:
>
> Hi!
>
> While I intend to continue on iterating
Thanks for the comments!
Let's implement this. Please vote on which variant you prefer by
giving a thumbs up at
https://salsa.debian.org/dep-team/deps/-/merge_requests/13
Unify DEP spelling with a dash instead of a space (e.g. "DEP-0")
OR
https://salsa.debian.org/dep-team/deps/-/mer
Your are right Simon, the body actually says "DEP0" and only title has
DEP-0 (
https://salsa.debian.org/dep-team/deps/-/blob/master/web/deps/dep0.mdwn#L1).
The changelog even has "DEP 0".
Front page of dep-team.pages.debian.net spells it with a space.. The role
model https://peps.python.org/pep-00
Hi all,
I am the kind of person that gets hugely annoyed by things like this.
Is anyone else feeling it?
Can we agree on calling Debian Enhancement Proposals DEP-N with a dash?
My eyes get sore when looking at commit messages like these:
* cd4d154 DEP 15: initial draft
* f54478c DEP8: Fix link
Hi!
On Mon, 11 Nov 2024 at 11:37, Andrey Rakhmatullin wrote:
>
> On Mon, Nov 11, 2024 at 06:03:22PM +0100, Alexandre GRIVEAUX wrote:
> > Hello,
> >
> > Some time ago I created some merge request on salsa for debian-xen:
> >
> > https://salsa.debian.org/xen-team/debian-xen/-/merge_requests?scope=a
1 - 100 of 234 matches
Mail list logo
