Some small formating or typos.
Added commas in a long sentence around line 280 and another one around
l298. I generally find it hard to concentrate on a whole sentence without
commas (or even periods separating ideas).
See https://gist.github.com/Batmat/6155302 for proposed patch.
If you need any other attachment format, just let me know.
Cheers
2013/8/5 Stephen Connolly <stephen.alan.conno...@gmail.com>
> 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 <bri...@infinity.nu <javascript:_e({},
> > 'cvml', 'bri...@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.conno...@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: <steph...@apache.org>
> > > Date: 2 August 2013 10:52
> > > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
> > > project-roles.md
> > > To: comm...@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
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
