maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Date Mon, 05 Aug 2013 10:55:16 GMT
Brian,

Did you have any suggested changes to the forks section wording to clear up
my intent for that section?

I'd like to start wrapping this up and move towards making it "official"

Everyone else,

Time to shout out if you have any issues / suggested improvements on the
content

- Stephen

On Friday, 2 August 2013, Stephen Connolly wrote:

> On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu <javascript:_e({},
> 'cvml', 'brianf@infinity.nu');>> wrote:
>
>> I think the bulk of this is pretty good. On the fork section,
>> specifically:
>>
>> "
>> As soon as changes in that
>> fork are identified which should be brought back to the project those
>> changes should be introduced into at least a branch hosted on the Apache
>> Maven
>> source control in order to facilitate the easier review by the community.
>>
>> The PMC should encourage by example the early committing of changes from a
>> fork back to Apache Maven source control.
>> "
>>
>> This seems to want to compel code to be brought back as a
>> responsibility, I don't think we need to spell that out.
>
>
> This is why I say "as soon as ... are identified"
>
> The wording could be clearer... if somebody can figure out a better way to
> say it.
>
> Basically, as soon as you say something like... "Oh commit 1a2b3d4e, we
> really need to get that into Maven itself, it's too good to be in our
> fork"... you should be trying to hasten getting that commit into Maven
> itself.... and if you are on the PMC and one of your commits is one that
> you say this of... you should just commit it back.
>
> Until you realise that a commit is one that you want to push to Maven, hey
> it's your work... whatever... but as soon as you identify the change as
> being one that should be at Maven, as a PMC member you are expected to try
> and get it into Maven quickly so that others working on the fork see that
> this is the example by which the PMC leads.
>
> If you can think of a clearer way to express that than my wording (which
> since you are not getting my intended meaning must therefore be lacking)
> please update.
>
> The section
>> about the downsides to not doing so and attempting to do it later is
>> really the core of the concerns... the extra diligence required to
>> consume large bodies of work is bigger. That doesn't mean that code
>> contributions are inherently bad just because they were developed
>> elsewhere, it's just harder to pull in.
>>
>
> Correct.
>
>
>
> On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
> <stephen.alan.connolly@gmail.com> wrote:
> > I have updated the project-roles with my thoughts resulting from the
> > healthy debate on the list and some debates elsewhere.
> >
> > If anyone wants to look at the resulting Work In Progress document as a
> > whole:
> >
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup
> >
> > Thoughts?
> >
> > -Stephen
> >
> > ---------- Forwarded message ----------
> > From: <stephenc@apache.org>
> > Date: 2 August 2013 10:52
> > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
> > project-roles.md
> > To: commits@maven.apache.org
> >
> >
> > Author: stephenc
> > Date: Fri Aug  2 09:52:11 2013
> > New Revision: 1509594
> >
> > URL: http://svn.apache.org/r1509594
> > Log:
> > After a lengthy discussion on the users@maven list and some
> > side discussions on members@apache, I think the following changes
> > are more in line with what we should be seeking as responsibilities
> > of the PMC.
> >
> > * Forks are not bad... letting changes stack up in the fork is bad
> >   but more from a 'it will be hard to review' point of view...
> >   similarly using a fork to get external contributions complicates
> >   the tracablity
> >
> > * We are not obligated to promote other ASF projects... but there
> >   should be a symmetry in how that lack of obligation plays out
> >
> > * I identified some
>
>
>

-- 
Sent from my phone

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