Dnia 2014-09-20, o godz. 21:20:34
Rich Freeman ri...@gentoo.org napisał(a):
On Sat, Sep 20, 2014 at 8:58 PM, Gordon Pettey petteyg...@gmail.com wrote:
You're following the wrong train down the wrong tracks. Git [0-9a-f]{40} is
to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure
On Sun, 21 Sep 2014, Michał Górny wrote:
Rich Freeman ri...@gentoo.org napisał(a):
Ulrich is well-aware of that. His argument is that with cvs there
is no security whatsoever in the scm, and so there is more interest
in layering security on-top. With git there is more of a tendency
to
Ulrich Mueller:
Full manifests could be generated automatically (and signed with an
infra key) when copying the tree from the repository to the master
mirror.
Would you like to implement it?
Dnia 2014-09-21, o godz. 09:54:06
Ulrich Mueller u...@gentoo.org napisał(a):
On Sun, 21 Sep 2014, Michał Górny wrote:
Rich Freeman ri...@gentoo.org napisał(a):
Ulrich is well-aware of that. His argument is that with cvs there
is no security whatsoever in the scm, and so there is more
On Sun, 21 Sep 2014, Michał Górny wrote:
Do you really consider keeping a key open for machine signing
somewhat secure?
You mean, as compared to manifests (or commits) signed by 250
different developers' keys?
Ulrich
pgpF0PMDGXMa0.pgp
Description: PGP signature
On Sun, Sep 21, 2014 at 2:13 PM, Ulrich Mueller u...@gentoo.org wrote:
On Sun, 21 Sep 2014, Michał Górny wrote:
Do you really consider keeping a key open for machine signing
somewhat secure?
You mean, as compared to manifests (or commits) signed by 250
different developers' keys?
Ulrich
Ulrich Mueller:
On Sun, 21 Sep 2014, Michał Górny wrote:
Do you really consider keeping a key open for machine signing
somewhat secure?
You mean, as compared to manifests (or commits) signed by 250
different developers' keys?
That's the actual security problem in gentoo: 250 developers
Hi!
On Fri, 19 Sep 2014, hasufell wrote:
Tobias Klausmann:
If this should really turn out to be a problem, then we could also:
4) Replace git's default merge driver by our own one that is better
suited for ebuilds. This can be done per repository via .git/config
and .gitattributes.
Tobias Klausmann:
When we do the migration, there _will_ be
confusion and breakage and those who actually have deep knowledge
will likely cringe a lot. Documentation is the way out of that.
https://wiki.gentoo.org/wiki/Gentoo_git_workflow
But so far, not many people have been particularly
Dnia 2014-09-18, o godz. 19:39:08
Tobias Klausmann klaus...@gentoo.org napisał(a):
Since we're causing at least mild upheaval process-wise, I
thought I'd bring up a topic that will be exacerbated by the git
migration if it's not really addressed.
AIUI, we try to avoid merge conflicts,
On Sun, 21 Sep 2014, hasufell wrote:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow
But so far, not many people have been particularly interested in the
details of these things. I'm also not sure if the ML is the right
way to figure out these details.
Where else should this be discussed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/21/2014 01:21 PM, Michał Górny wrote:
Dnia 2014-09-18, o godz. 19:39:08 Tobias Klausmann
klausman-abrp7r+bbdudnm+yrof...@public.gmane.org napisał(a):
Since we're causing at least mild upheaval process-wise, I
thought I'd bring up a
Jonathan Callen wrote:
the correct response would be to ensure that the final commit
pushed (whether it be a merge commit or rebased) contains the
stabilization for both arches
I think this is one of the things to check in a post-receive or
post-update hook. What is the easiest way to access
On Sun, 21 Sep 2014, Peter Stuge wrote:
Jonathan Callen wrote:
the correct response would be to ensure that the final commit
pushed (whether it be a merge commit or rebased) contains the
stabilization for both arches
I think this is one of the things to check in a post-receive or
Ulrich Mueller:
On Sun, 21 Sep 2014, hasufell wrote:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow
But so far, not many people have been particularly interested in the
details of these things. I'm also not sure if the ML is the right
way to figure out these details.
Where else
hasufell wrote:
A version bump plus cleaning up older ebuilds will be considered
one logical change, I suppose?
I'd consider it two logical changes
..
But I don't have a strong opinion on that
I do - I think this is really important. Having clean history makes a
huge difference for anyone
On Sun, Sep 21, 2014 at 9:08 PM, Peter Stuge pe...@stuge.se wrote:
hasufell wrote:
A version bump plus cleaning up older ebuilds will be considered
one logical change, I suppose?
I'd consider it two logical changes
..
But I don't have a strong opinion on that
I do - I think this is
On Monday 22 September 2014 00:52:14 hasufell wrote:
| • repoman must be run from all related ebuild directories (or
|
| related category directories or top-level directory) on the tip of
| the local master branch (as in: right before you push and also
| after resolving
Rich Freeman posted on Sun, 21 Sep 2014 21:46:14 -0400 as excerpted:
On Sun, Sep 21, 2014 at 9:08 PM, Peter Stuge pe...@stuge.se wrote:
hasufell wrote:
A version bump plus cleaning up older ebuilds will be considered one
logical change, I suppose?
I'd consider it two logical changes ...
19 matches
Mail list logo
