On Wed, Nov 19, 2014 at 7:36 PM, hasufell wrote:
>
> But keep in mind that the core is supposed to shrink with this idea of a
> distributed model! So it would be less work to actually roll/tag
> releases than it would be right now (or even do that stuff in branches).
This doesn't really make the
On Thu, 20 Nov 2014 01:36:11 +0100
"viv...@gmail.com" wrote:
> >> At that point it is forked. I don't see what's wrong with forking.
> > Forking wouldn't be the problem. Duplication of effort would be the
> > problem.
> worse, mutually incompatibility would be much worse
I was talking about wha
On 11/20/2014 12:58 AM, Rich Freeman wrote:
> On Wed, Nov 19, 2014 at 12:54 PM, hasufell wrote:
>> On 11/19/2014 06:27 PM, Jauhien Piatlicki wrote:
>>> On 11/19/2014 03:36 PM, hasufell wrote:
In the end, I'm not sure if this is actually such a big problem. You can
still use random e
Il 20/11/2014 01:00, Jeroen Roovers ha scritto:
> On Wed, 19 Nov 2014 18:54:05 +0100
> hasufell wrote:
>
>> At that point it is forked. I don't see what's wrong with forking.
> Forking wouldn't be the problem. Duplication of effort would be the
> problem.
>
>
> jer
>
worse, mutually incompati
Il 20/11/2014 00:58, Rich Freeman ha scritto:
> On Wed, Nov 19, 2014 at 12:54 PM, hasufell wrote:
>> On 11/19/2014 06:27 PM, Jauhien Piatlicki wrote:
>>> On 11/19/2014 03:36 PM, hasufell wrote:
In the end, I'm not sure if this is actually such a big problem. You can
still use random ebui
On Wed, 19 Nov 2014 18:54:05 +0100
hasufell wrote:
> At that point it is forked. I don't see what's wrong with forking.
Forking wouldn't be the problem. Duplication of effort would be the
problem.
jer
On Wed, Nov 19, 2014 at 12:54 PM, hasufell wrote:
> On 11/19/2014 06:27 PM, Jauhien Piatlicki wrote:
>> On 11/19/2014 03:36 PM, hasufell wrote:
>>>
>>> In the end, I'm not sure if this is actually such a big problem. You can
>>> still use random ebuilds from random overlays and commit them straigh
On 11/19/2014 06:27 PM, Jauhien Piatlicki wrote:
> On 11/19/2014 03:36 PM, hasufell wrote:
>>
>> In the end, I'm not sure if this is actually such a big problem. You can
>> still use random ebuilds from random overlays and commit them straight
>> to your own overlay.
>>
>
> A bad idea. Bad because
On 11/19/2014 03:36 PM, hasufell wrote:
> On 11/18/2014 02:12 PM, Jauhien Piatlicki wrote:
>>
>> On 11/18/2014 04:19 AM, hero...@gentoo.org wrote:
>>> Jauhien Piatlicki writes:
>>>
It would be probably good to have in the tree only the core components and
move other stuff to the themati
On 11/18/2014 02:12 PM, Jauhien Piatlicki wrote:
>
> On 11/18/2014 04:19 AM, hero...@gentoo.org wrote:
>> Jauhien Piatlicki writes:
>>
>>> It would be probably good to have in the tree only the core components and
>>> move other stuff to the thematic overlays.
>>>
>>> Then we can have a clear un
On 11/18/2014 03:02 PM, viv...@gmail.com wrote:
> Il 18/11/2014 14:12, Jauhien Piatlicki ha scritto:
>> On 11/18/2014 04:19 AM, hero...@gentoo.org wrote:
>>> Jauhien Piatlicki writes:
>>>
It would be probably good to have in the tree only the core components and
move other stuff to the
Il 18/11/2014 14:12, Jauhien Piatlicki ha scritto:
> On 11/18/2014 04:19 AM, hero...@gentoo.org wrote:
>> Jauhien Piatlicki writes:
>>
>>> It would be probably good to have in the tree only the core components and
>>> move other stuff to the thematic overlays.
>>>
>>> Then we can have a clear und
> 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
hasufell:
>
> First draft and only the basic ebuild workflow.
>
I'm working out the rest here
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#step_by_step_example_.28ebuild.29
On Wed, Sep 17, 2014 at 11:28 AM, hasufell wrote:
> NOTE: you may skip running repoman another time if you have manually
> verified that the commits you are missing are totally unrelated to your
> work (e.g. only affect a package that is not in the dependency chain of
> yours). You can do so via:
Daniel Campbell:
> As a prospective Gentoo developer, having a guide around meant
> specifically for Gentoo's practices would be incredibly helpful. I use
> git in my own hobby development and learned from Pro Git, et al, but
> it'd still be really nice to have, and give developers a place to
> poi
Rich Freeman:
>
> I suggest we just get git working in a fashion that is "good enough."
Sure, that's what I've been saying. Otherwise I'd propose to remove
access for everyone and only grant project leads/reviewers direct push
access. But as said... we are not ready for something like that.
Howe
hasufell wrote:
> * allow inconsistency and broken states as we do now with CVS (and rely
> on QA to run a repoman tinderbox and reverse-fixing broken crap)
...
> Rich Freeman:
>> It would make a lot more sense if we had a release-oriented strategy,
>> even if releases were hourly/daily/etc.
>>
Rich Freeman:
> It would make a lot more sense if we had a release-oriented strategy,
> even if releases were hourly/daily/etc.
>
If we are going that way, then we should think over the whole branching
model. I have a few things in mind, but I think we are already
fine-tuning stuff here that can
Ian Stakenvicius:
>
> I'm not that worried about the big (multi-package) commits, as it does
> make sense we're going to have difficulty and lots of potential
> conflicts there, but aren't we going to run into this issue just with
> multiple people committing separate single-package commits at the
On Mon, Sep 15, 2014 at 10:26 AM, Ian Stakenvicius wrote:
> I'm not that worried about the big (multi-package) commits, as it does
> make sense we're going to have difficulty and lots of potential
> conflicts there, but aren't we going to run into this issue just with
> multiple people committing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/09/14 09:13 AM, hasufell wrote:
> Rich Freeman:
>> On Mon, Sep 15, 2014 at 7:37 AM, hasufell
>> wrote:
>>> * repoman must be run from all related directories (or the
>>> top-level directory) on the latest commit that is being pushed
>>
>> Thi
Rich Freeman:
> On Mon, Sep 15, 2014 at 9:13 AM, hasufell wrote:
>> Yes, you have to rerun repoman after a rebase or merge. On the tip of
>> the local master branch (as in: right before you try to push).
>>
>> Sure, this may lead to problems if repoman takes long... but that's on
>> purpose. If yo
On Mon, Sep 15, 2014 at 9:13 AM, hasufell wrote:
> Yes, you have to rerun repoman after a rebase or merge. On the tip of
> the local master branch (as in: right before you try to push).
>
> Sure, this may lead to problems if repoman takes long... but that's on
> purpose. If your changes are that b
Rich Freeman:
> On Mon, Sep 15, 2014 at 7:37 AM, hasufell wrote:
>> * repoman must be run from all related directories (or the top-level
>> directory) on the latest commit that is being pushed
>
> This should be clarified. Does repoman need to be run on the exact
> commit that is being pushed,
On Mon, Sep 15, 2014 at 7:37 AM, hasufell wrote:
> * repoman must be run from all related directories (or the top-level
> directory) on the latest commit that is being pushed
This should be clarified. Does repoman need to be run on the exact
commit that is being pushed, or perhaps on a "parent
Andreas K. Huettel:
>>
>> However, rebasing changes *on* master, before they are pushed, is a good
>> thing, because that kills non-fast-forward merges.
>>
>
> Nontrivial rebases *on* master can be problematic because you're changing
> history.
>
> Imagine you pull some nice commits from a user
>
> However, rebasing changes *on* master, before they are pushed, is a good
> thing, because that kills non-fast-forward merges.
>
Nontrivial rebases *on* master can be problematic because you're changing
history.
Imagine you pull some nice commits from a user. Then at some point you will
h
"C. Bergström":
> Pretty please do NOT allow "merge" commits.. they are the bane of evil
> for the long term ability to have any sane work-flow.
It works pretty well for the linux kernel.
Ofc it's a matter of actually handling it. If people are unable to
properly handle tools/methods, everything
On 09/15/14 02:34 AM, hasufell wrote:
William Hubbs:
On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
Deciding on a _commit policy_ should be fairly straightforward and we
already have one point
* gpg sign every commit (unless it's a merged branch, then we only care
about the
William Hubbs:
> On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
>>
>>> Deciding on a _commit policy_ should be fairly straightforward and we
>>> already have one point
>>> * gpg sign every commit (unless it's a merged branch, then we only care
>>> about the merge commit)
>>
>>
On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
>
> > Deciding on a _commit policy_ should be fairly straightforward and we
> > already have one point
> > * gpg sign every commit (unless it's a merged branch, then we only care
> > about the merge commit)
>
> +1
Merge commits
> Deciding on a _commit policy_ should be fairly straightforward and we
> already have one point
> * gpg sign every commit (unless it's a merged branch, then we only care
> about the merge commit)
+1
> More things to consider for commit policy are:
> * commit message format (line length, maybe p
On Sun, Sep 14, 2014 at 11:11 AM, hasufell wrote:
>
> The only hard part is that people have to know the differences between
> merging/rebasing, fast-forward merges, non-fast-forward merges etc. and
> when and when not to do them.
>
> 'git rebase' is a powerful thing, but also pretty good to mess
On 13 August 2014 02:46, Michał Górny wrote:
> Dnia 2014-08-11, o godz. 20:48:20
> William Hubbs napisał(a):
>> > got a minor (but chatty) QA warning:
>> > DESCRIPTION ends with a '.' character
>>
>> Why is this a QA warning in the first place?
>
> Because it is a common mistake, and having t
On Mon, 11 Aug 2014 20:48:20 -0500
William Hubbs wrote:
> On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich wrote:
> > Hello World!
> >
> > TL;DR:
> > This evening I plan to mangle ~3000 ebuilds in the main tree
> > by dropping trailing '.' in all 'DESCRIPTION=' fields (except
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Friends,
the repoman patch is reverted. And that is the end of this.
I do not have gx86 access, so if someone wants me to revert 3K commits
there, I'll need a proxy...
- --
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BE
Chris Reffett:
>
> if people want to run this by Council
I'll laugh my ass off if this thing makes it on the council agenda xD
Dnia 2014-08-11, o godz. 20:48:20
William Hubbs napisał(a):
> On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich wrote:
> > Hello World!
> >
> > TL;DR:
> > This evening I plan to mangle ~3000 ebuilds in the main tree
> > by dropping trailing '.' in all 'DESCRIPTION=' fields (except
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/12/2014 9:26 AM, Rich Freeman wrote:
[snip]
> I don't have a problem with QA recommending new tree policies, but
> if they're going to do this the QA team ought to first ensure that
> the team agrees (however they want to govern that), and then
Dnia 2014-08-11, o godz. 22:34:06
Bertrand Jacquin napisał(a):
> Hi,
>
> On 2014-08-10 14:22, Sergei Trofimovich wrote:
>
> > The script does not handle case of multiline description:
> > DESCRIPTION="You have to
> > clean that yourself."
>
> You could handle this by reading metadata/m
On Tue, Aug 12, 2014 at 09:26:07AM -0400, Rich Freeman wrote:
*snip*
> Yeah, at best this seems a bit trivial. Do we have a policy that
> descriptions aren't allowed to be complete sentences? Many of our
> developers are not native English speakers in the first place, so
> striving for gramma
Rich Freeman:
> so striving for grammatical perfection is a bit optimistic.
In that case, we should just rm the repoman warning and stop discussing
this matter.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/14 08:47 AM, hasufell wrote:
> William Hubbs:
>> On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>>
>> *snip*
>>
>>> These links might be helpful:
>>>
>>> http://git.overla
On Tue, Aug 12, 2014 at 8:47 AM, hasufell wrote:
>
> First, a sentence does not need to have a predicate. I know that for 99%
> sure in german and the english wikipedia article seems to suggest the
> same. Correct me if I am wrong.
>
In English your typical English class would teach that every se
William Hubbs:
> On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>
> *snip*
>
>> These links might be helpful:
>>
>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=06637c4215d55c57517739214c6e0fd6f8f53914
how to i get off these mailing lists?
On Mon, Aug 11, 2014 at 7:42 PM, William Hubbs wrote:
> On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
>
> *snip*
>
> > These links might be helpful:
> >
> >
> http://git.overlays.gento
On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
*snip*
> These links might be helpful:
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=06637c4215d55c57517739214c6e0fd6f8f53914
>
> https://bugs.gentoo.or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/12/2014 03:48 AM, William Hubbs wrote:
> On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich
> wrote:
>> Hello World!
>>
>> TL;DR: This evening I plan to mangle ~3000 ebuilds in the main
>> tree by dropping trailing '.' in all 'DESCRI
On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich wrote:
> Hello World!
>
> TL;DR:
> This evening I plan to mangle ~3000 ebuilds in the main tree
> by dropping trailing '.' in all 'DESCRIPTION=' fields (except "etc." case)
>
> Long story:
>
> As you may know newest portage release
Hi,
On 2014-08-10 14:22, Sergei Trofimovich wrote:
The script does not handle case of multiline description:
DESCRIPTION="You have to
clean that yourself."
You could handle this by reading metadata/md5-cache/*/* instead of
ebuild itself
But is multiline DESCRIPTION something recomm
On Sun, Mar 16, 2014 at 09:36:02PM -0400, Mike Gilbert wrote:
> On Mon, Mar 10, 2014 at 7:30 PM, William Hubbs wrote:
> > All,
> >
> > for bug 373219 [1], we are working on providing a functions.sh that does
> > not rely on OpenRc so that people who are not using OpenRc can
> > completely remove i
On Mon, Mar 10, 2014 at 7:30 PM, William Hubbs wrote:
> All,
>
> for bug 373219 [1], we are working on providing a functions.sh that does
> not rely on OpenRc so that people who are not using OpenRc can
> completely remove it from their systems.
>
> I can now report that gentoo-functions has been
Dnia 2014-03-13, o godz. 07:59:55
Patrick Lauer napisał(a):
> On 03/13/2014 12:52 AM, William Hubbs wrote:
>
> >>> No, I don't think gentoo-functions should take over the symbolic
> >>> link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
> >>> My plan there is to work that into a s
On 03/12/2014 7:59 PM, Patrick Lauer wrote:
> On 03/13/2014 12:52 AM, William Hubbs wrote:
>
No, I don't think gentoo-functions should take over the symbolic
link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
My plan there is to work that into a script that prints a w
On Thu, 13 Mar 2014 07:59:55 +0800
Patrick Lauer wrote:
> On 03/13/2014 12:52 AM, William Hubbs wrote:
>
> Why deprecate it?
>
> I'm getting really irritated with the current trend of randomly
> renaming and movearounding things. All it does is confuse people,
> break existing setups and make d
On 03/13/2014 12:52 AM, William Hubbs wrote:
>>> No, I don't think gentoo-functions should take over the symbolic
>>> link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
>>> My plan there is to work that into a script that prints a warning
>>> message. It will stay that way until ope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/03/14 03:59 PM, William Hubbs wrote:
> All,
>
> thinking about this further,
>
> There may not be a need to remove /etc/init.d/functions.sh as long
> as it is understood that this is part of OpenRc, not the gentoo
> base.
>
> In other words,
201 - 300 of 1451 matches
Mail list logo
