RTC for overhead activities, and git branches versus releases

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

RTC for overhead activities, and git branches versus releases

Benson Margulies
Personally, I can't see value in RTC on housekeeping tasks such as
adding -incubator to the version # of the pom. And a person can't, at
the end of the day, RTC a release. However, if there's a general
feeling that you want to see a patch or a PR even for this, I'll of
course go along.

I also want to increase the precision of our plans for using branches
for releases.

On relatively informal projects that I'm on, the process (at least
just for the tiny maven plugin) would be to directly do the release on
develop. If there's a preference to start by making a pushed branch
for the release process, and then merge that branch to develop at the
end, I can do that.

In the later case, it seems important to adopt the gitflow convention
of using 'master' as the place where we merge the exact commit of each
release. I confess that my git-foo may be insufficient for this and if
someone else is willing to get the master branch to do the right thing
afterwards I'll be grateful.
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joey Echeverria
I'm +1 RTC for admin/overhead activities and -1 on RTC for release
process commits.

Basically, if anything is going into the main develop branch, I think
it should be reviewed. One of the major benefits of this is it puts
new contributors and committers on an equal footing when it comes to
*developing* patches. Committers of course have the ability to also
push patches that they've *reviewed*.

Release process commits are mostly coming from an automated tool (i.e.
the maven release plugin) so I don't see how we could review those
commits prior to going through the release process.

-Joey

On Thu, Jan 15, 2015 at 10:24 AM, Benson Margulies
<[hidden email]> wrote:

> Personally, I can't see value in RTC on housekeeping tasks such as
> adding -incubator to the version # of the pom. And a person can't, at
> the end of the day, RTC a release. However, if there's a general
> feeling that you want to see a patch or a PR even for this, I'll of
> course go along.
>
> I also want to increase the precision of our plans for using branches
> for releases.
>
> On relatively informal projects that I'm on, the process (at least
> just for the tiny maven plugin) would be to directly do the release on
> develop. If there's a preference to start by making a pushed branch
> for the release process, and then merge that branch to develop at the
> end, I can do that.
>
> In the later case, it seems important to adopt the gitflow convention
> of using 'master' as the place where we merge the exact commit of each
> release. I confess that my git-foo may be insufficient for this and if
> someone else is willing to get the master branch to do the right thing
> afterwards I'll be grateful.



--
Joey Echeverria
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joe Witt
In reply to this post by Benson Margulies
Benson,

For me personally, I share the view you indicate for applicability of RTC
for housekeeping items.  That was the intent of my previous RTC thread - to
test those sorts of things out.

Your comment about the branch for release and merging to master does bring
up an important curveball to our plans given that the nar maven plugin
within that same bundle.  I don't see how we'll do this without splitting
it into its own Git repo.  Perhaps we should just rip that bandaid off
now.  I can submit an infra request tonight if this is the right play.

Thanks
joe

On Thu, Jan 15, 2015 at 1:24 PM, Benson Margulies <[hidden email]>
wrote:

> Personally, I can't see value in RTC on housekeeping tasks such as
> adding -incubator to the version # of the pom. And a person can't, at
> the end of the day, RTC a release. However, if there's a general
> feeling that you want to see a patch or a PR even for this, I'll of
> course go along.
>
> I also want to increase the precision of our plans for using branches
> for releases.
>
> On relatively informal projects that I'm on, the process (at least
> just for the tiny maven plugin) would be to directly do the release on
> develop. If there's a preference to start by making a pushed branch
> for the release process, and then merge that branch to develop at the
> end, I can do that.
>
> In the later case, it seems important to adopt the gitflow convention
> of using 'master' as the place where we merge the exact commit of each
> release. I confess that my git-foo may be insufficient for this and if
> someone else is willing to get the master branch to do the right thing
> afterwards I'll be grateful.
>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joey Echeverria
The argument for doing "housekeeping" commits without a review is that
waiting for a review is a time burden. My counter to this is that
truly trivial patches require a trivial review which means the only
time burden is the time it takes to find someone to do the review. If
it takes a long time to find someone to do a review for a
"housekeeping" patch, then I'd view that as a community problem not a
process problem.

The one counter argument is that in dealing with a global community,
it can be hard for folks in some timezones to find available
reviewers. We've hit this before in Kite where due to timezones and
vacations, there were not committers available to do a review that was
blocking that release. In those cases, I asked third-party developers
that had good standing in the community to do the review for me even
though they weren't committers. Even better, they found a bug that I
had missed in my patch development process that would have required a
second patch anyway.

So in summary, I'm still a strong +1 on RTC for all patches. If you
want an explicit rule for "housekeeping" commits that they can be
developed by a committer and then reviewed by a contributor, then I'd
be in favor of that. However, we need to provide a very clear
definition of a "housekeeping" commit to avoid potential confusion.

-Joey

On Thu, Jan 15, 2015 at 11:02 AM, Joe Witt <[hidden email]> wrote:

> Benson,
>
> For me personally, I share the view you indicate for applicability of RTC
> for housekeeping items.  That was the intent of my previous RTC thread - to
> test those sorts of things out.
>
> Your comment about the branch for release and merging to master does bring
> up an important curveball to our plans given that the nar maven plugin
> within that same bundle.  I don't see how we'll do this without splitting
> it into its own Git repo.  Perhaps we should just rip that bandaid off
> now.  I can submit an infra request tonight if this is the right play.
>
> Thanks
> joe
>
> On Thu, Jan 15, 2015 at 1:24 PM, Benson Margulies <[hidden email]>
> wrote:
>
>> Personally, I can't see value in RTC on housekeeping tasks such as
>> adding -incubator to the version # of the pom. And a person can't, at
>> the end of the day, RTC a release. However, if there's a general
>> feeling that you want to see a patch or a PR even for this, I'll of
>> course go along.
>>
>> I also want to increase the precision of our plans for using branches
>> for releases.
>>
>> On relatively informal projects that I'm on, the process (at least
>> just for the tiny maven plugin) would be to directly do the release on
>> develop. If there's a preference to start by making a pushed branch
>> for the release process, and then merge that branch to develop at the
>> end, I can do that.
>>
>> In the later case, it seems important to adopt the gitflow convention
>> of using 'master' as the place where we merge the exact commit of each
>> release. I confess that my git-foo may be insufficient for this and if
>> someone else is willing to get the master branch to do the right thing
>> afterwards I'll be grateful.
>>



--
Joey Echeverria
Reply | Threaded
Open this post in threaded view
|

RE: RTC for overhead activities, and git branches versus releases

Mark Payne
I'm actually very likeminded with Joe & Benson here. I can understand Joey's argument, but at some point the process is much more expensive than the task itself. If you fix a typo, for instance, and you need to get a review, the typo fix was likely less than 3 seconds. Getting a review, even it involves saying to the person next to you "Hey, check this. And comment +1 on the ticket." will like take 3-4 minutes. If the "process" around getting something done takes long (especially an order of magnitude longer in this case) than the task itself, I think the process is a problem. And while waiting 3-4 minutes may not seem like a big deal, this sometimes happens many times in one day, and the simple distraction itself can be frustrating and can take away a great deal of time (Your Brain at Work by Dr. David Rock, as well as many other publications suppose "Another study, published in October 2005, found that employees spent an average of 11 minutes on a project before being distracted. After an interruption it takes them 25 minutes to return to the original task, if they do at all.")
So while I can understand Joey's point entirely I am very much +1 for skipping the RTC for housekeeping commits... though I agree that it's crucial that we define (early on) what is a "housekeeping" commit.
Thanks-Mark

> Date: Thu, 15 Jan 2015 11:25:44 -0800
> Subject: Re: RTC for overhead activities, and git branches versus releases
> From: [hidden email]
> To: [hidden email]
>
> The argument for doing "housekeeping" commits without a review is that
> waiting for a review is a time burden. My counter to this is that
> truly trivial patches require a trivial review which means the only
> time burden is the time it takes to find someone to do the review. If
> it takes a long time to find someone to do a review for a
> "housekeeping" patch, then I'd view that as a community problem not a
> process problem.
>
> The one counter argument is that in dealing with a global community,
> it can be hard for folks in some timezones to find available
> reviewers. We've hit this before in Kite where due to timezones and
> vacations, there were not committers available to do a review that was
> blocking that release. In those cases, I asked third-party developers
> that had good standing in the community to do the review for me even
> though they weren't committers. Even better, they found a bug that I
> had missed in my patch development process that would have required a
> second patch anyway.
>
> So in summary, I'm still a strong +1 on RTC for all patches. If you
> want an explicit rule for "housekeeping" commits that they can be
> developed by a committer and then reviewed by a contributor, then I'd
> be in favor of that. However, we need to provide a very clear
> definition of a "housekeeping" commit to avoid potential confusion.
>
> -Joey
>
> On Thu, Jan 15, 2015 at 11:02 AM, Joe Witt <[hidden email]> wrote:
> > Benson,
> >
> > For me personally, I share the view you indicate for applicability of RTC
> > for housekeeping items.  That was the intent of my previous RTC thread - to
> > test those sorts of things out.
> >
> > Your comment about the branch for release and merging to master does bring
> > up an important curveball to our plans given that the nar maven plugin
> > within that same bundle.  I don't see how we'll do this without splitting
> > it into its own Git repo.  Perhaps we should just rip that bandaid off
> > now.  I can submit an infra request tonight if this is the right play.
> >
> > Thanks
> > joe
> >
> > On Thu, Jan 15, 2015 at 1:24 PM, Benson Margulies <[hidden email]>
> > wrote:
> >
> >> Personally, I can't see value in RTC on housekeeping tasks such as
> >> adding -incubator to the version # of the pom. And a person can't, at
> >> the end of the day, RTC a release. However, if there's a general
> >> feeling that you want to see a patch or a PR even for this, I'll of
> >> course go along.
> >>
> >> I also want to increase the precision of our plans for using branches
> >> for releases.
> >>
> >> On relatively informal projects that I'm on, the process (at least
> >> just for the tiny maven plugin) would be to directly do the release on
> >> develop. If there's a preference to start by making a pushed branch
> >> for the release process, and then merge that branch to develop at the
> >> end, I can do that.
> >>
> >> In the later case, it seems important to adopt the gitflow convention
> >> of using 'master' as the place where we merge the exact commit of each
> >> release. I confess that my git-foo may be insufficient for this and if
> >> someone else is willing to get the master branch to do the right thing
> >> afterwards I'll be grateful.
> >>
>
>
>
> --
> Joey Echeverria
     
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Benson Margulies
I think I see a way to proceed that leaves people room to keep discussing.

Here's my proposed procedure:

git checkout -b nar-maven-plugin-0.0.1-release
mvn release:prepare
 # when it prompts, enter: 0.0.1-incubating
mvn release:perform
git checkout develop
git merge nar-maven-plugin-0.0.1-release
git push
git push --tags

git checkout master
git merge-with-some-fancy-commands-that-insist-that-the-result-is...
the-tag-for-the-release
git push

This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the
bother of another git repo. (c) seemingly end up with all the chickens
in the correct coops.

However, if other think that it would be less confusing to move the
plugin to a repo, by all means ask infra for the repo and we'll go
from there.
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joe Witt
Benson,

I too would like to march forward without having to bother infra for
another git repo.

What if we just move the directory structure a bit such that at the root
level of our git repo we have something like:

- nifi [directory]
- maven-plugins [directory]
- README
- NOTICE
- DISCLAIMER
- LICENSE
- KEYS

nifi then will contain all the stuff we have in Git today minus the
nar-maven-plugin subfolder.

maven-plugins will contain a single subdirectory right now which would be
the 'nar-maven-plugin' but we'd soon add some archetypes there too.

So then we release the project and artifacts of 'maven-plugins' and then
once all good we release 'nifi'.

We can tag these releases and merge them to master.  Since they'd be
'parallel' to eachother in hierarchy I'm thinking there'd be no problem.

Is this reasonable?  If not then I'm inclined to put in an infra request
tonight.

Thanks
Joe

On Thu, Jan 15, 2015 at 4:34 PM, Benson Margulies <[hidden email]>
wrote:

> I think I see a way to proceed that leaves people room to keep discussing.
>
> Here's my proposed procedure:
>
> git checkout -b nar-maven-plugin-0.0.1-release
> mvn release:prepare
>  # when it prompts, enter: 0.0.1-incubating
> mvn release:perform
> git checkout develop
> git merge nar-maven-plugin-0.0.1-release
> git push
> git push --tags
>
> git checkout master
> git merge-with-some-fancy-commands-that-insist-that-the-result-is...
> the-tag-for-the-release
> git push
>
> This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the
> bother of another git repo. (c) seemingly end up with all the chickens
> in the correct coops.
>
> However, if other think that it would be less confusing to move the
> plugin to a repo, by all means ask infra for the repo and we'll go
> from there.
>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Benson Margulies
The structure you propose would be less confusing that what we have.
Since I'm still too dense to follow what you wrote would go wrong if
we released from the current structure, I don't see any problem with
the new structure, either :-)  I probably need to reread your email.
But don't wait on me -- if no one else dislikes your proposal, do it.
On the RTC/CTR front, I really think that a discussion here of
something like this _is_ an 'R', but that's just me.


On Thu, Jan 15, 2015 at 4:44 PM, Joe Witt <[hidden email]> wrote:

> Benson,
>
> I too would like to march forward without having to bother infra for
> another git repo.
>
> What if we just move the directory structure a bit such that at the root
> level of our git repo we have something like:
>
> - nifi [directory]
> - maven-plugins [directory]
> - README
> - NOTICE
> - DISCLAIMER
> - LICENSE
> - KEYS
>
> nifi then will contain all the stuff we have in Git today minus the
> nar-maven-plugin subfolder.
>
> maven-plugins will contain a single subdirectory right now which would be
> the 'nar-maven-plugin' but we'd soon add some archetypes there too.
>
> So then we release the project and artifacts of 'maven-plugins' and then
> once all good we release 'nifi'.
>
> We can tag these releases and merge them to master.  Since they'd be
> 'parallel' to eachother in hierarchy I'm thinking there'd be no problem.
>
> Is this reasonable?  If not then I'm inclined to put in an infra request
> tonight.
>
> Thanks
> Joe
>
> On Thu, Jan 15, 2015 at 4:34 PM, Benson Margulies <[hidden email]>
> wrote:
>
>> I think I see a way to proceed that leaves people room to keep discussing.
>>
>> Here's my proposed procedure:
>>
>> git checkout -b nar-maven-plugin-0.0.1-release
>> mvn release:prepare
>>  # when it prompts, enter: 0.0.1-incubating
>> mvn release:perform
>> git checkout develop
>> git merge nar-maven-plugin-0.0.1-release
>> git push
>> git push --tags
>>
>> git checkout master
>> git merge-with-some-fancy-commands-that-insist-that-the-result-is...
>> the-tag-for-the-release
>> git push
>>
>> This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the
>> bother of another git repo. (c) seemingly end up with all the chickens
>> in the correct coops.
>>
>> However, if other think that it would be less confusing to move the
>> plugin to a repo, by all means ask infra for the repo and we'll go
>> from there.
>>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joe Witt
Agreed.  Pending no clear disagreement on this path I'll make those
adjustments tonight.  If it doesn't work out then all we did was make the
next logical step (going to a new git repo for maven stuff) easier.

Thanks
Joe

On Thu, Jan 15, 2015 at 4:58 PM, Benson Margulies <[hidden email]>
wrote:

> The structure you propose would be less confusing that what we have.
> Since I'm still too dense to follow what you wrote would go wrong if
> we released from the current structure, I don't see any problem with
> the new structure, either :-)  I probably need to reread your email.
> But don't wait on me -- if no one else dislikes your proposal, do it.
> On the RTC/CTR front, I really think that a discussion here of
> something like this _is_ an 'R', but that's just me.
>
>
> On Thu, Jan 15, 2015 at 4:44 PM, Joe Witt <[hidden email]> wrote:
> > Benson,
> >
> > I too would like to march forward without having to bother infra for
> > another git repo.
> >
> > What if we just move the directory structure a bit such that at the root
> > level of our git repo we have something like:
> >
> > - nifi [directory]
> > - maven-plugins [directory]
> > - README
> > - NOTICE
> > - DISCLAIMER
> > - LICENSE
> > - KEYS
> >
> > nifi then will contain all the stuff we have in Git today minus the
> > nar-maven-plugin subfolder.
> >
> > maven-plugins will contain a single subdirectory right now which would be
> > the 'nar-maven-plugin' but we'd soon add some archetypes there too.
> >
> > So then we release the project and artifacts of 'maven-plugins' and then
> > once all good we release 'nifi'.
> >
> > We can tag these releases and merge them to master.  Since they'd be
> > 'parallel' to eachother in hierarchy I'm thinking there'd be no problem.
> >
> > Is this reasonable?  If not then I'm inclined to put in an infra request
> > tonight.
> >
> > Thanks
> > Joe
> >
> > On Thu, Jan 15, 2015 at 4:34 PM, Benson Margulies <[hidden email]
> >
> > wrote:
> >
> >> I think I see a way to proceed that leaves people room to keep
> discussing.
> >>
> >> Here's my proposed procedure:
> >>
> >> git checkout -b nar-maven-plugin-0.0.1-release
> >> mvn release:prepare
> >>  # when it prompts, enter: 0.0.1-incubating
> >> mvn release:perform
> >> git checkout develop
> >> git merge nar-maven-plugin-0.0.1-release
> >> git push
> >> git push --tags
> >>
> >> git checkout master
> >> git merge-with-some-fancy-commands-that-insist-that-the-result-is...
> >> the-tag-for-the-release
> >> git push
> >>
> >> This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the
> >> bother of another git repo. (c) seemingly end up with all the chickens
> >> in the correct coops.
> >>
> >> However, if other think that it would be less confusing to move the
> >> plugin to a repo, by all means ask infra for the repo and we'll go
> >> from there.
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joe Witt
Team

I have made the changes described previous to the directory structure.  It
should make the release process a little more straight forward.  The
separation of the maven plugins to their own world should also provide a
nice landing spot for archetypes.  Bryan Bende has made what appears to be
a really awesome archetype for stubbing out a nar bundle so perhaps that
will work its way there sometime.

We will still need to iterate on the RTC discussion some more.  It feels
perfect for the 80% case.  For the 20% i think we'll need to be pretty
clear about what falls in that bucket.  This is a good thing to put into a
contributors guide.  That particular document feels less critical (in my
mind anyway) than a developer guide.

Benson: Please note I added the @{project.artifactId} in the tag naming
just so we could have it in the 'maven-plugins' parent area.  If this was
useless or counterproductive please advise.  One thing if you have a moment
to explain - what is the 'platform/pom.xml' line in the configuration of
the release plugin for?  My googling-fu let me down on figuring that out.

Thanks
Joe

On Thu, Jan 15, 2015 at 5:00 PM, Joe Witt <[hidden email]> wrote:

> Agreed.  Pending no clear disagreement on this path I'll make those
> adjustments tonight.  If it doesn't work out then all we did was make the
> next logical step (going to a new git repo for maven stuff) easier.
>
> Thanks
> Joe
>
> On Thu, Jan 15, 2015 at 4:58 PM, Benson Margulies <[hidden email]>
> wrote:
>
>> The structure you propose would be less confusing that what we have.
>> Since I'm still too dense to follow what you wrote would go wrong if
>> we released from the current structure, I don't see any problem with
>> the new structure, either :-)  I probably need to reread your email.
>> But don't wait on me -- if no one else dislikes your proposal, do it.
>> On the RTC/CTR front, I really think that a discussion here of
>> something like this _is_ an 'R', but that's just me.
>>
>>
>> On Thu, Jan 15, 2015 at 4:44 PM, Joe Witt <[hidden email]> wrote:
>> > Benson,
>> >
>> > I too would like to march forward without having to bother infra for
>> > another git repo.
>> >
>> > What if we just move the directory structure a bit such that at the root
>> > level of our git repo we have something like:
>> >
>> > - nifi [directory]
>> > - maven-plugins [directory]
>> > - README
>> > - NOTICE
>> > - DISCLAIMER
>> > - LICENSE
>> > - KEYS
>> >
>> > nifi then will contain all the stuff we have in Git today minus the
>> > nar-maven-plugin subfolder.
>> >
>> > maven-plugins will contain a single subdirectory right now which would
>> be
>> > the 'nar-maven-plugin' but we'd soon add some archetypes there too.
>> >
>> > So then we release the project and artifacts of 'maven-plugins' and then
>> > once all good we release 'nifi'.
>> >
>> > We can tag these releases and merge them to master.  Since they'd be
>> > 'parallel' to eachother in hierarchy I'm thinking there'd be no problem.
>> >
>> > Is this reasonable?  If not then I'm inclined to put in an infra request
>> > tonight.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Thu, Jan 15, 2015 at 4:34 PM, Benson Margulies <
>> [hidden email]>
>> > wrote:
>> >
>> >> I think I see a way to proceed that leaves people room to keep
>> discussing.
>> >>
>> >> Here's my proposed procedure:
>> >>
>> >> git checkout -b nar-maven-plugin-0.0.1-release
>> >> mvn release:prepare
>> >>  # when it prompts, enter: 0.0.1-incubating
>> >> mvn release:perform
>> >> git checkout develop
>> >> git merge nar-maven-plugin-0.0.1-release
>> >> git push
>> >> git push --tags
>> >>
>> >> git checkout master
>> >> git merge-with-some-fancy-commands-that-insist-that-the-result-is...
>> >> the-tag-for-the-release
>> >> git push
>> >>
>> >> This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the
>> >> bother of another git repo. (c) seemingly end up with all the chickens
>> >> in the correct coops.
>> >>
>> >> However, if other think that it would be less confusing to move the
>> >> plugin to a repo, by all means ask infra for the repo and we'll go
>> >> from there.
>> >>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Adam Taft
On Thu, Jan 15, 2015 at 9:54 PM, Joe Witt <[hidden email]> wrote:

> My googling-fu let me down on figuring that out.
>

​Indeed.​

https://www.google.com/#q=googling-fu
2,540,000 results
"Did you mean, google​-fu?"

https://www.google.com/#q=google-fu
83,9000,000 results
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Benson Margulies
In reply to this post by Joe Witt
On Thu, Jan 15, 2015 at 9:54 PM, Joe Witt <[hidden email]> wrote:

> Team
>
> I have made the changes described previous to the directory structure.  It
> should make the release process a little more straight forward.  The
> separation of the maven plugins to their own world should also provide a
> nice landing spot for archetypes.  Bryan Bende has made what appears to be
> a really awesome archetype for stubbing out a nar bundle so perhaps that
> will work its way there sometime.
>
> We will still need to iterate on the RTC discussion some more.  It feels
> perfect for the 80% case.  For the 20% i think we'll need to be pretty
> clear about what falls in that bucket.  This is a good thing to put into a
> contributors guide.  That particular document feels less critical (in my
> mind anyway) than a developer guide.
>
> Benson: Please note I added the @{project.artifactId} in the tag naming
> just so we could have it in the 'maven-plugins' parent area.  If this was
> useless or counterproductive please advise.  One thing if you have a moment
> to explain - what is the 'platform/pom.xml' line in the configuration of
> the release plugin for?  My googling-fu let me down on figuring that out.

 It should have said nar-maven-plugin/pom.xml; I ran some tests that
(I thought) would have failed if it was otherwise. I am completely
mystified that is ended up with 'platform'. That parameter is what you
use with the release plugin when you are releasing a subdirectory.

RIght now, ASF git is not responding to me. When it's alive, I'll see
how you left it and make adjustments. I might make a fake release with
a fake version where I'll drop the staging repo to make sure I have it
ironed out.

>
> Thanks
> Joe
>
> On Thu, Jan 15, 2015 at 5:00 PM, Joe Witt <[hidden email]> wrote:
>
>> Agreed.  Pending no clear disagreement on this path I'll make those
>> adjustments tonight.  If it doesn't work out then all we did was make the
>> next logical step (going to a new git repo for maven stuff) easier.
>>
>> Thanks
>> Joe
>>
>> On Thu, Jan 15, 2015 at 4:58 PM, Benson Margulies <[hidden email]>
>> wrote:
>>
>>> The structure you propose would be less confusing that what we have.
>>> Since I'm still too dense to follow what you wrote would go wrong if
>>> we released from the current structure, I don't see any problem with
>>> the new structure, either :-)  I probably need to reread your email.
>>> But don't wait on me -- if no one else dislikes your proposal, do it.
>>> On the RTC/CTR front, I really think that a discussion here of
>>> something like this _is_ an 'R', but that's just me.
>>>
>>>
>>> On Thu, Jan 15, 2015 at 4:44 PM, Joe Witt <[hidden email]> wrote:
>>> > Benson,
>>> >
>>> > I too would like to march forward without having to bother infra for
>>> > another git repo.
>>> >
>>> > What if we just move the directory structure a bit such that at the root
>>> > level of our git repo we have something like:
>>> >
>>> > - nifi [directory]
>>> > - maven-plugins [directory]
>>> > - README
>>> > - NOTICE
>>> > - DISCLAIMER
>>> > - LICENSE
>>> > - KEYS
>>> >
>>> > nifi then will contain all the stuff we have in Git today minus the
>>> > nar-maven-plugin subfolder.
>>> >
>>> > maven-plugins will contain a single subdirectory right now which would
>>> be
>>> > the 'nar-maven-plugin' but we'd soon add some archetypes there too.
>>> >
>>> > So then we release the project and artifacts of 'maven-plugins' and then
>>> > once all good we release 'nifi'.
>>> >
>>> > We can tag these releases and merge them to master.  Since they'd be
>>> > 'parallel' to eachother in hierarchy I'm thinking there'd be no problem.
>>> >
>>> > Is this reasonable?  If not then I'm inclined to put in an infra request
>>> > tonight.
>>> >
>>> > Thanks
>>> > Joe
>>> >
>>> > On Thu, Jan 15, 2015 at 4:34 PM, Benson Margulies <
>>> [hidden email]>
>>> > wrote:
>>> >
>>> >> I think I see a way to proceed that leaves people room to keep
>>> discussing.
>>> >>
>>> >> Here's my proposed procedure:
>>> >>
>>> >> git checkout -b nar-maven-plugin-0.0.1-release
>>> >> mvn release:prepare
>>> >>  # when it prompts, enter: 0.0.1-incubating
>>> >> mvn release:perform
>>> >> git checkout develop
>>> >> git merge nar-maven-plugin-0.0.1-release
>>> >> git push
>>> >> git push --tags
>>> >>
>>> >> git checkout master
>>> >> git merge-with-some-fancy-commands-that-insist-that-the-result-is...
>>> >> the-tag-for-the-release
>>> >> git push
>>> >>
>>> >> This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the
>>> >> bother of another git repo. (c) seemingly end up with all the chickens
>>> >> in the correct coops.
>>> >>
>>> >> However, if other think that it would be less confusing to move the
>>> >> plugin to a repo, by all means ask infra for the repo and we'll go
>>> >> from there.
>>> >>
>>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Benson Margulies
Joe has set things up on the assumption that all the maven stuff we
ever have will release at the same time. I could argue that each maven
item should be released independently, so we don't end up with
releases that are identical to their predecessors.
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joe Witt
My feeling there were not strong.  Feel free to adjust what I did.
On Jan 16, 2015 7:28 AM, "Benson Margulies" <[hidden email]> wrote:

> Joe has set things up on the assumption that all the maven stuff we
> ever have will release at the same time. I could argue that each maven
> item should be released independently, so we don't end up with
> releases that are identical to their predecessors.
>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Benson Margulies
Since your version gums up the mechanism for pushing source release
tarballs, I think I'll plan on being a splitter rather than figure out
how that goes wrong.

On Fri, Jan 16, 2015 at 7:46 AM, Joe Witt <[hidden email]> wrote:
> My feeling there were not strong.  Feel free to adjust what I did.
> On Jan 16, 2015 7:28 AM, "Benson Margulies" <[hidden email]> wrote:
>
>> Joe has set things up on the assumption that all the maven stuff we
>> ever have will release at the same time. I could argue that each maven
>> item should be released independently, so we don't end up with
>> releases that are identical to their predecessors.
>>
Reply | Threaded
Open this post in threaded view
|

Re: RTC for overhead activities, and git branches versus releases

Joe Witt
Fair enough.  Appreciate what you're doing
On Jan 16, 2015 7:57 AM, "Benson Margulies" <[hidden email]> wrote:

> Since your version gums up the mechanism for pushing source release
> tarballs, I think I'll plan on being a splitter rather than figure out
> how that goes wrong.
>
> On Fri, Jan 16, 2015 at 7:46 AM, Joe Witt <[hidden email]> wrote:
> > My feeling there were not strong.  Feel free to adjust what I did.
> > On Jan 16, 2015 7:28 AM, "Benson Margulies" <[hidden email]>
> wrote:
> >
> >> Joe has set things up on the assumption that all the maven stuff we
> >> ever have will release at the same time. I could argue that each maven
> >> item should be released independently, so we don't end up with
> >> releases that are identical to their predecessors.
> >>
>