2:25 p.m.
Hi,
I'd like to request FPC feedback on Fedora Reviews done outside the
Fedora Reviewing Process.
https://bugzilla.redhat.com/show_bug.cgi?id=1310886
Regards,
H.
3:11 p.m.
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.
On Feb 27, 2016 17:26, "Haïkel" <hguemar(a)fedoraproject.org> wrote:
Hi,
I'd like to request FPC feedback on Fedora Reviews done outside the
Fedora Reviewing Process.
https://bugzilla.redhat.com/show_bug.cgi?id=1310886
Regards,
H.
--
packaging mailing list
packaging(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org
4:20 p.m.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1211517
I see few problems
1. context loss, there's no feedback on bugzilla
2. making it harder for fellow packagers to participate in the review.
3. requires Fedora packagers to rely on external platforms.
4. undocumented process
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.
In the end, it could be acceptable (or not), but it has to be discussed.
1:45 p.m.
Hi,
On 02/27/2016 09:25 PM, Haïkel wrote:
Hi,
I'd like to request FPC feedback on Fedora Reviews done outside the
Fedora Reviewing Process.
https://bugzilla.redhat.com/show_bug.cgi?id=1310886
It is not the official review. The github.com/gofed/reviews is here to
deal with the most common mistakes when packaging golang projects. At
the same time I would like to collect all corner cases and user inputs
to know what packagers expect from the spec file. So I can provide
better tooling and automation. Once it is done, the official review goes
in the bugzilla.
Regards,
H.
--
packaging mailing list
packaging(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org
2:01 p.m.
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.
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(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org
10:48 a.m.
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.
> https://bugzilla.redhat.com/show_bug.cgi?id=1211517
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
[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
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
participate.
> 2. making it harder for fellow packagers to participate in the
review.
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
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'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
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.
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(a)lists.fedoraproject.org
>>
>> http://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org
>
> --
> packaging mailing list
> packaging(a)lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org
2976
days inactive
2978
days old
packaging@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Gerald B. Cox -
Haïkel -
Jan Chaloupka