Difference between revisions of "DeveloperWiki:TheBigIdeaPage"

From ArchWiki
Jump to navigation Jump to search
(More packaging automation)
m (whitespace issue)
Line 2: Line 2:
  
 
This page is for generating a collection of ideas that would improve Arch Linux.  It will allow us to assess areas in which we can improve and whether we need more "staff" to move forward.
 
This page is for generating a collection of ideas that would improve Arch Linux.  It will allow us to assess areas in which we can improve and whether we need more "staff" to move forward.
 
  
 
==== Bugzilla ====
 
==== Bugzilla ====

Revision as of 12:22, 21 October 2014

The Big Idea Page

This page is for generating a collection of ideas that would improve Arch Linux. It will allow us to assess areas in which we can improve and whether we need more "staff" to move forward.

Bugzilla

Moving the bug tracker to Bugzilla would have many advantages (see also FS#24999):

  • It is more well maintained upstream than Flyspray
  • Bugs could be handled via email
  • ...

Florian has a script that will convert our bug database into Bugzilla format. Currently no-one is interested in maintaining the install.

Moving repository management to git

Using git instead of SVN is not really the primary goal, although it is a nice bonus. We also gain other stuff (split packages with different architectures, debug package repos, ...) Florian has made great advances in this realm. User:Bluewind/dbscripts-rewrite

Signing database files

Our package security would be improved by signing repository databases. This requires working with upstream GPG developers to allow signing of files over ssh.

Auto rebuild script

Simplfing package rebuilds.

rebuildpkg pkg1 pkg2 pkg3

More packaging automation

Not a very big idea but very much related to "auto rebuild script". Yet another wrapper or a full-blown "packaging shell", this time abstracting away the underlying independent build tools (svn, devtools, etc.), providing auto-completion of package names, committing to the correct repo, building on remote build server if wanted, rebuilding single packages or a package dependency list (with bumps and auto push to a staging or testing repo; there is no need to test successful rebuilds locally; also send e-mails to maintainers of failed builds), getting packages and signing them if built remotely, starting up a container or a VM with the newly built package and all dependencies to allow real, live testing (especially for graphical stuff). Will allow anyone to build, release and push depending on permissions to a repo (all users by default have permission to custom repos); this is defined in a file. Does packaging and does it well. Very distro-specific, will have zero compatibility with other pacman distros. Will look stupid at first. Will be useful in the long-run. Will become obsolete if systemd solves the whole Linux packaging problem.

Orphan packages

There are LOTS of these. Any common themes that would be worth recruiting a new packager for?

Datacenter software

Maintain software used in datacenters in the repo for easier installation? (ceph, puppet, nagios, ...)

Delta packages in repos

pacman already supports delta packages, but repo scripts don't generate the necessary delta files. See: Deltup; Feature request (now closed).

Encourage people to contribute to Arch projects

Github and the like encourage contributions by making the source obvious and easy to navigate. We currently lack this with Arch projects (and possibly packages). I think slapping our projects onto Github or an in-house Gitlab would increase contributions. The cgit + mailing list thing seems archaic nowadays where developers grow up with pull requests. Perhaps we should adapt where it makes sense? This might in fact alleviate some of our staff trouble as we allow others to more easily help us out.

Better namcap errors for version bumps

namcap should emit errors for packages when their updated version would break other apps due to soname bumps. Sadly, this can't work just by dependencies alone because our packages don't list all the dependencies directly. This is currently done on pkgbuild.com using sogrep and some manual note keeping which seems backward. sogrep is not readily available in devtools because it requires having a full mirror on the local drive. Since a full mirror is still less than 20 GiB, I don't believe this is a big problem and sogrep should be packaged in devtools to allow namcap to have some new features. Failing that, either a generated database for sonames should be generated by our tools (basically ldd over all dynamically linked objects) or an API for sogrep-like operations should be provided.

When such a tool is available, namcap could be improved to have this feature and henceforth version bumping would require less manual effort upfront and would be less error prone.