"Philipp Kern" writes:
> On Sun Nov 24, 2024 at 4:45 AM CET, Otto Kekäläinen wrote:
>> To me the whole free and open source movement is about collaboration,
>> transparency and the ethos of "given enough eyeballs, all bugs are
>> shallow".
> The "given enough eyeballs" always happened after the
On Sun Nov 24, 2024 at 4:45 AM CET, Otto Kekäläinen wrote:
> > [ 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
> [ 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
On 11/10/24 3:42 AM, Otto Kekäläinen wrote:
[ 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
Hi!
...
> > - The number of contributors/maintainers is low everywhere. Ending
> > single-person maintainership is not going to happen any soon, but hopefully,
> > we can work towards first increasing the pool of contributors who
> > participate, and then expand on practices around Merge Requests
Hi,
Quoting Otto Kekäläinen (2024-08-27 08:42:53)
> > 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
Hi!
Considering what other Linux distros are doing and what is popular
among software developers today, Debian will probably gain more
contributors and be more approachable if we don't reinvent too many
custom things, and hence...
..
> In the current DEP14/DEP18 discussions a lot of discussion wa
Hello,
I think that more than you realise of this already exists :)
On Tue 20 Aug 2024 at 04:10pm +09, Simon Richter wrote:
> From a requirements perspective, I'd like to be able to
>
> - express patches as commits:
>- allow cherry-picking upstream commits as Debian patches
>- allow che
On Aug 22, Aurélien COUDERC wrote:
> I personally think it’s crazy / not a good use of my time to try and
> mix both upstream and packaging history in the same repo and try to
> make git dance around that when handling new upstream releases. The
> extents of the ongoing d-devel discussions on
On 2024-08-20 15:10, Simon Richter wrote:
(...)
> Right now, git is used mainly as a network file system, and only tagged
> releases are expected to be consistent enough to compile, because often
> going from one consistent state to another as an atomic operation would
> require multiple changes
Hi !
Le mercredi 21 août 2024, 23:37:38 CEST Chris Hofstaedtler a écrit :
> Hi Simon,
>
> * Simon Richter [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.
[…]
> > Any feeling
On 2024-08-21 19:11:40 -0400 (-0400), rsbec...@nexbridge.com wrote:
[...]
> 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 tr
* rsbec...@nexbridge.com [240822 01:21]:
> >> 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 sho
On Wednesday, August 21, 2024 5:38 PM, Chris Hofstaedtler wrote:
>* Simon Richter [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 typ
Chris Hofstaedtler writes:
> 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.
+1
I think this
Hi Simon,
* Simon Richter [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
Hi,
there's a bit of a discussion within Debian on collaborating using Git.
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.
The problem at hand is that the packaging workflow consists of
1. impor
17 matches
Mail list logo
