FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Advisory Board

 
 
LinkBack Thread Tools
 
Old 01-09-2008, 07:51 AM
Thorsten Leemhuis
 
Default closing out old bugs of unmaintained releases

On 09.01.2008 09:32, Christian Iseli wrote:
>> We have a lot of non-hackers that maintain packages in Fedora and it
>> worked well so far and that in parts made Fedora what it is today.
>> What IMHO would be good instead of what you outline: groups of people
>> (SIGs) a package-monkey can contact if he needs help to fix or improve
>> something needs programming skills.
> What I'd like to see is:
> - emergence of a group of able programmers willing to help squashing
> bugs in other maintainers' packages, and an easy way to alert this
> group of people to a list of bugs to squash
> - education of the non-programmers packagers that they can and *should*
> seek help from the above group when needed, and how to go about this
> process

That's what I meant in better words

CU
knurd

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-09-2008, 08:09 AM
Thorsten Leemhuis
 
Default closing out old bugs of unmaintained releases

On 09.01.2008 09:39, Michael Schwendt wrote:
> On Wed, 09 Jan 2008 07:16:22 +0100, Thorsten Leemhuis wrote:
>> On 08.01.2008 22:53, David Woodhouse wrote:
>>> Perhaps one option would be for non-programmer packagers to team up with
>>> a programmer/sponsor to take on the task of package maintenance?
>> Don't put more bureaucracy or hurdles in the way. That won't scale and
>> will frustrate people and some will feel a second-class citizen
> Not just that, it is completely unrealistic to hope that there would be
> enough volunteers to fill the "programmer/sponsor" role. [...]

+1

>> What
>> IMHO would be good instead of what you outline: groups of people (SIGs)
>> a package-monkey can contact if he needs help to fix or improve
>> something needs programming skills.
> Is it necessary to increase complexity of the Fedora Project's structure
> by adding lots of small SIGs like that? The Wiki pages are really
> troublesome already because it has become increasingly difficult to
> navigate in them and find what you are looking for. Additionally, there's
> still the problem of over-complex page layout, such as pseudo-menus that
> use tables and include files. I'd rather suggest that packagers request
> assistance on fedora-devel-list or via some keyword/feature in bugzilla.

Hmmm. SIGs for me are not part of "Fedora Project's structure" -- they
are just a loose group of people that simply do something without formal
structure (they can have one if they want of course). Sure, most SIGs
have a page in the Wiki for advertising and tracking, but there is iirc
no rule "SIGs must have a page in the wiki".

CU
knurd

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-09-2008, 09:20 AM
Michael Schwendt
 
Default closing out old bugs of unmaintained releases

On Wed, 09 Jan 2008 10:09:27 +0100, Thorsten Leemhuis wrote:

> Hmmm. SIGs for me are not part of "Fedora Project's structure" -- they
> are just a loose group of people that simply do something without formal
> structure (they can have one if they want of course). Sure, most SIGs
> have a page in the Wiki for advertising and tracking, but there is iirc
> no rule "SIGs must have a page in the wiki".

Okay, probably using plural {"groups of people (SIGs)"} was misleading
then. I just would prefer to see the procedure (i.e. the HOW TO request
help) documented somewhere instead of an inflation of SIGs. First see the
demand (i.e. the number of requests for help with technical issues), then
find out how the possibly small bug-fixing squad manages to deal with the
load. It could likely happen that they will be flooded with a growing
queue of bugzilla tickets.

And, of course, upstream should not be forgotten in the process.
Especially not when uptream is not Fedora-hostile (and not biased), but
active, confirms problems, and works on a fix instead of reacting with a
shrug of the shoulders.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-09-2008, 10:05 AM
David Woodhouse
 
Default closing out old bugs of unmaintained releases

On Wed, 2008-01-09 at 07:16 +0100, Thorsten Leemhuis wrote:
> Don't put more bureaucracy or hurdles in the way.

That's a sensible request.

> That won't scale and
> will frustrate people and some will feel a second-class citizen (I
> already feel unwanted more and more in Fedora-land after this discussion
> because I never found time to learn proper programming -- mostly due to
> fact that most of my free time is already filled with Fedora-related work).

I'm sorry you feel that way, and I believe that you shouldn't. They are
two entirely separate skill sets, and it doesn't necessarily follow that
a non-programmer packager should be 'training' to become a programmer,
or vice versa.

You are very good at packaging software, and not a programmer. There's
no shame in that. I am... well, I manage to scrape a living by
programming, but I suck at packaging things because I don't have the
attention-span for it. I don't feel particularly shameful about that
either.

Shipping software and supporting it requires input from both of us. I'd
like us to have a sensible discussion about how we handle that
requirement, without anyone feeling unwanted.

> We have a lot of non-hackers that maintain packages in Fedora and it
> worked well so far and that in parts made Fedora what it is today. What
> IMHO would be good instead of what you outline: groups of people (SIGs)
> a package-monkey can contact if he needs help to fix or improve
> something needs programming skills.

Fundamentally, that's fairly much what I was saying. Christian phrases
it slightly better, mostly IMHO because he stresses "can and *should*".
But I think we are fairly much in agreement about what we'd like to
happen in principle; we're just not sure on the details of how to
achieve it.

I'll follow up to a different mail on that topic...

--
dwmw2

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-09-2008, 10:22 AM
David Woodhouse
 
Default closing out old bugs of unmaintained releases

On Wed, 2008-01-09 at 09:51 +0100, Thorsten Leemhuis wrote:
> On 09.01.2008 09:32, Christian Iseli wrote:
> >> We have a lot of non-hackers that maintain packages in Fedora and it
> >> worked well so far and that in parts made Fedora what it is today.
> >> What IMHO would be good instead of what you outline: groups of people
> >> (SIGs) a package-monkey can contact if he needs help to fix or improve
> >> something needs programming skills.
> > What I'd like to see is:
> > - emergence of a group of able programmers willing to help squashing
> > bugs in other maintainers' packages, and an easy way to alert this
> > group of people to a list of bugs to squash
> > - education of the non-programmers packagers that they can and *should*
> > seek help from the above group when needed, and how to go about this
> > process
>
> That's what I meant in better words

So do we have a nebulous group of 'programmers with free time' and call
upon them as an when they're needed, or do we have a programmer sign up
to 'own' a package in conjunction with the 'packager'?

I favour the latter, for much the same reason as we have specific
package owners in the first place rather than a free-for-all¹:

- it sets the _expectation_ that this is the person who will step up
when action is necessary (although we aren't going to turn up on
your doorstep and promote an attitude of violence if you don't).

- it gives some primitive level of workload control. If the programmer
is and unable to keep up with the packages he/she has signed up to
work on, he/she can stop taking on new packages and/or try to find
others to take over some of them.

- it would give the non-programmer packager a first point of contact
when he/she needs help, rather than a general appeal to a mailing
list where nobody feels 'ownership' of the problem at hand.

- it gives the programmer 'community' the opportunity to throw their
hands up in horror and say "No! This code is a steaming pile of crap
and should not ever be shipped with the Fedora name on it", rather
than being stuck with supporting it after the fact.

I think that as part of the review process, a non-programmer packager
should identify a programmer who has agreed to help look after the
package. This might often be the packager's sponsor, or it could be the
owner of the upstream code (some are more helpful than others), or it
could be someone else who believes themselves capable of working on the
code to the extent that it's likely to be necessary.

But they should be identified in advance, rather than letting packagers
just add arbitrary packages to the pool and expecting a 'programmer SIG'
to cope with whatever's thrown at them. Or letting packagers add
packages to the pool and then refuse to support them, which is sometimes
happening at the moment.

--
dwmw2

¹ Although I do feel that the old Red Hat internal process benefited a
lot by being a bit _more_ of a free-for-all than we have in Fedora.
Fedora seems to have largely lost the teamwork mentality. But that's
a separate issue.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-09-2008, 11:14 AM
Christopher Aillon
 
Default closing out old bugs of unmaintained releases

On 01/09/2008 12:22 PM, David Woodhouse wrote:

So do we have a nebulous group of 'programmers with free time' and call
upon them as an when they're needed, or do we have a programmer sign up
to 'own' a package in conjunction with the 'packager'?

I favour the latter, for much the same reason as we have specific
package owners in the first place rather than a free-for-all¹:


Why not both? This way the not as popular packages may have a chance of
getting fixes from someone when needed.


_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-09-2008, 11:47 AM
David Woodhouse
 
Default closing out old bugs of unmaintained releases

On Wed, 2008-01-09 at 13:14 +0100, Christopher Aillon wrote:
> On 01/09/2008 12:22 PM, David Woodhouse wrote:
> > So do we have a nebulous group of 'programmers with free time' and call
> > upon them as an when they're needed, or do we have a programmer sign up
> > to 'own' a package in conjunction with the 'packager'?
> >
> > I favour the latter, for much the same reason as we have specific
> > package owners in the first place rather than a free-for-all¹:
>
> Why not both? This way the not as popular packages may have a chance of
> getting fixes from someone when needed.

Absolutely, but then we really are digressing into the "WTF happened to
teamwork" discussion.

I think there should be a programmer who signs up to be responsible for
each package. As a separate issue, I think that ACLs should be abolished
and anyone who _wants_ to help (and has executed the CLA and is trusted
enough to have been sponsored and given an account) should be
_permitted_ to help.

I was trying to avoid conflating the two -- there is merit in having
named individuals who are listed as having taken responsibility for
certain things, as well as _allowing_ people to help out wherever they
like in a more informal fashion. It's not strictly an either-or choice.

--
dwmw2

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-09-2008, 11:58 AM
Ralf Corsepius
 
Default closing out old bugs of unmaintained releases

On Wed, 2008-01-09 at 09:39 +0100, Michael Schwendt wrote:
> On Wed, 09 Jan 2008 07:16:22 +0100, Thorsten Leemhuis wrote:
>
> > On 08.01.2008 22:53, David Woodhouse wrote:
> > > Perhaps one option would be for non-programmer packagers to team up with
> > > a programmer/sponsor to take on the task of package maintenance?
> >
> > Don't put more bureaucracy or hurdles in the way. That won't scale and
> > will frustrate people and some will feel a second-class citizen
>
> Not just that, it is completely unrealistic to hope that there would be
> enough volunteers to fill the "programmer/sponsor" role.
That's true, but my answer is different than yours: I feel the current
sponsorship/tutor/mentor model is dead, because the infrastructure and
the packaging workflow are not in a shape suitable for such a model to
work out and because some "maintainers" are unwilling to team up.

> > What
> > IMHO would be good instead of what you outline: groups of people (SIGs)
> > a package-monkey can contact if he needs help to fix or improve
> > something needs programming skills.
>
> Is it necessary to increase complexity of the Fedora Project's structure
> by adding lots of small SIGs like that?
Why not? They collect people with common interests. IMO, a good thing.

But, as the perl-sig issue (JPO AWOL) in late last year demonstrated,
the real issue which is preventing such groups from working out on
collaborating on package maintenance, is Fedora's infrastructure
(esp. ACLs).

Ralf


_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 09:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org