From: <rsbecker@nexbridge.com>
To: "'Chris Hofstaedtler'" <zeha@debian.org>,
"'Simon Richter'" <sjr@debian.org>
Cc: <git@vger.kernel.org>, <debian-devel@lists.debian.org>
Subject: RE: Representing Debian Metadata in Git
Date: Wed, 21 Aug 2024 19:11:40 -0400 [thread overview]
Message-ID: <029801daf41f$7e994b70$7bcbe250$@nexbridge.com> (raw)
In-Reply-To: <gbgpxxpikhkykvhug4ugbufqm6bdh44ygiknpzc3khalibwutk@jlebwg4vsvjt>
On Wednesday, August 21, 2024 5:38 PM, Chris Hofstaedtler wrote:
>* Simon Richter <sjr@debian.org> [240820 09:11]:
>> One of the long-standing issues is that there are multiple ways Debian
>> packaging can be represented in a git tree, and none of them are optimal.
>[..]
>> A possible implementation would be a type of Git "user extension"
>> object that contains
>>
>> - an extension name
>> - an object type (interpreted by the extension)
>> - type-tagged references to other objects
>> - other type-tagged data
>[..]
>
>> Any feelings/objections/missed requirements?
>
>In the current DEP14/DEP18 discussions a lot of discussion was had about how we
>should represent Debian things in git; your mail also goes into this direction.
>
>My *feeling* is we should do the opposite - that is, represent less Debian stuff in git,
>and especially do it in less Debian-specific ways. IOW, no git extensions, no setup
>with multiple branches that contain more or less unrelated things, etc.
>
>I think we should move more towards a setup that is easily understood by people
>not closely following our Debian-specific things. We should avoid surprising things,
>again that would include the multiple branches and any git extensions.
>
>Before pushing for new ways of representing Debian stuff in git, I think it would be a
>good idea to learn from all the other distros and distro-like systems successfully
>using git [1]. Debian is not the only distro that wants to use git to capture changes
>and encourage contributions to its packages.
On the other side (perhaps), git is increasingly being used in the Ops setting for
DevOps and DevSecOps. Production configurations for high-value applications are
moving to storing those configurations into git for tracing and audit. Git is an
enabler for good production operations practices. My $0.02 (and my customers')
--Randall
next prev parent reply other threads:[~2024-08-21 23:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-20 7:10 Representing Debian Metadata in Git Simon Richter
2024-08-21 21:37 ` Chris Hofstaedtler
2024-08-21 23:11 ` rsbecker [this message]
2024-08-21 23:51 ` Chris Hofstaedtler
2024-08-22 19:27 ` Blair Noctis
2024-08-23 2:20 ` Sean Whitton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='029801daf41f$7e994b70$7bcbe250$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=debian-devel@lists.debian.org \
--cc=git@vger.kernel.org \
--cc=sjr@debian.org \
--cc=zeha@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).