#3 Make the packaging draft up to date
Opened 3 years ago by jcajka. Modified 3 years ago

Update packaging guidelines draft with new things that got implemented from the https://fedoraproject.org/wiki/More_Go_packaging (forge macros,...)

Metadata Update from @jcajka:
- Issue marked as blocking: #2

3 years ago

The spec templates are finished and published in templates.

They can be pushed FPC-side, as soon as the SIG agrees no further tweaking is required.

Metadata Update from @nim:
- Issue status updated to: Closed (was: Open)

3 years ago

Metadata Update from @jcajka:
- Issue status updated to: Open (was: Closed)

3 years ago

I don't see how your issue #20 is resolving this, it doesn't mention docs at all.

This is step 4 of the migration plan.

Basically, guidelines are about how to package things practically, which boils down to commented packaging templates, and the templates are written and available in the go-rpm-macros repository.

It’s useless to spend time on any wiki draft since FPC converted to another guidelines format and won’t accept wiki submissions anymore. You have an example of the new submission format here.

So the work is done, except for the final SIG review of go-rpm-macros (this is step 3 of the migration plan), that can lead to tweaks in macros and in the templates that document them.

@nim in step 4(mind you even marked it as optional) you are talking about commented templates(applied guidelines) not guidelines(formal definition of what needs to be done and is expected behavior of the macros stack).

@jcajka Fedora packaging guidelines are applied guidelines. If you want some form of document created, that FPC does not want to hear about, please start by not calling it packaging draft or guidelines in the Fedora sense.

Furthermore, formal specifications are just a tool. They are not a substitute to getting involved, understanding the implementation, and identifying the implementation parts that need reworking. They can be useful once you get to this point, and you have a group of people that need a support to track their decisions and the reasons behind those decisions. Otherwise it’s just ass-covering paperwork that documents none of the tricky points that need documenting, goes in extensive detail on all the self-evident things that need no explanation in the first place, and that no one actually reads because it is all perfectly pointless. That's why the IETF requires two independent implementations before even thinking about making a formal spec official.

And unit tests suffer from the same bias of testing the wrong things because they are the easy things to test, just to show up some testing was done to management.

I work in an heavily regulated industry, where mistakes kill people, that is commonly excluded from software licensing because devs do not want to deal with the associated obligations. So I know perfectly well what is a formal specification, when it is useful, and when it is used as an excuse to not getting involved. Some of mine have been reviewed by third-parties, including competitors and the government (and I passed).

So please start with an applied review, and if there are tricky points that need a formal specification after the applied review, it will get done.

And if you do not want to do an applied review of internal rpm lua and shell macro code, either take it as is or find someone you trust to do the review. That's the actual sticking point. You do not trust me fine. Find someone you trust. Or try the code and make yourself and opinion. Do not hope for magic formal specs you won't understand or like any more than the implementation code to solve the trust issue for you.

sigh @nim first of all I would like to kindly ask you to stop putting words in to my mouth.
Secondly I do respect the work that you do at your day job(wherever, whatever for whomever you are working for,at,on) and that you want to in some form contribute back to the open source community.
My main issue with this proposal is that it completely lacks user/packager facing documentation in standard format commonly used by the Fedora project and you are explicit refusing to provide any. I have suggested to you if you really do not wan to do any user docs at least implement some sort of automated testing that can be used as basis in getting familiar with your packaging system.
With this attitude of yours, I see as second biggest issue maintainability of what you want to contribute. As without the knowledge transfer(that you are actively refusing to do) you and your co-workers/employees are the only people that are capable of understanding this complex system and effectively maintaining and using it. This effectively hinders any possibility to grow healthy community around it. This is reason why I believe we as Fedora(Go SIG) are better of with what we have now(however lacking), but approachable(even through FUD that you built up over past year) system and not endorsing yours.
From my experience with talking and working with you online in Fedora. You are not seeking feedback and collaboration, but somebody that you can dump your day job on.
I can't bar you from implementing this system in Fedora via the standard system wide change workflow and accompanying processes nor I want to block you in any way. But I don't want to spend my limited time on something that I have substantial technical disagreement and where my feedback is dismissed and not respected.
I do hope that I'm wrong in some of my conclusions and you will prove me wrong while bringing Fedora Go packaging to the next level.

@jcajka for the n-th time the user-facing doc exists here and is complete. Several orders of magnitude more complete than what is in Fedora now or what were in Fedora before I got involved Go side.

This format is good enough to have been accepted recently in other Fedora guidelines for the redhat-rpm-config forge parts. That makes it as official as it could be. (and BTW the macro implementation also follows the patterns that emerged during the redhat-rpm-config changes review because the redhat-rpm-config maintainers did provide useful constructive feedback)

The code is completely documented and I had complete strangers who asked me "where is the doc" find their answer in the code itself in the few hours it took me to see and answer their question.

You do not want to look at it. That has been plain for quite a long time. Thank you for writing it up. That's honest.

What's not honest is telling people I'm lying when I say you're refusing to work on this implementation.

What's not honest is telling this proposal is undocumented.

What's not honest is telling people you understand the format Fedora documentation needs to be in when none of your documentation proposals got accepted by Fedora instances over many years. If the current code is so good get its doc accepted and then you can tell others their doc is rubish.

What's not honest is calling the problems of the current Fedora implementation FUD when you just don't want to work on them. State plainly the parts when you feel the current implementation does not need the proposed fixes and we'll see who is FUDing.

It took months of work to prepare all the various things you asked at various times. After all this work you still do not want to look at things. You're not providing feedback you're just blocking things up. You complain about knowledge transfer — how is that supposed to happen when you just refuse to look at things and ask what you don't understand?

You make it a Go SIG position when you refuse to discuss it in SIG meetings. Is the Go SIG just you in your own mind? Do you think any "healthy" community is likely to emerge this way? Before making decisions for everyone else in the Fedora Go community, in their name, could you at least bother to ask them all if they need all the fixes and changes your dismiss, and if they also find out the documentation you don't want to read lacking?

I don't have any problem discussing publicly this code and why it is useful. You call such discussions FUD. Where are your alternative non-FUD proposals then?

I really didn't want to get involved in this discussion, but here goes ...

This format is good enough to have been accepted recently in other Fedora guidelines for the redhat-rpm-config forge parts. That makes it as official as it could be.

Speaking for the FPC, I'd say that's not entirely true. I was the member who pushed to accept the current version of the "forge" macro documentation, but only because I didn't think we'd ever get a better proposal, since you didn't seem to understand what we'd like to see. FPC also discussed how nothing else concerning the Packaging Guidelines is "documented" this way (annotated example files), and that I'll write some accompanying text to fill the gap of actual "Guidelines" text (when I can find motivation and time to do that).

@decathorpe Thanks for the additional information. I'm not saying things are perfect, and I'm definitely curious about the complements you will find worthwhile to add when you get around it (feel free to ask all the questions where I can help you write those). But the point it, things will go forward on the doc side because you will take a look at it and provide input and complements, just like they went forward on the implementation side for the same reason (thanks to @ignatenkobrain, and @tibbs, and @ngompa).

And none of it has been happening Go side for almost a year now, with a vastly broader problem space, and much nastier things to process. It's never good enough to look at, but expecting things to shape up, without anyone looking at it, is unrealistic.

And, lastly, the existing code is even more undocumented brittle incomplete and full of bugs (both mine that I have fixed since, and @jchaloup bugs, because he had not had the time to do a thorough solid job). But somehow, endorsing it is ok. And fixing it is not urgent. In fact, it is urgent to do nothing: neither to fix the existing code, nor to look at my changes. How things are supposed to improve with that attitude, I have not the faintest idea.

@nim sigh sigh Nicolas, I would gain kindly ask you again not to put words in to my mouth(as matter of fact in to anybody's) or making up stuff that I or anyone else in Go SIG and Fedora have not done.

Nicolas I do not want to play your blame games. I believe that we all have lot of work to do and I believe we will better of not arguing but actually creating something.

Please stop this nonconstructive blaming and ranting. Nobody is blocking you on anything, you can pursue the changes that you want/need via standard(to the Fedora as a whole) documented channels.

Login to comment on this ticket.