> On Mon, 22 Sep 2014, W Trevor King wrote:
> There's no Signed-off-by on the commits adding the DCO to the Linux
> tree ;). The only information I can find claiming copyright and
> licensing by one of the DCO authors is at
> http://developercertificate.org/. I suppose you could alter the DC
On Mon, Sep 22, 2014 at 04:56:58PM -0400, Rich Freeman wrote:
> In any case, I don't think it is necessary to actually modify the DCO.
Ah, good. Then the verbatim copy license is sufficient, and we don't
need to decide if the GPLv2 with Linus' exception applies.
> I don't believe that it require
On Mon, Sep 22, 2014 at 3:43 PM, W. Trevor King wrote:
> There's no Signed-off-by on the commits adding the DCO to the Linux
> tree ;). The only information I can find claiming copyright and
> licensing by one of the DCO authors is at
> http://developercertificate.org/. I suppose you could alter
On Mon, Sep 22, 2014 at 03:35:29PM -0400, Rich Freeman wrote:
> On Mon, Sep 22, 2014 at 3:27 PM, W. Trevor King wrote:
> > On Mon, Sep 22, 2014 at 03:13:35PM -0400, Rich Freeman wrote:
> >> On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote:
> >> > On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich
On Mon, Sep 22, 2014 at 3:27 PM, W. Trevor King wrote:
> On Mon, Sep 22, 2014 at 03:13:35PM -0400, Rich Freeman wrote:
>> On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote:
>> > On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote:
>> >> Perhaps the c clause should be clarified that t
On Mon, Sep 22, 2014 at 03:13:35PM -0400, Rich Freeman wrote:
> On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote:
> > On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote:
> >> Perhaps the c clause should be clarified that the source files
> >> themselves were not modified - not the c
On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote:
> On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote:
>> Perhaps the c clause should be clarified that the source files
>> themselves were not modified - not the commit message.
>
> The DCO text is verbatim copies only [1], so I don'
On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote:
> Perhaps the c clause should be clarified that the source files
> themselves were not modified - not the commit message.
The DCO text is verbatim copies only [1], so I don't think adjusting
clauses is legal. And if you're modifying ne
On Mon, Sep 22, 2014 at 12:52 PM, W. Trevor King wrote:
> On Mon, Sep 22, 2014 at 11:29:52AM -0400, Rich Freeman wrote:
>> On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller wrote:
>> > Another issue, should we require "Signed-off-by:" lines? At least
>> > for things that are contributed by users?
>
On Mon, Sep 22, 2014 at 11:29:52AM -0400, Rich Freeman wrote:
> On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller wrote:
> > Another issue, should we require "Signed-off-by:" lines? At least
> > for things that are contributed by users?
> >
> > …
>
> Thanks for bringing this up. I had circulated t
On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller wrote:
>> On Mon, 22 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
> On Mon, 22 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.
Another issue, shou
On 09/22/2014 08:40 AM, Ulrich Mueller wrote:
>> 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
On Mon, 22 Sep 2014 08:56:04 +0200
Michał Górny wrote:
> How can we distinguish between accidental and intentional stable
> keyword removals? :)
(The lack of) Proper commit messages that point out those removals! ;)
But well, yeah, that'll require consistency and so on...
On Fri, 19 Sep 2014 16:03:57 +0200
Tobias Klausmann wrote:
> As I pointed out, getting the right code into the tree is not the
> problem here. It is extra work over the current way of doing it
> (since I need to deal with a local commit that can't be ff'd or
> rebased as git is very line-oriented
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
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
Rich Freeman:
>
> Would it make more sense to use a migrated repository as the starting
> point, such as this one:
> https://github.com/rich0/gentoo-gitmig-2014-09-15
>
Not sure why. The old history is irrelevant for testing git workflow.
The repository is also fairly small, even without shallo
On Sat, Sep 20, 2014 at 10:28 AM, hasufell wrote:
> Ian Stakenvicius:
>>> I wonder if it would make sense to set up a practice git tree
>>> somewhere so that people can try working together on workflows/etc.
>>> We can clone a migrated tree (I have one from a few days ago on
>>> github).
>>
>> Def
Ian Stakenvicius:
>> I wonder if it would make sense to set up a practice git tree
>> somewhere so that people can try working together on workflows/etc.
>> We can clone a migrated tree (I have one from a few days ago on
>> github).
>
> Definitely. I'd volunteer for that (doing my updates to bot
> On Fri, 19 Sep 2014, hasufell wrote:
> There is no reason to roll back commits or do merge commits for the
> keywords conflict use case. So I don't see what else needs
> discussion here, except the proposal from ulm.
About an optimised merge driver for ebuilds? Please don't see this as
a b
Ian Stakenvicius:
> Git on the other hand will update the entire
> tree and there's no way around that, right?
Yeah, people have to understand that we cannot map the cvs workflow 1:1
to git.
That's for a reason and that little inconvenience it causes is pretty
minor compared to the breakage CVS a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/14 11:10 AM, Ian Stakenvicius wrote:
>
> I don't think there's any valid debate on whether git is more
> efficient than cvs on fetching tree-wide updates :)
>
erm, that was worded wrong, let me try again: I don't think there's
any valid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/14 10:48 AM, Rich Freeman wrote:
> On Fri, Sep 19, 2014 at 10:25 AM, hasufell
> wrote:
>>
>> That is pretty easy and takes you ~20s for a keyword merge.
>> What's the problem?
>>
>
> Agree. Also, there was a comment that git pull is m
On Fri, Sep 19, 2014 at 10:25 AM, hasufell wrote:
>
> That is pretty easy and takes you ~20s for a keyword merge. What's the
> problem?
>
Agree. Also, there was a comment that git pull is much slower than
cvs. While it is true that git does refresh the whole tree all the
time, it is FAR more ef
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.
>>>
>>
>> Certainly that would be
Hi!
On Fri, 19 Sep 2014, Tom Wijsman wrote:
> On Thu, 18 Sep 2014 19:39:08 +0200
> Tobias Klausmann wrote:
>
> > AIUI, we try to avoid merge conflicts, unless the merge is a
> > meaningful integration of divergent processes.
> >
> > However, one aspect of how ebuilds are written these days wil
On Thu, 18 Sep 2014 19:39:08 +0200
Tobias Klausmann wrote:
> AIUI, we try to avoid merge conflicts, unless the merge is a
> meaningful integration of divergent processes.
>
> However, one aspect of how ebuilds are written these days will
> cause a non-trivial amount of merge commits that are not
On 19 September 2014 06:51, Rich Freeman wrote:
>
> Git even allows the use of tools like meld to resolve conflicts,
> besides the usual fill-the-file-with-diffs-to-cleanup approach.
I'd personally discourage any kind of collision resolution in the merge
itself.
Mostly because I've been bitten
Hi!
On Thu, 18 Sep 2014, Rich Freeman wrote:
> On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller wrote:
> >> On Thu, 18 Sep 2014, Tobias Klausmann wrote:
> >
> >> However, one aspect of how ebuilds are written these days will
> >> cause a non-trivial amount of merge commits that are not actual
On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller wrote:
>> On Thu, 18 Sep 2014, Tobias Klausmann wrote:
>
>> However, one aspect of how ebuilds are written these days will
>> cause a non-trivial amount of merge commits that are not actually
>> useful in that sense.
>
Git can do merge conflict
> On Thu, 18 Sep 2014, Tobias Klausmann wrote:
> However, one aspect of how ebuilds are written these days will
> cause a non-trivial amount of merge commits that are not actually
> useful in that sense.
> This is due to the way keywording and stabilization work on an
> ebuild level. Since ke
Hi!
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 a
meaningful integration of divergent processes.
However, one aspect
44 matches
Mail list logo
