| Line 22: | Line 22: | ||
Only ''stable collections'' should be included in Fedora repositories. Let's say the stable are those used by other projects (Puppet). We don't plan to have dozens of Ruby&Rails collections in Fedora. "Unstable/Rawhide" collections might have some place, where they can live before being switched into "stable" - perhaps leveraging COPRs similar to PPAs. However, we don't wish to address this use case at this time. | Only ''stable collections'' should be included in Fedora repositories. Let's say the stable are those used by other projects (Puppet). We don't plan to have dozens of Ruby&Rails collections in Fedora. "Unstable/Rawhide" collections might have some place, where they can live before being switched into "stable" - perhaps leveraging COPRs similar to PPAs. However, we don't wish to address this use case at this time. | ||
Every collection will be presented as Change in new release of Fedora. FESCo would review it as standard feature. | |||
''Detailed Description'' - description of the collection, for which purpose was collection prepared. For example Ruby collection was done for Puppet, so no ABI changes, which would harm puppet. Also proposed life time must be mentioned here e.g. SCL will be supported at least two releases of Fedora. | |||
Naming of collections - prefix and name of collection is very important | Naming of collections - prefix and name of collection is very important. | ||
Life cycle - collection can live longer than 6 months. The life cycle doesn't have to be defined strictly, it will be based on needs of dependent projects. | Life cycle - collection can live longer than 6 months. The life cycle doesn't have to be defined strictly, it will be based on needs of dependent projects. | ||
Latest revision as of 07:12, 26 September 2013
DRAFT for Software Collection in Fedora
Working group: mmaslano, bkabrda, langdon (long time users, early adopters)
Reviewer of proposal (user side): msuchy (as previous member of project using collections)
Reviewer from FPC: toshio
Reason
In past we couldn't update some components as fast as we wanted because some packages would be broken. On the other hand, sometimes we did update to the latest version and broke various packages -- for example, Puppet. Fedora moves too fast for some developers, but Fedora should also give developers opportunity to stay longer on older/stable versions of their preferred languages by allowing Software Collections (scl).
Testing/Production
Software Collections (scl) have been already tested on various packages or sets of packages - gcc, ruby&rails, mysql/mariadb, eclipse and many more. Some projects like OpenShift or Foreman are already using scls for their development and for packaging of their projects.
Homepage of project and testing repositories: https://fedorahosted.org/SoftwareCollections/
Inclusion of collections in to Fedora
Fedora package reviews could be turned into SCL package reviews using the same process as is used for review of any "normal" new package. We might even be able to use the same ticket for review, only the tag would differ. All SCL packages would still have to adhere to Fedora Packaging Guidelines + there will be a special set of guidelines for SCL, draft is at https://fedoraproject.org/wiki/User:Bkabrda/SCLGuidelinesDraft. (Most of it should be already included in [docs] from Documentation team).
Reviews
Only stable collections should be included in Fedora repositories. Let's say the stable are those used by other projects (Puppet). We don't plan to have dozens of Ruby&Rails collections in Fedora. "Unstable/Rawhide" collections might have some place, where they can live before being switched into "stable" - perhaps leveraging COPRs similar to PPAs. However, we don't wish to address this use case at this time.
Every collection will be presented as Change in new release of Fedora. FESCo would review it as standard feature. Detailed Description - description of the collection, for which purpose was collection prepared. For example Ruby collection was done for Puppet, so no ABI changes, which would harm puppet. Also proposed life time must be mentioned here e.g. SCL will be supported at least two releases of Fedora.
Naming of collections - prefix and name of collection is very important.
Life cycle - collection can live longer than 6 months. The life cycle doesn't have to be defined strictly, it will be based on needs of dependent projects.
Example: OpenShift would like to stay on Ruby 1.9.3 & Rails 3.2.8, the collection will be maintained by Ruby & Rails collection maintainer as long as collection is needed. In case maintainer loses interest, it could be still maintained by projects using the collection. Orphaning of a collection must be announced on software-collection or fedora-devel list.
Packagers can use various tools for packaging collections.
Stable Collections
Stable collection should provide something needed for Fedora. Let's say:
- stable version of language used by many projects (ruby193, python2)
- set of packages based on collection
Obsoleting Collections
Maintainer must warn users on devel mailing list, (s)he doesn't plan to support collection X after release of Fedora-Y. If someone else was interested in maintenance, he could take ownership of such collection.
Technical details/Workflow
Workflow was already defined for projects already packaged as scl, but it must be also defined for Fedora https://fedoraproject.org/wiki/User:Mmaslano/SCL
Developers can prepare their collections in mock. Following changes are needed in Fedora infrastructure:
- buildroot - minimal buildroot must contain scl-utils-build and collection meta-package, which gives name and prefix to the collection .
- branch - add properly conditionalized macros into new branch based on branch with wanted version. Another possibility might be to have macros in rawhide branch, but it might be hard to do for some packages (Perl, Ruby, MySQL).
- build mechanism - fedpkg build should be able to build collection properly if a branch has defined buildroot with scl and meta-package.
- security tracking/handling should be done as for standard packages (packages will have their components in BZ, SRT will file bugs for them, too). We will have to keep the number of collections in Fedora reasonably low to have enough engineering resources.
Guidelines, Howtos
Documentation for users and packagers: http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/index.html
Workflow for packagers and relengs: https://fedoraproject.org/wiki/User:Mmaslano/SCL
SCL packaging guidelines draft: https://fedoraproject.org/wiki/User:Bkabrda/SCLGuidelinesDraft
Contacts
mailing list: softwarecollections@lists.fedorahosted.org