On 02/27/2016 11:20 PM, Haïkel wrote:
2016-02-27 22:11 GMT+01:00 Gerald B. Cox <gbcox@xxxxxx>:
It's not a review if it doesn't follow the process. That said, I
personally don't see any harm with constructive critiquing prior to an
official review.
btw, I already asked them in the past to contact FPC about it few
months earlier and yet nothing.
https://bugzilla.redhat.com/show_bug.cgi?id=1211517
Since that time guidelines for bundling have changed.
I see few problems
1. context loss, there's no feedback on bugzilla
What context are you referring to? If you read the comments you can get
a good picture of what I was talking about. I have referenced the ftp
ticket [1] in which I summarize the most critical problems for golang
packaging. Is there anything else you need to know wrt. bundling vs.
debundling. What feedback would be sufficient?
[1] https://fedorahosted.org/fpc/ticket/382
2. making it harder for fellow packagers to participate in the review.
Harder in what way?
3. requires Fedora packagers to rely on external platforms.
Can you be more specific? What external platforms do you mean? Can you
give me a review where a packager had to rely on an external platform?
4. undocumented process
https://fedoraproject.org/wiki/PackagingDrafts/Go
https://fedorahosted.org/fpc/ticket/382
What else is missing? Give me a list of steps that are not documented
and I will update the draft.
I agree that bugzilla is an horrible tool for packages reviews but it
should concerted with the whole Fedora community and not done behind
closed doors.
Meaning the link to github spec file can get lost? Any link in any
review can get lost over time.
Closed doors? The bugzilla provides a link into the github spec file.
Or is there anything the bugzilla hides? Any information not provided?
If you want to participate in any golang review, I would be glad and you
would be welcome. Just let me know and I will CC in any review. It is
not an exception to have 10 or 15 new golang project to get into fedora
and review. The github is here to help others to see the most common
mistakes in their spec file and to learn from them. So they can update
they spec files before the review and save time of reviewers. So
reviewers can deal with project specific problems, not golang packaging
specific ones. I don't think anyone will search bugzilla for golang
reviews to see what else needs to be done.
In the end, it could be acceptable (or not), but it has to be discussed.
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
