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:01 AM
Brian Pepple
 
Default Maintainer Responsibility Policy

Hi all,

I'm looking for some feedback on what I've got so far for the Maintainer
Responsibility Policy.

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

--

== Maintainer Responsibility Policy ==
=== How long to maintain? ===
13 months from initial release.

=== Belong to the appropriate low-traffic mailing list ===
* Package maintainers will receive important announcements through
the moderated fedora-devel-announce mailing list. Maintainers
will be automatically subscribed to this list. Everyone that is
a primary maintainer of a package in Fedora is also strongly
encouraged to subscribe to the fedora-devel list, though this is
not mandatory.
* http://www.redhat.com/mailman/listinfo/fedora-devel-announce
* http://www.redhat.com/mailman/listinfo/fedora-devel-list

=== Manage security issues ===
* Package maintainer should handle security issues quickly, and if
they need help they should contact the Security Response Team.
* http://fedoraproject.org/wiki/Security/ResponseTeam

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

=== 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.

=== Track dependency issues in a timely manner ===
* In the development tree, and to a small degree in the release
trees as well, updates to packages may cause other packages to
have broken dependencies. Maintainers will be alerted when this
happens, and should work to rebuild their packages with all due
haste. Broken dependencies may leave end user systems in a state
where no updates will be applied. In order to keep the
distribution in a reasonable state, someone will step in and
rebuild packages that have had dependency issues for some time,
but package maintainers should not rely on these rebuilds.

=== Notify others of changes that may affect their packages ===
* Some packages are depended upon by others; in this case, changes
to one package may cause issues for others. Maintainers should
be aware of the effects that changes to their packages may have,
and should alert to the fedora-devel-announce mailing list of
updates which contain ABI or API changes which may cause
dependency problems for other packages. The announcement should
occur a week before the packages update, so all maintainers
affected are notified. The announcement should include the
following information:
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
change.
* Expected date of the change.
* List of packages which are affected by the change.
Generally, this is merely the list of packages which
depend directly on the package which is being updated,
and can be found with "repoquery --whatrequires package"
where "package" is the package being updated.
* If your package upgrade breaks other packages in Rawhide, you
should try to help fix the packages affected. For example, when
Python-2.5 was integrated into Rawhide, Jeremy Katz at least
fixed the important packages and queued a rebuild for all the
other packages affected.

=== 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).
---

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:25 AM
Jesse Keating
 
Default Maintainer Responsibility Policy

On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote:
> == Maintainer Responsibility Policy ==
> === How long to maintain? ===
> 13 months from initial release.

From initial Fedora release right? If you bring a package in around F10
Beta, you're expected to stick around for 13 months after F10 final goes
out.

> === Belong to the appropriate low-traffic mailing list ===
> * Package maintainers will receive important announcements through
> the moderated fedora-devel-announce mailing list. Maintainers
> will be automatically subscribed to this list.

Do we have this hooked up now, or is that a future item (the
autosubscribing)


> Everyone that is
> a primary maintainer of a package in Fedora is also strongly
> encouraged to subscribe to the fedora-devel list, though this is
> not mandatory.
> * http://www.redhat.com/mailman/listinfo/fedora-devel-announce
> * http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
> === Manage security issues ===
> * Package maintainer should handle security issues quickly, and if
> they need help they should contact the Security Response Team.
> * http://fedoraproject.org/wiki/Security/ResponseTeam
>
> === Deal with reported bugs in a timely manner ====
> * 'Nuff said.

I would note here that putting a comment in the bug letting folks know
when you're going to be too busy to look at the bug immediately would
help.

> === 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.
>
> === Track dependency issues in a timely manner ===
> * In the development tree, and to a small degree in the release
> trees as well, updates to packages may cause other packages to
> have broken dependencies. Maintainers will be alerted when this
> happens, and should work to rebuild their packages with all due
> haste. Broken dependencies may leave end user systems in a state
> where no updates will be applied. In order to keep the
> distribution in a reasonable state, someone will step in and
> rebuild packages that have had dependency issues for some time,
> but package maintainers should not rely on these rebuilds.
>
> === Notify others of changes that may affect their packages ===
> * Some packages are depended upon by others; in this case, changes
> to one package may cause issues for others. Maintainers should
> be aware of the effects that changes to their packages may have,
> and should alert to the fedora-devel-announce mailing list of
> updates which contain ABI or API changes which may cause
> dependency problems for other packages. The announcement should
> occur a week before the packages update, so all maintainers
> affected are notified. The announcement should include the
> following information:
> * Nature of the change.
> * Branches (devel, F9, etc.) which will be affected by the
> change.
> * Expected date of the change.
> * List of packages which are affected by the change.
> Generally, this is merely the list of packages which
> depend directly on the package which is being updated,
> and can be found with "repoquery --whatrequires package"
> where "package" is the package being updated.

Shouldn't there be an --all there, as well as looking at what packages
BuildRequire yours?

> * If your package upgrade breaks other packages in Rawhide, you
> should try to help fix the packages affected. For example, when
> Python-2.5 was integrated into Rawhide, Jeremy Katz at least
> fixed the important packages and queued a rebuild for all the
> other packages affected.
>
> === 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).
--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 01:40 AM
Brian Pepple
 
Default Maintainer Responsibility Policy

On Mon, 2008-05-05 at 21:25 -0400, Jesse Keating wrote:
> On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote:
> > == Maintainer Responsibility Policy ==
> > === How long to maintain? ===
> > 13 months from initial release.
>
> From initial Fedora release right? If you bring a package in around F10
> Beta, you're expected to stick around for 13 months after F10 final goes
> out.

Correct. I'll clarify that.
>
> > === Belong to the appropriate low-traffic mailing list ===
> > * Package maintainers will receive important announcements through
> > the moderated fedora-devel-announce mailing list. Maintainers
> > will be automatically subscribed to this list.
>
> Do we have this hooked up now, or is that a future item (the
> autosubscribing)

I thought that was already hooked up, but I could be mistaken on that
point. Is anyone aware of the status of this?

> >
> > === Deal with reported bugs in a timely manner ====
> > * 'Nuff said.
>
> I would note here that putting a comment in the bug letting folks know
> when you're going to be too busy to look at the bug immediately would
> help.

Agreed. I'll add it.

> > === Notify others of changes that may affect their packages ===
> > * Some packages are depended upon by others; in this case, changes
> > to one package may cause issues for others. Maintainers should
> > be aware of the effects that changes to their packages may have,
> > and should alert to the fedora-devel-announce mailing list of
> > updates which contain ABI or API changes which may cause
> > dependency problems for other packages. The announcement should
> > occur a week before the packages update, so all maintainers
> > affected are notified. The announcement should include the
> > following information:
> > * Nature of the change.
> > * Branches (devel, F9, etc.) which will be affected by the
> > change.
> > * Expected date of the change.
> > * List of packages which are affected by the change.
> > Generally, this is merely the list of packages which
> > depend directly on the package which is being updated,
> > and can be found with "repoquery --whatrequires package"
> > where "package" is the package being updated.
>
> Shouldn't there be an --all there, as well as looking at what packages
> BuildRequire yours?

Yeah, I think your right.

Thanks for the feedback, Jesse.

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, 02:10 AM
Kevin Fenzi
 
Default Maintainer Responsibility Policy

On Mon, 05 May 2008 21:01:35 -0400
bpepple@fedoraproject.org (Brian Pepple) wrote:

> Hi all,
>
> I'm looking for some feedback on what I've got so far for the
> Maintainer Responsibility Policy.
>
> http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
>
> --
>
> == Maintainer Responsibility Policy ==
> === How long to maintain? ===
> 13 months from initial release.
>
> === Belong to the appropriate low-traffic mailing list ===
> * Package maintainers will receive important announcements
> through the moderated fedora-devel-announce mailing list. Maintainers
> will be automatically subscribed to this list. Everyone that
> is a primary maintainer of a package in Fedora is also strongly
> encouraged to subscribe to the fedora-devel list, though this
> is not mandatory.
> *
> http://www.redhat.com/mailman/listinfo/fedora-devel-announce
> *
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> === Manage security issues ===
> * Package maintainer should handle security issues quickly, and
> if they need help they should contact the Security Response Team.
> * http://fedoraproject.org/wiki/Security/ResponseTeam
>
> === Deal with reported bugs in a timely manner ====
> * 'Nuff said.

I think this needs expanding...

I would add:

"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".

> === 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.

> === Track dependency issues in a timely manner ===
> * In the development tree, and to a small degree in the release
> trees as well, updates to packages may cause other packages to
> have broken dependencies. Maintainers will be alerted when
> this happens, and should work to rebuild their packages with all due
> haste. Broken dependencies may leave end user systems in a
> state where no updates will be applied. In order to keep the
> distribution in a reasonable state, someone will step in and
> rebuild packages that have had dependency issues for some
> time, but package maintainers should not rely on these rebuilds.

Bodhi should prevent this in released branches now... so might need a
bit of re-wording.

> === Notify others of changes that may affect their packages ===
> * Some packages are depended upon by others; in this case,
> changes to one package may cause issues for others. Maintainers
> should be aware of the effects that changes to their packages may
> have, and should alert to the fedora-devel-announce mailing list of
> updates which contain ABI or API changes which may cause
> dependency problems for other packages. The announcement
> should occur a week before the packages update, so all maintainers
> affected are notified. The announcement should include the
> following information:
> * Nature of the change.
> * Branches (devel, F9, etc.) which will be affected by
> the change.
> * Expected date of the change.
> * List of packages which are affected by the change.
> Generally, this is merely the list of packages which
> depend directly on the package which is being updated,
> and can be found with "repoquery --whatrequires
> package" where "package" is the package being updated.
> * If your package upgrade breaks other packages in Rawhide, you
> should try to help fix the packages affected. For example,
> when Python-2.5 was integrated into Rawhide, Jeremy Katz at least
> fixed the important packages and queued a rebuild for all the
> other packages affected.

Might be worth mentioning the gcc and/or perl updates...
where they were done entirely in another tag and fixes were made until
the landing of the updates were pretty painless overall.

> === 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).

Looks like a good start...

> Thanks,

Thanks for looking at this.

> /B

kevin
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 02:22 AM
Brian Pepple
 
Default Maintainer Responsibility Policy

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:
> >
> > === Deal with reported bugs in a timely manner ====
> > * 'Nuff said.
>
> "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".

Added.

> > === 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.

> > === Track dependency issues in a timely manner ===
> > * In the development tree, and to a small degree in the release
> > trees as well, updates to packages may cause other packages to
> > have broken dependencies. Maintainers will be alerted when
> > this happens, and should work to rebuild their packages with all due
> > haste. Broken dependencies may leave end user systems in a
> > state where no updates will be applied. In order to keep the
> > distribution in a reasonable state, someone will step in and
> > rebuild packages that have had dependency issues for some
> > time, but package maintainers should not rely on these rebuilds.
>
> Bodhi should prevent this in released branches now... so might need a
> bit of re-wording.

Good suggestion. I changed that to refer to Rawhide only, since that
should be the only branch affected.

Thanks, Kevin!

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, 01:01 PM
Hans Ulrich Niedermann
 
Default Maintainer Responsibility Policy

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?


--
Hans Ulrich Niedermann

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 01:10 PM
"Xavier Lamien"
 
Default Maintainer Responsibility Policy

2008/5/6 Brian Pepple <bpepple@fedoraproject.org>:

Hi all,



I'm looking for some feedback on what I've got so far for the Maintainer

Responsibility Policy.



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



--



== Maintainer Responsibility Policy ==

=== How long to maintain? ===

13 months from initial release.



=== Belong to the appropriate low-traffic mailing list ===

* * ** Package maintainers will receive important announcements through

* * * *the moderated fedora-devel-announce mailing list. Maintainers

* * * *will be automatically subscribed to this list. Everyone that is

* * * *a primary maintainer of a package in Fedora is also strongly

* * * *encouraged to subscribe to the fedora-devel list, though this is

* * * *not mandatory.

* * * * * * ** http://www.redhat.com/mailman/listinfo/fedora-devel-announce

* * * * * * ** http://www.redhat.com/mailman/listinfo/fedora-devel-list



=== Manage security issues ===

* * ** Package maintainer should handle security issues quickly, and if

* * * *they need help they should contact the Security Response Team.

* * * * * * ** http://fedoraproject.org/wiki/Security/ResponseTeam



=== Deal with reported bugs in a timely manner ====

* * ** 'Nuff said.



=== 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.



=== Track dependency issues in a timely manner ===

* * ** In the development tree, and to a small degree in the release

* * * *trees as well, updates to packages may cause other packages to

* * * *have broken dependencies. Maintainers will be alerted when this

* * * *happens, and should work to rebuild their packages with all due

* * * *haste. Broken dependencies may leave end user systems in a state

* * * *where no updates will be applied. In order to keep the

* * * *distribution in a reasonable state, someone will step in and

* * * *rebuild packages that have had dependency issues for some time,

* * * *but package maintainers should not rely on these rebuilds.



=== Notify others of changes that may affect their packages ===

* * ** Some packages are depended upon by others; in this case, changes

* * * *to one package may cause issues for others. *Maintainers should

* * * *be aware of the effects that changes to their packages may have,

* * * *and should alert to the fedora-devel-announce mailing list of

* * * *updates which contain ABI or API changes which may cause

* * * *dependency problems for other packages. *The announcement should

* * * *occur a week before the packages update, so all maintainers

* * * *affected are notified. *The announcement should include the

* * * *following information:

* * * * * * ** Nature of the change.

* * * * * * ** Branches (devel, F9, etc.) which will be affected by the

* * * * * * * *change.

* * * * * * ** Expected date of the change.

* * * * * * ** List of packages which are affected by the change.

* * * * * * * *Generally, this is merely the list of packages which

* * * * * * * *depend directly on the package which is being updated,

* * * * * * * *and can be found with "repoquery --whatrequires package"

* * * * * * * *where "package" is the package being updated.

* * ** If your package upgrade breaks other packages in Rawhide, you

* * * *should try to help fix the packages affected. For example, when

* * * *Python-2.5 was integrated into Rawhide, Jeremy Katz at least

* * * *fixed the important packages and queued a rebuild for all the

* * * *other packages affected.



=== 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.





---



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


--
Xavier.t Lamien
--

http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
--
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 11:10 AM.

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