deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS] Workflow for contributions
Date Tue, 17 Jan 2012 09:05:43 GMT
hi @ all,

as we have seen the suggestion of christian works pretty well and at least
for contributions via patches, we should use it imo (it's better than the
typical "thx to [name of contributor]" in the commit message).

@christian:
if there are no objections, it would be nice if you add it to [1].

@new features which consist of multiple commits:
(there needs to be at least a jira ticket and we have to review it in any
case - just trusting an external contributor without reviewing the
contribution won't work at all imo.)
since we suggest to work with >local< branches, we could think about
suggesting branches for new features as well.
e.g.: create branch -> commits -> push it to a public repository -> add the
link to the jira ticket.
-> a committer performs a pull >rebase< on the remote branch as soon as we
agreed on it -> we still have a clean commit history.

regards,
gerhard

[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows




2012/1/15 Marius Bogoevici <marius.bogoevici@gmail.com>

>
> On 2012-01-15, at 11:25 AM, Mark Struberg wrote:
>
> > basically that would be fine.
> >
> > But note that any user on github _might_ be faked. It's simple for
> everyone to e.g. create a commit with "Marius Bogoevici <
> marius.bogoevici@gmail.com>" as committer info ;)
>
> >
> > So please only pull from locations you know and have verified in the
> past - otherwise let the contributor creat a Jira issue and he should
> attach the patch + pull request there.
>
> Sure, but I thought that we were already discussing this in the context of
> two sources which authorize submitters beforehand, viz.: JIRA+patch and
> github. Ultimately, in both cases the submitter must be trusted.
>
> >
> > LieGrue,
> > strub
> >
> >
> > ----- Original Message -----
> >> From: Marius Bogoevici <marius.bogoevici@gmail.com>
> >> To: deltaspike-dev@incubator.apache.org
> >> Cc:
> >> Sent: Saturday, January 14, 2012 8:16 PM
> >> Subject: Re: [DISCUSS] Workflow for contributions
> >>
> >>
> >> On 2012-01-14, at 12:39 PM, Lincoln Baxter, III wrote:
> >>
> >>> Is it not still possible to use Pull requests, but simply merge them
> >>> manually against the proper repository? Github would see the changes
> in the
> >>> repository and automatically close the pull request once the merge has
> been
> >>> completed (and synced with Github.) Additionally, pull requests that
> were
> >>> only partially merged or accepted can still be closed manually.
> >>
> >> That should work pretty well too, especially if multi-commit pull
> requests are
> >> discouraged or even
> >> banned (and I personally think that they should, as they are can be a
> PITA to
> >> review).
> >>
> >>
> >>>
> >>> Would that be too confusing?
> >>> ~Lincoln
> >>>
> >>> On Sat, Jan 14, 2012 at 12:05 PM, Marius Bogoevici <
> >>> marius.bogoevici@gmail.com> wrote:
> >>>
> >>>>
> >>>> On 2012-01-14, at 11:55 AM, Matt Benson wrote:
> >>>>
> >>>>> On Sat, Jan 14, 2012 at 9:47 AM, Marius Bogoevici
> >>>>> <marius.bogoevici@gmail.com> wrote:
> >>>>>>
> >>>>>> On 2012-01-14, at 10:14 AM, Christian Kaltepoth wrote:
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> I think we should talk about how contributions and patch
> >> submissions
> >>>> could
> >>>>>>> work in the future.
> >>>>>>>
> >>>>>>> Everybody familiar with GitHub knows pull requests which
> >> offer a great
> >>>> way
> >>>>>>> to submit patches to a project. But as the ASF repository
> >> doesn't offer
> >>>>>>> such a feature we should think about how we could handle
> >> contributions
> >>>>>>> while getting as much out of git as possible.
> >>>>>>>
> >>>>>>> One way to handle this is to use "git
> >> format-patch" which is able to
> >>>>>>> package a series of commits into one file (see [1] for an
> >> examle).
> >>>> Using
> >>>>>>> format-patch has some nice advantages over standard patch
> >> files. The
> >>>> major
> >>>>>>> advantage is that individual commits including their commit
> >> messages
> >>>> and
> >>>>>>> author are preserved.
> >>>>>>>
> >>>>>>> Creating such patches is very easy. Just create a local
> >> branch, do the
> >>>>>>> commits there and then create the patch this way:
> >>>>>>>
> >>>>>>> $ git format-patch --stdout master >
> >> ../DELTASPIKE-XXX.patch
> >>>>>>>
> >>>>>>> Applying such patches is also straight forward:
> >>>>>>>
> >>>>>>> $ git am < ../DELTASPIKE-XXX.patch
> >>>>>>>
> >>>>>>> The most important question we have to answer is if we
> >> should accept
> >>>> such
> >>>>>>> "git format-patch" patches in the future or if we
> >> stick with the
> >>>> classic
> >>>>>>> "diff" patches.
> >>>>>>>
> >>>>>>> The only reason against the "git format-patch"
> >> contributions I could
> >>>> think
> >>>>>>> of would be that the name of the original patch author (who
> >> is
> >>>> presumably
> >>>>>>> not ASF member) appears in the commit. But IMHO this
> >> shouldn't be a
> >>>> real
> >>>>>>> problem because the name of the committer that applied the
> >> patch is
> >>>> also
> >>>>>>> added (see [2] for an example).
> >>>>>>
> >>>>>> I would argue that preserving a reference to the original
> >> contributor
> >>>> is very
> >>>>>> desirable. For one thing, giving credit where it's due is
> >> the fair
> >>>> thing to do - on the other hand,
> >>>>>> it is a good way of tracing the amount of individual
> >> contributions for
> >>>> non-committer contributors
> >>>>>> (e.g. before they become committers in their own right). Now,
> >> quantity
> >>>> is really just one of the
> >>>>>> metrics (the other one being quality, of course), but I'd
> >> say that it's
> >>>> still good to have this kind of
> >>>>>> stuff remembered somewhere.
> >>>>>>
> >>>>>
> >>>>> This won't necessarily be the case 100% of the time, but I
> >> would hope
> >>>>> that a given contribution would typically not be pulled into the
> >> main
> >>>>> repository without meeting or exceeding the DeltaSpike
> >> committer's
> >>>>> standard of minimum quality.  So in most cases, quantity of
> >>>>> contributions, along with other forms of community participation
> >>>>> (there have been committers and even PMC members elected to
> >> projects
> >>>>> with *no* actual code contributed), would remain a decent metric.
> >>>>>
> >>>>
> >>>> Yes, and other SCMs (SVN for instance) tend to blur this. So, I see
> >> using
> >>>> the way
> >>>> in which git format-patch works more like a desirable feature we shall
> >>>> use, rather than a
> >>>> hindrance we need to work around.
> >>>>
> >>>>> Matt
> >>>>>
> >>>>>>>
> >>>>>>> Any thoughts on this? I think we should create a wiki page
> >> for the
> >>>> process
> >>>>>>> however it will look like so that new contributors can get
> >> started
> >>>> quickly.
> >>>>>>>
> >>>>>>> Christian
> >>>>>>>
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>
> >>
> https://issues.apache.org/jira/secure/attachment/12510524/DELTASPIKE-49.patch
> >>>>>>> [2]
> >>>>>>>
> >>>>
> >>
> http://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=becf0ff57bfbf472fc7c1e07a0c68746aa00018b
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Christian Kaltepoth
> >>>>>>> Blog: http://chkal.blogspot.com/
> >>>>>>> Twitter: http://twitter.com/chkal
> >>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Lincoln Baxter, III
> >>> http://ocpsoft.com
> >>> http://scrumshark.com
> >>> "Keep it Simple"
> >>
>
>

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