On Wed, 2012-09-26 at 10:46 -0400, Richard Ryniker wrote:
> On 09/26/2012 10:37 AM, Kamil Paral wrote:
> > I personally split maintainers in the distribution into three
> > categories.
> >
> > 1. Packager
> >
> > 2, Maintainer
> >
> > 3. Upstream maintainer
>
> Is this an argument for an additiona
On 09/26/2012 10:37 AM, Kamil Paral wrote:
> I personally split maintainers in the distribution into three
> categories.
>
> 1. Packager
>
> 2, Maintainer
>
> 3. Upstream maintainer
Is this an argument for an additional Fedora package class? At present,
it seems there are two well-defined types:
On 09/26/2012 10:45 AM, Karel Volný wrote:
Dne St 26. září 2012 10:37:54, Jan Pazdziora napsal(a):
>(they have accounts in the upstream bug tracking systems).
just a note, this is very valid point
Indeed but will never come to be unless it will be made mandatory for
packagers , pack of the r
On 09/26/2012 10:37 AM, Kamil Paral wrote:
I personally split maintainers in the distribution into three
categories.
1. Packager
2, Maintainer
3. Upstream maintainer
Nice categorization.
We differ in the view of Packagers. You consider them harmful, I consider them desired. I am
missing *lo
Dne St 26. září 2012 10:37:54, Jan Pazdziora napsal(a):
> (they have accounts in the upstream bug tracking systems).
just a note, this is very valid point
I've given up reporting many problems just because of the initial
barrier - to find the upstream way of handling bugs (not every
project has i
On 09/26/2012 10:28 AM, Kamil Paral wrote:
I completely missed my point. I was suggesting middle ground - lots of packages
and clear bug reporting guidelines configurable for each of them. That can help
us avoid stale NEW bugs.
That is something you need to fix on packagers/maintainers level
> I personally split maintainers in the distribution into three
> categories.
>
> 1. Packager
>
> 2, Maintainer
>
> 3. Upstream maintainer
Nice categorization.
We differ in the view of Packagers. You consider them harmful, I consider them
desired. I am missing *lots* of packages in Fedora whe
> I'd rather have limited set of packages that are well supported with
> bugzillas acted upon than load of packages where bugzillas are all
> NEW
> or UPSTREAM.
I completely missed my point. I was suggesting middle ground - lots of packages
and clear bug reporting guidelines configurable for each
On 09/26/2012 10:08 AM, Jan Pazdziora wrote:
On Wed, Sep 26, 2012 at 05:25:06AM -0400, Kamil Paral wrote:
In my opinion this should be a maintainer choice. Ideally there would be a support for this choice in
Bugzilla. When reporting a new bug against component X, "bug reporting guidelines" woul
On 09/26/2012 07:50 AM, Matej Cepl wrote:
On 26/09/12 01:21, "Jóhann B. Guðmundsson" wrote:
If we send reporters upstream to read documents we can just as well send
them by the same method to upstream bugzilla's to file reports.
Yes, I think it could be preferred way for some bugs and some
co
On Wed, Sep 26, 2012 at 05:25:06AM -0400, Kamil Paral wrote:
> In my opinion this should be a maintainer choice. Ideally there would be a
> support for this choice in Bugzilla. When reporting a new bug against
> component X, "bug reporting guidelines" would be displayed (Launchpad already
> supp
On 09/26/2012 08:37 AM, Jan Pazdziora wrote:
The Fedora maintainers are supposed to bring the upstream to the
distribution and maintain it there. The Fedora users are supposed
to use the distribution, not compile the upstream themselves. It's
the Fedora maintainer that should do the communication
On 09/26/2012 09:25 AM, Kamil Paral wrote:
In my opinion this should be a maintainer choice.
That will only lead to confusion for members of the QA community.
Either we direct all QA community members upstream *always* or we keep
them locally *always*
JBG
--
test mailing list
test@lists.fed
> > What would you prefer? Upstream balancing five bug reports in five
> > downstream bug trackers (plus his own) and wasting ton of time just
> > coordinating and communicating with them, or five bug reporters
> > (and
> > their package maintainers, if required) working with the upstream
> > in
>
On Wed, Sep 26, 2012 at 09:50:06AM +0200, Matej Cepl wrote:
> On 26/09/12 01:21, "Jóhann B. Guðmundsson" wrote:
> >If we send reporters upstream to read documents we can just as well send
> >them by the same method to upstream bugzilla's to file reports.
>
> Yes, I think it could be preferred way
On 26/09/12 01:21, "Jóhann B. Guðmundsson" wrote:
If we send reporters upstream to read documents we can just as well send
them by the same method to upstream bugzilla's to file reports.
Yes, I think it could be preferred way for some bugs and some components
(i.e., I would suggest much more a
On Tue, 2012-09-25 at 23:21 +, "Jóhann B. Guðmundsson" wrote:
> > I still don't think you've actually demonstrated any causal linkage
> > between these two things. Debugging instructions are debugging
> > instructions. Bug reports are bug reports. They are separate things. I
> > don't see how
On 09/25/2012 10:59 PM, Adam Williamson wrote:
On Tue, 2012-09-25 at 22:37 +, "Jóhann B. Guðmundsson" wrote:
On 09/25/2012 07:54 PM, Adam Williamson wrote:
I don't see that that follows logically at *all*. The two just seem like
totally different things. Instructions for debugging a given
On Tue, 2012-09-25 at 22:37 +, "Jóhann B. Guðmundsson" wrote:
> On 09/25/2012 07:54 PM, Adam Williamson wrote:
>
> > I don't see that that follows logically at *all*. The two just seem like
> > totally different things. Instructions for debugging a given component
> > are going to be the same
On 09/25/2012 07:54 PM, Adam Williamson wrote:
I don't see that that follows logically at*all*. The two just seem like
totally different things. Instructions for debugging a given component
are going to be the same whether you're running Fedora, Ubuntu, SUSE or
whatever: debugging systemd is debu
On Mon, 2012-09-24 at 20:31 +, "Jóhann B. Guðmundsson" wrote:
> On 09/24/2012 08:25 PM, Kevin Fenzi wrote:
> > On Mon, 24 Sep 2012 19:29:39 +
> > "Jóhann B. Guðmundsson" wrote:
> >
> >> A while back I started the initiative and writing how to debug pages
> >> for QA Community to use and wa
On 09/24/2012 08:59 PM, Kevin Fenzi wrote:
On Mon, 24 Sep 2012 20:31:41 +
"Jóhann B. Guðmundsson" wrote:
The general idea was to increase activity within the QA community and
improve reporting at the same time without having them running around
the whole internet while doings so.
Sure, bu
On Mon, 24 Sep 2012 20:31:41 +
"Jóhann B. Guðmundsson" wrote:
> The general idea was to increase activity within the QA community and
> improve reporting at the same time without having them running around
> the whole internet while doings so.
Sure, but duplicating upstream work seems not
On 09/24/2012 08:25 PM, Kevin Fenzi wrote:
On Mon, 24 Sep 2012 19:29:39 +
"Jóhann B. Guðmundsson" wrote:
A while back I started the initiative and writing how to debug pages
for QA Community to use and was about to write another when I noticed
when there has been put a big fat banner refer
On Mon, 24 Sep 2012 19:29:39 +
"Jóhann B. Guðmundsson" wrote:
> A while back I started the initiative and writing how to debug pages
> for QA Community to use and was about to write another when I noticed
> when there has been put a big fat banner referring to upstream wiki
> page on it.
>
>
25 matches
Mail list logo
