maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Gudian <andreas.gud...@gmail.com>
Subject Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
Date Thu, 25 Jul 2013 17:55:11 GMT
I also find it quite odd an almost offensive to the open source community
in general to state that a PMC member shall not be allowed to fork too much
around. It's not a marriage, you know ;-).

I tend to agree with Jason: the PMC needs people who *do* stuff, meaning:
* bring the project foward (with discussions like this one, or the
JDK5/JDK6 threads).
* keep a close eye on commits.
* keep a very close eye on release votes.
* continue to assure that we don't do anything that the ASFdoesn't allow,
while making sure that we don't burden ourselfs with bulky processes to
achieve that.

It's a tough responsibility and it requires some dedication to the project.

I explicitly do not think that it's the responsibility of the PMC to make
sure that the maven project will never die out. That I'd find a bit
unnatural and against any best-of-breed principles, which worked out quite
well for open source software (and especially their users) in the past.

Cheers,
Andreas


2013/7/25 Sankaran, Nambi <nsankaran@ebay.com>

> +1
>
> The candidates should be people who contribute in terms of code/patch.
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@tesla.io]
> Sent: Thursday, July 25, 2013 9:56 AM
> To: Maven Users List
> Subject: Re: [DISCUSS] Should the Maven PMC be an example of how we want
> the Maven Community to behave (was Re: svn commit: r1506778 -
> /maven/site/trunk/content/markdown/project-roles.md)
>
>
> On Jul 25, 2013, at 12:03 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > As part of trying to kick this project back to life, we need to grow
> > both committers and the PMC.
> >
>
> You don't need either. You need people who do work. People who do work may
> happen to be a committer or PMC member but you have it backward. You need a
> lot of people who do a lot of work to drive a project forward.
>
> > One of the issues with growing either is determining if potential
> > candidates are the "right sort of person".
> >
>
> People who do work. I'm not sure how you decide the "right sort of person"
> if it's not based in the actual contributions to the project. Not what
> might be contributed, but what has actually been contributed.
>
> > There is a disagreement in the PMC as to whether "dedication to the
> > Maven project community" is relevant to such discussions.
> >
>
> Are not people who do work dedicated? Are not people who have done the
> most work the most dedicated? To me doing work is the whole basis of a
> meritocracy, doing work is table stakes for being on the PMC and is first
> condition at least in a meritocracy.
>
> > For growing committers, this is usually a small issue, if at all.
> >
> > For growing the PMC it can be quite contentious, especially when
> > considering "controversial" candidates.
> >
>
> Discussions should be about the work that is being done on the project.
> Everything outside of that is not within the purview of the discussion. How
> can it be? It's generally looking at the contributions over the last 6
> months or a year and making a decision based on the merit of that work.
>
> > In an effort to try and harmonise the PMC, I - as one of the fence
> > sitters
> > - started this debate... In essence calling on that group that trumps
> > the PMC... ie the community.
> >
> > John posted the proposed - remember we are CTR not RTC - addition to
> > the page I started, at least as a stalking horse (or perhaps it is his
> > opinion... I will leave it up to him to state his position)
> >
> > On Thursday, 25 July 2013, Jason van Zyl wrote:
> >
> >> So what's outlined in those paragraphs have counter examples at the
> >> ASF. I do not believe it is a bad thing to have alternative
> >> distributions or forks, and it doesn't matter where they are. What
> >> you are saying is that committers are obliged to share all their work
> >> with other committers. Which is more coercion than a matter of
> >> choice. For all work that happens within the bounds of the ASF
> >> absolutely. Core changes should not be made projects without
> >> discussion. That's a good rule and helps with stability. For work
> >> that happens outside the bounds of the ASF an author is obliged to do
> >> nothing of the sort and the assert as much is absurd quite honestly.
> What right does the ASF have over work that is not done at Apache?
> >>
> >> In fact there are people on the ASF Board who belong to companies
> >> that have long standing forks and/or alternative distributions of ASF
> projects.
> >> Look at Hadoop: there are two companies that have people on PMCs who
> >> maintain alternative distributions with code that does not exist in
> >> standard distributions. Both Cloudera and HortonWorks maintain
> >> versions of Hadoop that are not compatible and/or have different code
> >> than the version from Apache. There is selective patching and
> >> additions made to try and provide a better distribution of Hadoop. I
> don't think this is a bad thing.
> >> This also happens with Cassandra and the people who work at Datastax
> >> where an alternative distribution is made. I don't know as much about
> >> what is in those distributions insofar as code that doesn't exist in
> >> the standard Apache distribution. Again, I don't think this is a bad
> >> thing. I'm sure they would all tell you that they are trying to make
> >> a better version of said project, they work with customers, work at a
> >> different pace and hope to integrate their work back in later if
> possible.
> >>
> >> If this is a sideways attempt to address what I'm doing in Tesla,
> >> which is what it appears like to me, then just start a discussion on
> the dev list.
> >> Happy to discuss it.
> >
> >
> > It would be great if you could have that discussion on the dev list
> > any way... But what prompted me to prod John to commit the text and me
> > to start this discussion is a long running debate on the PMC private
> > list as to what kind of person should be on the PMC... By long running
> > I mean that some aspects of this are more than a year old and have
> > been in mails since before you started to re-engage with the project.
> >
> > That does not mean that the stuff you are doing at Tesla is not
> > relevant or a trigger for trying to sort out the disconnect between
> > two camps in the PMC... More that it is being considered in a common
> > context of an ongoing debate, and in an effort to resolve the debate
> > we are asking those we are supposed to serve for their input.
> >
> > HTH
> >
> >
> >>
> >> But if someone posits that all work related to an Apache project has
> >> to be done at Apache, then I will say that is a ridiculous
> >> supposition and you can find ten counter examples in ten minutes if you
> went looking.
> >>
> >> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >>> On Thursday, 25 July 2013, Curtis Rueden wrote:
> >>>
> >>>> Hi Stephen and everyone,
> >>>>
> >>>> I largely agree with Nigel, and would add that in general,
> >>>> bureaucratic rules prohibiting various (often technically and/or
> >>>> socially sound)
> >> actions
> >>>> such as forking are a great way to ensure that skilled people
> >>>> distance themselves from the organization (i.e., quit the PMC,
> >>>> decline to join, etc.). You will be left with only bureaucrats who
> >>>> can tolerate those restrictions, and worse, create even more of them.
> >>>>
> >>>> Of course, there should be good, publicly stated reasons for
> >> long-running
> >>>> forks.
> >>>
> >>>
> >>> I will not speak for the author of the proposed revision, but my
> >>> understanding of the intent is that these forks should be hosted on
> >>> ASF hardware in public and as part of our community.
> >>>
> >>> It's not about no forking, but allowing the committers to have an
> >>> ongoing view of things in the community.
> >>>
> >>> Any committer is free to edit the wording if they want right now...
> >>> The
> >> doc
> >>> is a work in progress proposal
> >>>
> >>>
> >>>> Merging to mainline is ideal but not always practical in the real
> >>>> world. Developers need the freedom to experiment, even (perhaps
> >> especially)
> >>>> when in active community positions such as the PMC.
> >>>>
> >>>> That said, it is certainly the responsibility of those on the PMC
> >>>> to
> >> act as
> >>>> community leaders via best practices. But enforcing that in
> >>>> writing, at least as the current proposal does, seems very
> counterproductive to me.
> >>>>
> >>>> Regards,
> >>>> Curtis
> >>>> On Jul 25, 2013 8:59 AM, "Nigel Magnay" <nigel.magnay@gmail.com>
> wrote:
> >>>>
> >>>>> That whole section I find pretty bizarre.
> >>>>>
> >>>>> - Apache is about (open-source) software.
> >>>>> - Writing code is *good*.
> >>>>> - Forks are *good*
> >>>>> *
> >>>>> *
> >>>>> I'm put in mind of Linus' talk about why git distribution is so
> >>>> important -
> >>>>> that 'if you don't think I'm doing a good job, then you can just
> >>>>> take
> >>>> your
> >>>>> code from another maintainer. *That's* what keeps a project honest
> >>>>> and responsive to the users.
> >>>>>
> >>>>> I would have thought that the kinds of people who are interested
> >>>>> in
> >>>> writing
> >>>>> maven-esque code would be some of the people you'd want on a PMC.
> >>>>> If
> >> they
> >>>>> have a "long running fork" or a "reimplementation", surely they
> >>>>> would
> >> be
> >>>>> lobbying for its integration? Merging is also good. If, despite
> >>>>> this, they're choosing to do this elsewhere, and/or are having
> >>>>> trouble
> >> merging
> >>>>> projects in, isn't that a pretty sad indictment for the health of
> >>>>> the project? Isn't it a bit like saying "boo-hoo, those that are
> >>>>> doing the actual work might go work in their own sandpit if we
> >>>>> won't play ball,
> >>>> let's
> >>>>> ex-communicate them" ?
> >>>>>
> >>>>> Unless (as some have suspected for a while) Apache isn't about
> >>>>> software anymore, it's about the continued existence of Apache (cfex:
> >>>> OpenOffice).-
> >>>>> a political edifice where projects go to die. That's certainly
> >>>>> what
> >> those
> >>>>> added paragraphs say to me.
> >>>>>
> >>>>>
> >>>>> On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly <
> >>>>> stephen.alan.connolly@gmail.com> wrote:
> >>>>>
> >>>>>> There are two schools of thought amongst the current members
of
> >>>>>> this projects PMC.
> >>>>>>
> >>>>>> Without wanting to deliberately tip my hand and reveal where
my
> >> opinion
> >>>>> is,
> >>>>>> we would like to solicit the opinions if the community that
we
> serve.
> >>>>>>
> >>>>>> Please give us your thoughts.
> >>>>>>
> >>>>>> The topic is essentially:
> >>>>>>
> >>>>>> Do you want the members of the Maven PMC to be social leaders
of
> >>>>>> the
> >>>>> Maven
> >>>>>> community, who's actions demonstrate the best community beThanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> The modern conservative is engaged in one of man's oldest exercises
> >> in moral philosophy; that is, the search for a superior moral
> >> justification for selfishness.
> >>
> >> -- John Kenneth Galbraith
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Sent from my phone
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message