On Mon, Nov 23, 2015 at 08:32:30AM +, Arnt Gulbrandsen wrote:
> (I said my commits contained cosmetics. They did in principle; I wrote a
> whitespace-fixing emacslisp hook while at Trolltech, and ran on the entire
> file before every commit from then on.
> Whitespace is a chore and chores ar
Oswald Buddenhagen writes:
On Sun, Nov 22, 2015 at 08:03:34PM +, Arnt Gulbrandsen wrote:
Oswald Buddenhagen writes: ...
i associate that term means opposition to change - and that obviously
makes no sense for historical states.
also, i find this kind of "opensource" bashing rather ridiculou
On Sun, Nov 22, 2015 at 08:03:34PM +, Arnt Gulbrandsen wrote:
> Oswald Buddenhagen writes:
> > On Sun, Nov 22, 2015 at 03:20:52PM +, Arnt Gulbrandsen wrote:
> >> Oh really? I think I broke that rule about 365 times per year during the
> >> years I spent at Trolltech.
> >
> > yes, i know ho
On Sun, Nov 22, 2015 at 03:09:39PM -0600 I heard the voice of
David Champion, and lo! it spake thus:
>
> +1 to both. Commenting the code and reformatting the code are
> separate tasks, and should be committed separately. Comments are
> reviewable, and I can support that without argument. Reform
* On 22 Nov 2015, Kevin J. McCarthy wrote:
>
> As the experienced committers have gotten busy, Mutt has had a problem
> the past few years accepting patches. However, since becoming a
> committer I have personally tried my damnedest to review and accept
> patches, and to give attribution to cont
Oswald Buddenhagen writes:
On Sun, Nov 22, 2015 at 03:20:52PM +, Arnt Gulbrandsen wrote:
Oh really? I think I broke that rule about 365 times per year during the
years I spent at Trolltech.
yes, i know how the code looked like before standards were established.
that's not something to be p
On Sun, Nov 22, 2015 at 02:18:55PM +, Richard Russon wrote:
> Kevin J. McCarthy wrote:
> > given the small size of the active development team.
>
> And it's likely to stay that way if the community doesn't encourage new
> people.
A good route to becoming a contributor is to start small: tackl
On Sun, Nov 22, 2015 at 03:20:52PM +, Arnt Gulbrandsen wrote:
> Oswald Buddenhagen writes:
> > in qt, the rule is to fix the style of only exactly the lines that are
> > being touched anyway. but this works only if the codebase is in a
> > reasonable shape in the first place.
>
> Oh really? I
Richard Russon writes:
I'm not surprised my ideas attracted a host of 'no' emails, but I was
hoping someone would suggest a way forward.
Write a script that runs astyle, other tools, custom-written scripts, or
any combination, and provide examples of its changes to the list. You'll
attract mo
Oswald Buddenhagen writes:
in qt, the rule is to fix the style of only exactly the lines that are
being touched anyway. but this works only if the codebase is in a
reasonable shape in the first place.
Oh really? I think I broke that rule about 365 times per year during the
years I spent at Tro
Kevin J. McCarthy wrote:
> given the small size of the active development team.
And it's likely to stay that way if the community doesn't encourage new
people.
I'm not surprised my ideas attracted a host of 'no' emails, but I was
hoping someone would suggest a way forward.
> reviewing large-scal
On Sun, Nov 22, 2015 at 01:45:43PM +0100, Martin Mares wrote:
> > there won't ever be a right time. either you accept that legible code is
> > worth it, or you don't.
>
> This smells of false dichotomy :) Legible code has its advantages and
> reformatting large chunks of code has its cost. You jus
Hello, world!\n
> there won't ever be a right time. either you accept that legible code is
> worth it, or you don't.
This smells of false dichotomy :) Legible code has its advantages and
reformatting large chunks of code has its cost. You just need to find the
right balance for a given project.
On Sat, Nov 21, 2015 at 02:42:32PM -0800, Kevin J. McCarthy wrote:
> You raise another good point: reviewing large-scale changes (even,
> or especially, unnecessary cosmetic ones) is an additional burden we
> can probably do without right now, given the small size of the active
> development team.
On Sat, Nov 21, 2015 at 11:34:07AM +, Andras Salamon wrote:
> On Sat, Nov 21, 2015 at 01:24:51AM +, Richard Russon wrote:
> >tl;dr -- I want to to extensively tidy the mutt code
>
> I'm disinclined to want to audit the result of wholesale changes to
> the code for cosmetic reasons, and I a
On Sat, Nov 21, 2015 at 02:59:09PM +, Richard Russon wrote:
> Mutt won't accept the changes and the patches won't go away.
Is this true? I've been lurking here a while and don't recall seeing many cases
of distros submitting patchsets for review, let alone them being rejected. I
just took e qu
On 21-11-2015 14:59:09 +, Richard Russon wrote:
> Mutt won't accept the changes and the patches won't go away.
>
> Downstream patches:
> Gentoo 59
Unrelated, but just for reduction of the severity, Gentoo applies
depending on what the user wants, ~22 patches.[1]
> Debian 42
> Fed
On Sat, Nov 21, 2015 at 11:34:07AM +, Andras Salamon wrote:
> On Sat, Nov 21, 2015 at 01:24:51AM +, Richard Russon wrote:
> >tl;dr -- I want to to extensively tidy the mutt code
> Moreover, consistency with a particular set of compiler standards will
> almost certainly ensure that some sys
On Sat, Nov 21, 2015 at 01:24:51AM +, Richard Russon wrote:
tl;dr -- I want to to extensively tidy the mutt code
I'm disinclined to want to audit the result of wholesale changes to
the code for cosmetic reasons, and I am also disinclined to use a
codebase I cannot audit effectively. Moreov
tl;dr -- I want to to extensively tidy the mutt code
Mutt's great, but it's the work of hundreds of people over a couple of
decades and that *really* shows in the code.
The code desperately needs cleaning up and I'm keen to make those changes.
Tidy, well documented code, will:
make maintenan
20 matches
Mail list logo
