2016-02-28 21:01 GMT+01:00 Jan Chaloupka <jchaloup(a)redhat.com>:
On 02/27/2016 11:20 PM, Haïkel wrote:
> 2016-02-27 22:11 GMT+01:00 Gerald B. Cox <gbcox(a)bzb.us>:
>> 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.
Since that time guidelines for bundling have changed.
Thanks, I know I was there when Fesco voted that change.
The new guidelines enforces that you declare bundled libraries.
> 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
 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?
You're mixing topics, we lose the context of the review in the bugzilla ticket.
Bugzilla ticket has no content, no discussion where your fellow packagers can
> 2. making it harder for fellow packagers to participate in the
Harder in what way?
All the discussion happens on github and not in bugzilla.
> 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?
See above, you're not answering the point at all.
> 4. undocumented process
What else is missing? Give me a list of steps that are not documented and I
will update the draft.
I'm not speaking about guidelines but about the review process, stop
addressing the wrong point.
> 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.
We can loose links, but at least, we don't lose the context aka discussions.
Closed doors? The bugzilla provides a link into the github spec file.
A lot of Fedora packagers refuse to use github or any proprietary platforms.
Or is there anything the bugzilla hides? Any information not
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.
No, the problem is that all the discussion happens outside the Fedora
reviewing process, and rather than actively discussing with the Fedora
community to improve the process, it looks like you're circumventing
the whole thing.
Moreover, that doesn't help people to do informal reviews which are
part of our culture, this is how new packagers learn our guidelines
and best practices, how our peers can verify reviews, some discussions
in a bugzilla ticket could raise a bigger issue that needs to be
addressed at a higher level.
By allowing a different process for golang packages, we're just
ruining the consistency of the whole reviewing experience, you're
raising the barrier to anyone who wants to help contributing to golang
packaging in the *community*
If you want to improve the reviewing experience, why not contributing
additional checks to fedora-review rather than leveraging github?
I'm not here to blame you or whatever, just saying that this is the
wrong way to address a very concrete issue, so yes, it's the role of
FPC to take a look at that.
It could be fine, or they don't care, or wrong, up to them to judge.
>> In the end, it could be acceptable (or not), but it has to be discussed.
>> packaging mailing list
> packaging mailing list