Hi there,
> no, actually, i was referring to the first part of my first sentence in
> that paragraph. of course there is a time perspective to it, but that's
> not the point.
Oh, I see now. The survey is not essential - the proposals themselves
are needed (e.g. with proper arguments based on some
On Mon, Nov 11, 2013 at 03:18:21PM +0100, jpac...@redhat.com wrote:
> Hi Oswald,
> > and who makes *that* call? where do you draw the line? it doesn't appear
> > magically, somebody with the competence and guts (=> authority) has to
> > do it.
>
> If you're bold enough (devs/committers are :)), yo
Hi Oswald,
> and who makes *that* call? where do you draw the line? it doesn't appear
> magically, somebody with the competence and guts (=> authority) has to
> do it.
If you're bold enough (devs/committers are :)), you'll do it.
> ... but the simple fact is that there is nobody here
> who wants
On Thu, Nov 07, 2013 at 11:20:36AM +0100, jpac...@redhat.com wrote:
> > from my experience, people without maintainership ambitions simply adapt
> > to lower standards.
>
> Such people are fast to discover => you can ban them (it may/should have
> also a social face, not only sudden change of comm
Hi Oswald,
> from my experience, people without maintainership ambitions simply adapt
> to lower standards.
Such people are fast to discover => you can ban them (it may/should have
also a social face, not only sudden change of commit rights or alike) at
the very beginning => solved :).
> they co
Hi Gary,
you must be right. The only concern is about the very final slow-down of
patch adoption. In case of mutt, this slow-down was/is (?) really
counterproductive.
Kind regards
-- Jan Pacner
On Mon, Nov 04, 2013 at 11:22:51AM +0100, jpac...@redhat.com wrote:
> > try more context. hint: it's a response to what *you* wrote.
>
> Well, it seems we both have no idea if some of mutt devs are paid or
> not, so let's move to the next point :).
>
actually, i'm pretty confident that none are.
On 2013-11-04, jpacner wrote:
> Hi Holger,
>
> you're entirely right with my misuse of 'high-quality'. I should have
> quoted it. The submitter himself would be responsible for the quality.
> The point of this suggestion is that patches would be incorporated
> faster, but on the other hand they co
Hi Holger,
> try more context. hint: it's a response to what *you* wrote.
Well, it seems we both have no idea if some of mutt devs are paid or
not, so let's move to the next point :).
> obviously.
> i'll point out that we were talking about the motivation to polish
> patches.
> so how exactly ca
Hi Holger,
you're entirely right with my misuse of 'high-quality'. I should have
quoted it. The submitter himself would be responsible for the quality.
The point of this suggestion is that patches would be incorporated
faster, but on the other hand they could be much faster abandoned
(because the
* jpac...@redhat.com [2013-10-31 13:20]:
> > But the solution is not to give everyone commit access.
>
> Don't get me wrong, but a high-quality patch in conjunction with
> constructive track ticket seems enough for accepting the person as a
> commiter into (and only into) the quick-moving partly
Hi Holger,
> But the solution is not to give everyone
> commit access.
Don't get me wrong, but a high-quality patch in conjunction with
constructive track ticket seems enough for accepting the person as a
commiter into (and only into) the quick-moving partly stable branch.
It's imho quite far fro
Hi Holger,
> You suggest the project could be moved forward without
> maintainership, while I believe that strong maintainership is the only
> realistic option.
More accurately, I suggest the project could be moved forward by
_adding_ another tier, which would fill in the hole called "missing
pos
On Thu, Oct 24, 2013 at 10:33:22AM +0200, jpac...@redhat.com wrote:
> >> In one of your emails you mentioned, there are most probably some paid
> >> developers. Now you're writing "would need" as if there were none of
> >> them right now. I'm not sure what is actually your point.
> >>
> > i made no
On Thu, Oct 24, 2013 at 08:50:51PM +0200, Holger Weiß wrote:
> * Derek Martin [2013-10-24 10:46]:
> > This hasn't been true for Mutt, at least historically. Some of the
> > people who submit patches infrequently have taken the time to review
> > other patches (myself included)...
>
> However, th
* Derek Martin [2013-10-24 10:46]:
> On Thu, Oct 24, 2013 at 02:05:07PM +0200, Holger Weiß wrote:
> > > Of course, but they build only a minority and therefore if the others
> > > don't like their work, why not to revert the commit or rewrite the patch
> > > with prompting the original author that
On Thu, Oct 24, 2013 at 01:11:29PM +0200, Ondřej Bílka wrote:
> On Thu, Oct 24, 2013 at 10:53:33AM +0200, Fredrik Gustafsson wrote:
> > On Thu, Oct 24, 2013 at 10:45:05AM +0200, jpac...@redhat.com wrote:
> > > > And beyond that I think there needs to be a automated C-style checker to
> > > > enforc
On Thu, Oct 24, 2013 at 02:05:07PM +0200, Holger Weiß wrote:
> > Of course, but they build only a minority and therefore if the others
> > don't like their work, why not to revert the commit or rewrite the patch
> > with prompting the original author that the patch was really bad?
>
> This sounds
* jpac...@redhat.com [2013-10-24 15:02]:
> Anyway, you sound like a usual mutt user, who prefers stability over
> new-features (this is the trade-off you've mentioned) and therefore you
> can stay calm - you'll get the same quality of stable releases like up
> until now (no changes in the stable r
Hi Holger,
> This sounds so awesome! No need for maintainers. The community will
> just magically take over all their work.
>
> Of course, in practice, it doesn't work this way. Occasional
> contributors add their favourite feature or fix a bug they stumbled
> over. That's it. They provide p
* [2013-10-24 10:33]:
> > i've been maintainer of sufficiently many projects to know that this
> > is not a universally true statement. a significant percentage of casual
> > contributors throws some crappy code at you and expects you to be
> > grateful for it, possibly flaming you down when you m
On Thu, Oct 24, 2013 at 10:53:33AM +0200, Fredrik Gustafsson wrote:
> On Thu, Oct 24, 2013 at 10:45:05AM +0200, jpac...@redhat.com wrote:
> > > And beyond that I think there needs to be a automated C-style checker to
> > > enforce consistent C code formatting. The checker could be run via a
> > >
On Thu, Oct 24, 2013 at 10:45:05AM +0200, jpac...@redhat.com wrote:
> > And beyond that I think there needs to be a automated C-style checker to
> > enforce consistent C code formatting. The checker could be run via a
> > gate push hook.
>
> Why not. Could someone with change repo rights accompli
Hi Fredrik,
> If you need an automated tool to enforce formatting rules, doesn't that
> apply that your code review process is broken and you risc to slip in
> serious bugs? Shouldn't formatting rules be part of the ordinary code
> review process?
It depends. IMHO it should be, but if the project
> While I'd like to see a more inclusive patch process (I have created
> several over the years that I'd like to see included in mutt) I think,
> as others have mentioned before, that a comprehensive regression test
> needs to be created and included in the mutt source tree with a make
> target to
> Mutt might not *any longer* be able to garner that kind of support.
> The number of people I know who use Mutt today has become A LOT
> smaller than the number of people I know who previously used Mutt.
> It's a small project which fills a particular niche that is becoming
> less and less interes
Hi Oswald,
>> In one of your emails you mentioned, there are most probably some paid
>> developers. Now you're writing "would need" as if there were none of
>> them right now. I'm not sure what is actually your point.
>>
> i made no such claim regarding mutt. you should re-read the relevant
> mail
On Thu, Oct 03, 2013 at 03:40:12PM +0200, jpac...@redhat.com wrote:
>
> Let me propose a fairly minor change in the development process. First,
> introduce a special branch in mercurial for a "user-developed" version
> of mutt. Commit rights for this branch would be given immediately
> (without an
On Thu, Oct 17, 2013 at 09:54:06PM +0200, Oswald Buddenhagen wrote:
> On Thu, Oct 17, 2013 at 10:29:49AM +0200, jpac...@redhat.com wrote:
> > On 10/07/2013 10:29 AM, Oswald Buddenhagen wrote:
> chasing behind a quick-moving branch with much lower quality standards is
> anything between deeply demot
hi,
On Fri, Oct 18, 2013 at 10:52:22AM +0200, jpac...@redhat.com wrote:
> > chasing behind a quick-moving branch with much lower quality
> > standards is anything between deeply demotivating and unrealistic -
> > that's why you would need paid people to accomplish that feat.
>
> In one of your em
Hi Oswald,
> yes, there is a huge difference for the *users*, because as it stands,
> they are in fact faced with a whole forrest of branches which they need
> to merge by themselves. from the perspective of the developers it is the
> same - an external source of random patches.
Exactly.
> chasi
On Thu, Oct 17, 2013 at 10:29:49AM +0200, jpac...@redhat.com wrote:
> On 10/07/2013 10:29 AM, Oswald Buddenhagen wrote:
> > mutt already has that anything-goes branch: it's called trac. when
> > you make an actual hg branch of it, it will be a fork, and master
> > will be abandoned for good.
>
> W
Hi Oswald,
On 10/07/2013 10:29 AM, Oswald Buddenhagen wrote:
> the difference is that these branches are maintained by the same people,
> or at least that those maintaining the stable branch are *paid* to
> actively cherry-pick from the unstable branch.
> you proposed an open-for-all branch with v
On Mon, Oct 07, 2013 at 08:59:32AM +0200, jpac...@redhat.com wrote:
> >> Let me propose a fairly minor change in the development process.
> >>
> > you are proposing a fork on mutt's own infrastructure.
>
> Not at all. Look at many other projects. Even huge projects like Fedora
> ("not guaranteed t
Hi,
>> Let me propose a fairly minor change in the development process.
>>
> you are proposing a fork on mutt's own infrastructure.
Not at all. Look at many other projects. Even huge projects like Fedora
("not guaranteed to work in a production environment") and RHEL
("everything bundled is guara
On Thu, Oct 03, 2013 at 03:40:12PM +0200, jpac...@redhat.com wrote:
> Let me propose a fairly minor change in the development process.
>
you are proposing a fork on mutt's own infrastructure. i'm not quite
sure whether you are incredibly naive or incredibly sneaky. ;)
nope, what it takes to make a
Well,
if you don't mind, I would try to make a small intermediate aggregation
of the current topics discussed regarding the purpose of this discussion
(which is solving the declining vitality of the mutt project).
Except for many examples of technical stuff, patches and situations
where the proje
37 matches
Mail list logo
