Dnia 2014-09-21, o godz. 23:36:58
Peter Stuge napisał(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
> On Mon, 22 Sep 2014, hasufell wrote:
> Ulrich Mueller:
>> | • atomic commits (one logical change)
>>
>> A version bump plus cleaning up older ebuilds will be considered
>> one logical change, I suppose?
> I'd consider it two logical changes (e.g. imagine a user complaining
> about ebuild
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 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 ...
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 p
On Sun, Sep 21, 2014 at 9:08 PM, Peter Stuge 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 rea
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
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.
>
> 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
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
-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
> 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
>>
> 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 d
Dnia 2014-09-18, o godz. 19:39:08
Tobias Klausmann 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, unless the merge is
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 particularl
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
> >>> an
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:
On Sun, Sep 21, 2014 at 2:13 PM, Ulrich Mueller 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
> 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
Dnia 2014-09-21, o godz. 09:54:06
Ulrich Mueller napisał(a):
> > On Sun, 21 Sep 2014, Michał Górny wrote:
>
> > Rich Freeman 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 l
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?
> On Sun, 21 Sep 2014, Michał Górny wrote:
> Rich Freeman 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 rely o
Dnia 2014-09-20, o godz. 21:20:34
Rich Freeman napisał(a):
> On Sat, Sep 20, 2014 at 8:58 PM, Gordon Pettey 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 because its
> > commits are sequen
21 matches
Mail list logo
