You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Dominik Psenner <dp...@gmail.com> on 2017/06/09 15:12:52 UTC
Re: [LOG4NET] [VOTE] gitflow
Hi,
On 2017-05-23 08:49, Stefan Bodewig wrote:
> Please ensure github tracks develop as the default branch when the vote passes.
I just filed an issue on INFRA to make this happen. This is the ticket
for it:
https://issues.apache.org/jira/browse/INFRA-14316
Cheers,
Dominik
Re: [LOG4NET] [VOTE] gitflow
Posted by Matt Sicker <bo...@gmail.com>.
In theory, you can use Jenkins pipelines scripts in your projects, but I
haven't tested that out yet. It's the system we're using at my work.
On 12 June 2017 at 14:25, Dominik Psenner <dp...@gmail.com> wrote:
> I envision to automate the build and publishing process. At work we are
> migrating to git and along with that we are going to set up our (insane)
> build process with gitlab runners executed by virtualbox executors. See
> https://docs.gitlab.com/runner/ and
> https://docs.gitlab.com/ee/ci/yaml/README.html for more info.
>
> Does the asf have the infrastructure to parse pipelines and run them as
> scripted in a yml file that is checked in and versioned?
>
> On 12 Jun 2017 5:59 p.m., "Matt Sicker" <bo...@gmail.com> wrote:
>
> > We're doing the same in log4j right now as well. I'd love to figure out a
> > more fluid way of doing this eventually.
> >
> > On 12 June 2017 at 10:16, Stefan Bodewig <bo...@apache.org> wrote:
> >
> > > On 2017-06-12, Matt Sicker wrote:
> > >
> > > > That's an interesting use case. Are you using gitpubsub instead of
> > > > svnpubsub for the site then?
> > >
> > > "mvn site" plus manual copy over to svn plus the logging site's
> > > svnpubsub. Yes, it is painful :-)
> > >
> > > Stefan
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] [VOTE] gitflow
Posted by Dominik Psenner <dp...@gmail.com>.
I envision to automate the build and publishing process. At work we are
migrating to git and along with that we are going to set up our (insane)
build process with gitlab runners executed by virtualbox executors. See
https://docs.gitlab.com/runner/ and
https://docs.gitlab.com/ee/ci/yaml/README.html for more info.
Does the asf have the infrastructure to parse pipelines and run them as
scripted in a yml file that is checked in and versioned?
On 12 Jun 2017 5:59 p.m., "Matt Sicker" <bo...@gmail.com> wrote:
> We're doing the same in log4j right now as well. I'd love to figure out a
> more fluid way of doing this eventually.
>
> On 12 June 2017 at 10:16, Stefan Bodewig <bo...@apache.org> wrote:
>
> > On 2017-06-12, Matt Sicker wrote:
> >
> > > That's an interesting use case. Are you using gitpubsub instead of
> > > svnpubsub for the site then?
> >
> > "mvn site" plus manual copy over to svn plus the logging site's
> > svnpubsub. Yes, it is painful :-)
> >
> > Stefan
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [LOG4NET] [VOTE] gitflow
Posted by Matt Sicker <bo...@gmail.com>.
We're doing the same in log4j right now as well. I'd love to figure out a
more fluid way of doing this eventually.
On 12 June 2017 at 10:16, Stefan Bodewig <bo...@apache.org> wrote:
> On 2017-06-12, Matt Sicker wrote:
>
> > That's an interesting use case. Are you using gitpubsub instead of
> > svnpubsub for the site then?
>
> "mvn site" plus manual copy over to svn plus the logging site's
> svnpubsub. Yes, it is painful :-)
>
> Stefan
>
--
Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] [VOTE] gitflow
Posted by Stefan Bodewig <bo...@apache.org>.
On 2017-06-12, Matt Sicker wrote:
> That's an interesting use case. Are you using gitpubsub instead of
> svnpubsub for the site then?
"mvn site" plus manual copy over to svn plus the logging site's
svnpubsub. Yes, it is painful :-)
Stefan
Re: [LOG4NET] [VOTE] gitflow
Posted by Matt Sicker <bo...@gmail.com>.
That's an interesting use case. Are you using gitpubsub instead of
svnpubsub for the site then?
On 10 June 2017 at 12:41, Dominik Psenner <dp...@gmail.com> wrote:
> We have also the site versioned in the same repository. Updates to the
> website do not necessarily synchronize well with the library releases. So
> this is a good example where the master branch is useful to track published
> website patches. In a wider sense, updates to the website are one kind of
> hot fix releases that do not bump the version of the library.
>
> Cheers,
> Dominik
>
> On 9 Jun 2017 11:02 p.m., "Matt Sicker" <bo...@gmail.com> wrote:
>
> > Agreed. Whenever I've used git-flow in the past, the only reason we had a
> > develop and master branch was so that it was simpler to write hotfixes
> > against master later on. We'd delete our release branches after they were
> > tagged and merged to master&develop, so the only ways to find what's in
> > production are to either take the head of master or the highest numbered
> > tag name.
> >
> > On 9 June 2017 at 14:05, Gary Gregory <ga...@gmail.com> wrote:
> >
> > > I'm unlikely to do development on Log4jnet but I like having 'master'
> > > instead of 'develop' for the reason Julius stated.
> > >
> > > Gary
> > >
> > > On Fri, Jun 9, 2017 at 9:07 AM, Julius Davies <ju...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > The 'master' branch in the gitflow model is pointless (that state is
> > > > already tracked with the 'release/*' branches). I say ditch the
> > > 'master'
> > > > branch and make 'develop' the default branch (e.g., the one that a
> > fresh
> > > > "git clone" automatically checks out).
> > > >
> > > > And rebase the short lived feature branches against develop before
> > > merging
> > > > them to make the history cleaner:
> > > >
> > > > git checkout feature/TKT-123
> > > > [do work...]
> > > > git fetch
> > > > git rebase origin/develop
> > > > git push --force-with-lease
> > > >
> > > >
> > > > (Honestly I prefer to rename 'develop' to 'master' because then it
> > > matches
> > > > the terminology of most git documentation and tutorials on the web).
> > > >
> > > >
> > > > Sorry, drive by email. I've been subscribed this email list for a
> > > decade
> > > > but I don't think I've ever posted before.
> > > >
> > > >
> > > > yours,
> > > >
> > > > Julius
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jun 9, 2017 at 8:12 AM, Dominik Psenner <dp...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > On 2017-05-23 08:49, Stefan Bodewig wrote:
> > > > >
> > > > >> Please ensure github tracks develop as the default branch when the
> > > vote
> > > > >> passes.
> > > > >>
> > > > >
> > > > > I just filed an issue on INFRA to make this happen. This is the
> > ticket
> > > > for
> > > > > it:
> > > > >
> > > > > https://issues.apache.org/jira/browse/INFRA-14316
> > > > >
> > > > > Cheers,
> > > > > Dominik
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] [VOTE] gitflow
Posted by Dominik Psenner <dp...@gmail.com>.
We have also the site versioned in the same repository. Updates to the
website do not necessarily synchronize well with the library releases. So
this is a good example where the master branch is useful to track published
website patches. In a wider sense, updates to the website are one kind of
hot fix releases that do not bump the version of the library.
Cheers,
Dominik
On 9 Jun 2017 11:02 p.m., "Matt Sicker" <bo...@gmail.com> wrote:
> Agreed. Whenever I've used git-flow in the past, the only reason we had a
> develop and master branch was so that it was simpler to write hotfixes
> against master later on. We'd delete our release branches after they were
> tagged and merged to master&develop, so the only ways to find what's in
> production are to either take the head of master or the highest numbered
> tag name.
>
> On 9 June 2017 at 14:05, Gary Gregory <ga...@gmail.com> wrote:
>
> > I'm unlikely to do development on Log4jnet but I like having 'master'
> > instead of 'develop' for the reason Julius stated.
> >
> > Gary
> >
> > On Fri, Jun 9, 2017 at 9:07 AM, Julius Davies <ju...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > The 'master' branch in the gitflow model is pointless (that state is
> > > already tracked with the 'release/*' branches). I say ditch the
> > 'master'
> > > branch and make 'develop' the default branch (e.g., the one that a
> fresh
> > > "git clone" automatically checks out).
> > >
> > > And rebase the short lived feature branches against develop before
> > merging
> > > them to make the history cleaner:
> > >
> > > git checkout feature/TKT-123
> > > [do work...]
> > > git fetch
> > > git rebase origin/develop
> > > git push --force-with-lease
> > >
> > >
> > > (Honestly I prefer to rename 'develop' to 'master' because then it
> > matches
> > > the terminology of most git documentation and tutorials on the web).
> > >
> > >
> > > Sorry, drive by email. I've been subscribed this email list for a
> > decade
> > > but I don't think I've ever posted before.
> > >
> > >
> > > yours,
> > >
> > > Julius
> > >
> > >
> > >
> > >
> > > On Fri, Jun 9, 2017 at 8:12 AM, Dominik Psenner <dp...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On 2017-05-23 08:49, Stefan Bodewig wrote:
> > > >
> > > >> Please ensure github tracks develop as the default branch when the
> > vote
> > > >> passes.
> > > >>
> > > >
> > > > I just filed an issue on INFRA to make this happen. This is the
> ticket
> > > for
> > > > it:
> > > >
> > > > https://issues.apache.org/jira/browse/INFRA-14316
> > > >
> > > > Cheers,
> > > > Dominik
> > > >
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [LOG4NET] [VOTE] gitflow
Posted by Matt Sicker <bo...@gmail.com>.
Agreed. Whenever I've used git-flow in the past, the only reason we had a
develop and master branch was so that it was simpler to write hotfixes
against master later on. We'd delete our release branches after they were
tagged and merged to master&develop, so the only ways to find what's in
production are to either take the head of master or the highest numbered
tag name.
On 9 June 2017 at 14:05, Gary Gregory <ga...@gmail.com> wrote:
> I'm unlikely to do development on Log4jnet but I like having 'master'
> instead of 'develop' for the reason Julius stated.
>
> Gary
>
> On Fri, Jun 9, 2017 at 9:07 AM, Julius Davies <ju...@gmail.com>
> wrote:
>
> > Hi,
> >
> > The 'master' branch in the gitflow model is pointless (that state is
> > already tracked with the 'release/*' branches). I say ditch the
> 'master'
> > branch and make 'develop' the default branch (e.g., the one that a fresh
> > "git clone" automatically checks out).
> >
> > And rebase the short lived feature branches against develop before
> merging
> > them to make the history cleaner:
> >
> > git checkout feature/TKT-123
> > [do work...]
> > git fetch
> > git rebase origin/develop
> > git push --force-with-lease
> >
> >
> > (Honestly I prefer to rename 'develop' to 'master' because then it
> matches
> > the terminology of most git documentation and tutorials on the web).
> >
> >
> > Sorry, drive by email. I've been subscribed this email list for a
> decade
> > but I don't think I've ever posted before.
> >
> >
> > yours,
> >
> > Julius
> >
> >
> >
> >
> > On Fri, Jun 9, 2017 at 8:12 AM, Dominik Psenner <dp...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > On 2017-05-23 08:49, Stefan Bodewig wrote:
> > >
> > >> Please ensure github tracks develop as the default branch when the
> vote
> > >> passes.
> > >>
> > >
> > > I just filed an issue on INFRA to make this happen. This is the ticket
> > for
> > > it:
> > >
> > > https://issues.apache.org/jira/browse/INFRA-14316
> > >
> > > Cheers,
> > > Dominik
> > >
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] [VOTE] gitflow
Posted by Gary Gregory <ga...@gmail.com>.
I'm unlikely to do development on Log4jnet but I like having 'master'
instead of 'develop' for the reason Julius stated.
Gary
On Fri, Jun 9, 2017 at 9:07 AM, Julius Davies <ju...@gmail.com>
wrote:
> Hi,
>
> The 'master' branch in the gitflow model is pointless (that state is
> already tracked with the 'release/*' branches). I say ditch the 'master'
> branch and make 'develop' the default branch (e.g., the one that a fresh
> "git clone" automatically checks out).
>
> And rebase the short lived feature branches against develop before merging
> them to make the history cleaner:
>
> git checkout feature/TKT-123
> [do work...]
> git fetch
> git rebase origin/develop
> git push --force-with-lease
>
>
> (Honestly I prefer to rename 'develop' to 'master' because then it matches
> the terminology of most git documentation and tutorials on the web).
>
>
> Sorry, drive by email. I've been subscribed this email list for a decade
> but I don't think I've ever posted before.
>
>
> yours,
>
> Julius
>
>
>
>
> On Fri, Jun 9, 2017 at 8:12 AM, Dominik Psenner <dp...@gmail.com>
> wrote:
>
> > Hi,
> >
> > On 2017-05-23 08:49, Stefan Bodewig wrote:
> >
> >> Please ensure github tracks develop as the default branch when the vote
> >> passes.
> >>
> >
> > I just filed an issue on INFRA to make this happen. This is the ticket
> for
> > it:
> >
> > https://issues.apache.org/jira/browse/INFRA-14316
> >
> > Cheers,
> > Dominik
> >
>
Re: [LOG4NET] [VOTE] gitflow
Posted by Julius Davies <ju...@gmail.com>.
Hi,
The 'master' branch in the gitflow model is pointless (that state is
already tracked with the 'release/*' branches). I say ditch the 'master'
branch and make 'develop' the default branch (e.g., the one that a fresh
"git clone" automatically checks out).
And rebase the short lived feature branches against develop before merging
them to make the history cleaner:
git checkout feature/TKT-123
[do work...]
git fetch
git rebase origin/develop
git push --force-with-lease
(Honestly I prefer to rename 'develop' to 'master' because then it matches
the terminology of most git documentation and tutorials on the web).
Sorry, drive by email. I've been subscribed this email list for a decade
but I don't think I've ever posted before.
yours,
Julius
On Fri, Jun 9, 2017 at 8:12 AM, Dominik Psenner <dp...@gmail.com> wrote:
> Hi,
>
> On 2017-05-23 08:49, Stefan Bodewig wrote:
>
>> Please ensure github tracks develop as the default branch when the vote
>> passes.
>>
>
> I just filed an issue on INFRA to make this happen. This is the ticket for
> it:
>
> https://issues.apache.org/jira/browse/INFRA-14316
>
> Cheers,
> Dominik
>