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 Development

 
 
LinkBack Thread Tools
 
Old 05-06-2008, 01:44 PM
Brian Pepple
 
Default Maintainer Responsibility Policy

On Tue, 2008-05-06 at 15:10 +0200, Xavier Lamien wrote:
> 2008/5/6 Brian Pepple <bpepple@fedoraproject.org>:
>
> === Miscellaneous Items ===
> * Maintainers need to maintain an upgrade path for their
> packages.
> * F(current-1) -> F(current) -> Rawhide
> * Packages should be pushed to the Rawhide branch first.
> If it
> builds and works fine for a few days, then it can be
> pushed to
> F(current). If there is a good reason to push it to
> F(current-1), it should be done after a few days of
> being in
> F(current).
>
> I think you should also mention the act of "pushing to testing" repo
> for each current fedora release.

Yeah, that's not a bad idea. I believe when that section was written,
Bodhi wasn't even around (which tells you how long this proposal has
been around). I'll add a note.

Thanks,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 01:58 PM
Dmitry Butskoy
 
Default Maintainer Responsibility Policy

Brian Pepple wrote:

On Tue, 2008-05-06 at 15:10 +0200, Xavier Lamien wrote:


* Packages should be pushed to the Rawhide branch first.
If it
builds and works fine for a few days, then it can be
pushed to
F(current). If there is a good reason to push it to
F(current-1), it should be done after a few days of
being in
F(current).

I think you should also mention the act of "pushing to testing" repo
for each current fedora release.



Yeah, that's not a bad idea. I believe when that section was written,
Bodhi wasn't even around (which tells you how long this proposal has
been around). I'll add a note.



A restriction of "few days" might complicate the maintainer work. It is
much more easy to compile for all the branches at one time, rather than
to plan it for 3 different days. IMO it would be better if such a
delaying will be performed automatically at "updates-testing-->updates"
stage...



~buc
http://www.fedoraproject.org/wiki/DmitryButskoy

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 02:26 PM
Toshio Kuratomi
 
Default Maintainer Responsibility Policy

Hans Ulrich Niedermann wrote:

Brian Pepple wrote:


=== Deal with reported bugs in a timely manner ====
* 'Nuff said.


"Deal with" meaning what, exactly? When the maintainer has reported the
bug to upstream in a timely manner, his job is done and he can patiently
wait for years until upstream fixes the bug or not?



A little more than that:

1) Someone who can work on the bug should know about it.
- If the package maintainer is capable and willing, they can be
working on fixing it.
- If not, the package maintainer should have tried at least some of
the following options:

* reported it upstream.
* asked for help on fedora-devel (there are people who volunteer
their time to work on code/autotools problems that other package
maintainers have)
* checked if other distributions have patches for the problem
already (google often finds patches in Debian, for instance.)


2) Let the bug reporter know what's going on with the bug report. If
that happens to be that they reported it upstream and upstream has
proven disinterested in fixing it, having an upstream bug#, etc is very
useful. Then the bug reporter can try to get upstream to fix the bug
themselves.


Brian, we probably want to list the ways to deal with bug reports in the
policy as many maintainers don't realize how many options there are for
getting help fixing a bug.



-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 03:54 PM
Brian Pepple
 
Default Maintainer Responsibility Policy

On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote:
<snip>
> Brian, we probably want to list the ways to deal with bug reports in the
> policy as many maintainers don't realize how many options there are for
> getting help fixing a bug.

Here's what I've got right now (from Kevin's suggestion) in the section
regarding bugs:

"If you find yourself unable to handle the load of bugs from your
package(s), please ask for assistance on the fedora-devel and/or
fedora-test lists. Teaching triagers about how to triage your bugs or
getting help from other maintainers can not only reduce your load, but
improve Fedora. Consider reaching out for some (more) co-maintainers to
assist as well."

Do we want to expand on that?

Later,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 04:12 PM
Toshio Kuratomi
 
Default Maintainer Responsibility Policy

Brian Pepple wrote:

On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote:
<snip>
Brian, we probably want to list the ways to deal with bug reports in the
policy as many maintainers don't realize how many options there are for
getting help fixing a bug.


Here's what I've got right now (from Kevin's suggestion) in the section
regarding bugs:

"If you find yourself unable to handle the load of bugs from your
package(s), please ask for assistance on the fedora-devel and/or
fedora-test lists. Teaching triagers about how to triage your bugs or
getting help from other maintainers can not only reduce your load, but
improve Fedora. Consider reaching out for some (more) co-maintainers to
assist as well."


Yeah. I think it's worthwhile to mention something like this:

"Even bugs that you aren't capable of fixing yourself because they deal
with intricacies of the source code that you don't have the knowledge to
fix deserve a few moments of your time. You can report the bug upstream
for the user, ask for help from more code-oriented people on
fedora-devel, or check whether other distros have patches for the
problem. Always be sure to post to the bug report what you have done so
that the reporter has a proper expectation of whether you're working on
a fix or if it's something that has to wait on upstream action."


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 04:25 PM
Brian Pepple
 
Default Maintainer Responsibility Policy

On Tue, 2008-05-06 at 09:12 -0700, Toshio Kuratomi wrote:
> Yeah. I think it's worthwhile to mention something like this:
>
> "Even bugs that you aren't capable of fixing yourself because they deal
> with intricacies of the source code that you don't have the knowledge to
> fix deserve a few moments of your time. You can report the bug upstream
> for the user, ask for help from more code-oriented people on
> fedora-devel, or check whether other distros have patches for the
> problem. Always be sure to post to the bug report what you have done so
> that the reporter has a proper expectation of whether you're working on
> a fix or if it's something that has to wait on upstream action."

Added. Thanks for the suggestion, Toshio.

Later,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 07:27 PM
Nicolas Mailhot
 
Default Maintainer Responsibility Policy

Le lundi 05 mai 2008 ŕ 22:22 -0400, Brian Pepple a écrit :
> On Mon, 2008-05-05 at 20:10 -0600, Kevin Fenzi wrote:
> > On Mon, 05 May 2008 21:01:35 -0400
> > bpepple@fedoraproject.org (Brian Pepple) wrote:
>
> > > === Maintain stability for users ===
> > > * Package maintainers should limit updates within a single
> > > Fedora release to those which do not require special user action. Many
> > > users update automatically, and if their applications stop
> > > working from no action of their own then they will be upset.
> > > This goes doubly for services which may break overnight.
> >
> > I would add additionally:
> >
> > "Maintainers should not push every single upstream update to all
> > branches. Examine the changes in each upstream release and ask if the
> > update is worth download and update time for many users. For upstreams
> > that update very often with many small updates, consider waiting and
> > updated only when the amount of changes is worth updating.
>
> Added.

***Except for fedora devel***

Maintainers that only update devel a few days before the freeze and
ignore intermediary versions (where problems in the package or in its
interaction with others could be identified and reported upstream) are
as time-wasting as maintainers who push everything everywhere.

Fedora devel has a limited number of users (except just before a
release). That does not mean ignoring it is ok for a maintainer.

--
Nicolas Mailhot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-07-2008, 07:59 AM
Alex Lancaster
 
Default Maintainer Responsibility Policy

>>>>> "BP" == Brian Pepple writes:

BP> Hi all, I'm looking for some feedback on what I've got so far for
BP> the Maintainer Responsibility Policy.

BP> http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy

As Extras is defunct, all the wiki pages under the namespace:
Extras/Schedule

should probably be moved under the new namespace: Development/Schedule

I made a start by moving:

http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy

to:

http://fedoraproject.org/wiki/Development/Schedule/MaintainerResponsibilityPolicy

I think I got all the places that also linked to it (I also created a
redirect so that people who only have the old URL from previous
messages will be redirected to it fine). Let me know if not.

Alex

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-07-2008, 10:07 AM
David Woodhouse
 
Default Maintainer Responsibility Policy

On Tue, 2008-05-06 at 09:12 -0700, Toshio Kuratomi wrote:
> Yeah. I think it's worthwhile to mention something like this:
>
> "Even bugs that you aren't capable of fixing yourself because they deal
> with intricacies of the source code that you don't have the knowledge to
> fix deserve a few moments of your time. You can report the bug upstream
> for the user, ask for help from more code-oriented people on
> fedora-devel, or check whether other distros have patches for the
> problem. Always be sure to post to the bug report what you have done so
> that the reporter has a proper expectation of whether you're working on
> a fix or if it's something that has to wait on upstream action."

I'm not sure that's strong enough. It should clearly state that the
package maintainer is responsible for getting bugs fixed -- if the
package maintainer isn't a coder, then they need to take a more
managerial röle; working with upstream or with code-monkeys within
Fedora to get things fixed. How about this:

If there are bugs which you aren't capable of fixing yourself because
they deal with intricacies of the source code which you don't fully
understand, then you still need to address these bugs. It can be helpful
to work with the upstream maintainer of the code, obtain help from more
code-oriented people on fedora-devel, or check other distributions for
patches. Always be sure to post to the bug report what you have done so
that the reporter knows what it happening and what to expect.
It is recommended that non-coder packagers should find co-maintainers
who are familiar with the programming language used by their package(s),
and can help with such bugs as a kind of 'second line support'.

--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-07-2008, 02:30 PM
Brian Pepple
 
Default Maintainer Responsibility Policy

On Wed, 2008-05-07 at 11:07 +0100, David Woodhouse wrote:
> I'm not sure that's strong enough. It should clearly state that the
> package maintainer is responsible for getting bugs fixed -- if the
> package maintainer isn't a coder, then they need to take a more
> managerial röle; working with upstream or with code-monkeys within
> Fedora to get things fixed. How about this:
>
> If there are bugs which you aren't capable of fixing yourself because
> they deal with intricacies of the source code which you don't fully
> understand, then you still need to address these bugs. It can be helpful
> to work with the upstream maintainer of the code, obtain help from more
> code-oriented people on fedora-devel, or check other distributions for
> patches. Always be sure to post to the bug report what you have done so
> that the reporter knows what it happening and what to expect.
> It is recommended that non-coder packagers should find co-maintainers
> who are familiar with the programming language used by their package(s),
> and can help with such bugs as a kind of 'second line support'.

Added your suggestion.

Thanks,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:44 PM.

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