git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).