#16 make it use the actual code that was merged in redhat-rpm-config-130
Merged 8 months ago by nim. Opened 8 months ago by nim.
nim/go-rpm-macros redhat-rpm-config-130  into  master

file modified
+2 -2

@@ -245,7 +245,7 @@ 

          "BuildArch:      noarch\n" ..

          "%{?currentgodevelheader}\n" ..

          "%description -n %{currentgodevelname}\n") ..

-       fedora.filterdescr("%{?currentgodeveldescription}") ..

+       fedora.wordwrap("%{?currentgodeveldescription}") ..

        "\n")

    elseif (kind == "alt") then

      local ismain = (suffix == "") or (suffix == "0")

@@ -267,7 +267,7 @@ 

            "BuildArch:      noarch\n" ..

            "%{?currentgoaltheader}\n" ..

            "%description -n %{currentgoaltname}\n") ..

-         fedora.filterdescr("%{?currentgoaltdescription}") ..

+         fedora.wordwrap("%{?currentgoaltdescription}") ..

          "\n")

      end

    else

@@ -64,7 +64,7 @@ 

  URL:     %{gourl}

  Source0: %{gosource}

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  # Generate package declarations for all known kinds of Go subpackages.

  # You can replace if with “godevelpkg” to generate Go devel subpackages only.

@@ -84,7 +84,7 @@ 

  URL:     %{gourl}

  Source0: %{gosource}

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  %gopkg

  

@@ -43,7 +43,7 @@ 

  URL:     %{gourl}

  Source0: %{gosource}

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  # Generate package declarations for all known kinds of Go subpackages. You can

  # replace if with separate “goaltpkg” and “godevelpkg” calls.

@@ -69,7 +69,7 @@ 

  URL:     %{gourl}

  Source0: %{gosource}

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  %gopkg

  

@@ -42,7 +42,7 @@ 

  URL:     %{gourl}

  Source0: %{gosource}

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  %gopkg

  

@@ -59,7 +59,7 @@ 

  URL:     %{gourl}

  Source0: %{gosource}

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  %gopkg

  

@@ -132,7 +132,7 @@ 

  Source1: %{gosource1}

  # …

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  # “gopkg” will generate all the subpackages package declarations corresponding

  # to the elements declared above.

@@ -32,7 +32,7 @@ 

  URL:     %{gourl}

  Source0: %{gosource}

  %description

- %filterdescr -v common_description

+ %wordwrap -v common_description

  

  %package -n %{goname}-devel

  Summary: %{summary}

no initial comment

Pull-Request has been merged by nim

8 months ago

I would appreciate if you would not merge your own PRs in one minute after opening.

@ignatenkobrain sorry, I didn't know there was much interest in reviewing such a trivial commit (or in go-rpm-macros PRs in general). If you have any comment on the result, please report it, code is not set in stone, merge or no merge.

I mean, if it is trivial - just commit it. I this not first PR where this happens.

Ah, that

Just because it is trivial does not mean stupid typos can not happen, so the commits cook in a private feature branch (where I can rewrite git history without bothering anyone) and are merged when they pass testing.

The commit state that get merged is rarely the first version I wrote.

Is there a simpler/better method to move reliably a set of commits from a forked feature branch to the main project?

@nim it is customary in almost every project I have been in that someone doesn't merge their own commit unless time has passed/emergency situations.

I think what @ignatenkobrain is getting at is that there are multiple membes of this repo and the whole Go SIG. It is perhaps worth putting the commit policy in writing to prevent confusions and misunderstandings.

In my own experience I have seen my trivial patches viewed as non-trivial by others (and vice versa) and one-line commits get a lot of commentary.

@bex sadly there are not many (any?) good wills to do regular reviewing. The repo history shows long periods of one-man commits, be it now or when the maintenance was done by others. @eclipseo does most of the second level checking/testing nowadays (thanks a lot!) but that does not happen in PR tickets (and sometimes he tests pre-versions of code before they even end up in a PR)

So it's not a SIG policy set in stone, just a side effect of the small kernel of people that work on Fedora Go tooling. It can change any time people show up and propose to take ownership of something (be it reviewing, documenting, or anything else that could benefit from more contributions).

If anyone here volunteers to conduct a formal review of the next PRs, there's no problem to keep them open some more. As long as it's not just gathering up dust in the hope some hypothetical reviewer will eventually show up.

@nim if you are not looking for feedback keep it open for some time and then merge it with something like tested here in this way works for me or just commit and push directly in to the master branch this kind of looks really bad.
I have been trying to provide you with feedback in the past, but you made to me obvious that you are not wanting it by shaming and blaming me and others.