Foresight 2.1.2 Release Roadmap

Goals

The primary goal of 2.1.2 is to do a 'wide repo cleanup' of user facing packages, which involves:

• Create a list of which user facing packages that we maintain and which of them we ship per default
• Remove dead packages (packages with no maintainer-ship and no upstream)
• Fix packages that currently do not work (or remove them)
• Finish incomplete packages
• Create and document scripts to extract info about recipe activity

Documents

Release Day HowTO
2.1.2 Release notes (draft)
Upgrade testing HOWTO

Issues to be fixed in 2.1.2

Note: please also check out https://issues.foresightlinux.org/browse/FL and edit 2.0x issues to 'Fix for 2.1.2' or 'Fix for 2.2' if they're not straightforward to check and resolve.

Sprints

Wide repo cleanup - sprint #2 - dangling troves

We need to get a picture of how many of the troves that currently live in fl:2-devel are not in any groups and, hence, will never be pulled into a normal fl:2 install unless specifically requested by the user from the fl:2-devel label:

1)$ conary rq --recurse group-world=@fl:2 | grep foo
 and
2)$ conary rq foo=fl:2-devel

if 1) is empty and 2) is non-empty, we have caught a dangling trove.

I'm sure some of you can come up with a creative way of semi-automating this!

Wide repo cleanup - sprint #1 for 2.1.2

Please populate the below table with user facing packages - add links as appropriate (to application home page, to recipe in r.b.o, to issues etc.)

Scripts to extract info about packages from the repo

As part of the cleanup, please create and add scripts to help with the process of figuring out which packages might need some love.

Mark__T? Doniphon?

We can use "conary rq --info |grep Name" for now

Mark__T has generated a list here, with the fields of Name,Builddate,Sourcefile,Last commit by.

What is a user facing package?

... and how are we choosing what user facing packages (applications?) we add to our distribution?

1. Usability - The application should be easy to use. (simplicty over complexity)
2. Stability - The application should not break.
3. Popularity - We add applications that are popular.

In #foresight, jesse suggested that we consider packages that directly faces the user (such as Rhythmbox and Totem) and then their dependencies (gstreamer, for instance): "it's like if we have a diagram where all packages are linked by dependencies, and we start picking from leaf nodes".

afranke suggested that http://oswatershed.org might cover our user facing packages.
zodman contact the admin of oswatershed. And give the info ( where xml cache of packagekit located) for add foresight.

11:43 < jesse> i still don't have much idea which package should go on the list
11:46 < bertux> there are very well known user facing apps
11:47 < jesse> conary q --labels here, http://sprunge.us/MDMB
11:48 < jesse> (sprunge is so handy
11:49 < jesse> http://sprunge.us/MDMB?sh, for line numbers
11:53 < jesse> not so easy to pick out 'user-facing' ones
11:53 < Mark__T> we could start with 'everything that has a gui'
11:54 < Mark__T> If it wouldn't be user facing at some point, it wouldn't need one
11:54 < afranke> Mark__T: I don't think user-facing means graphical here
11:55 < afranke> rather "that a foresight user will necessarily have on his desktop"
11:55 < afranke> for instance gstreamer
11:55 < afranke> not graphical but used by totem, banshee...
11:56 < afranke> the point is to define the core packages, the ones that need to be absolutely ok
                 for our users to have an enjoyable experience
11:56 < Mark__T> I didn't say we should stop there :-D
11:57 < afranke> Mark__T: yep but I'm sure there are gui apps that also don't belong to user-facing
                 because few people will use them
11:57 < afranke> so gui is definitely not a good "criterium" (what's the correct English word?)
11:58 < afranke> criteria?
11:59 < jesse> what about we first choose those that no one else depends, then pick their
               dependencies
12:00 < jesse> so in the first stage, we won't pick gstreamer, but in the second we do
12:01 < jesse> that should be easier to perform
12:11 < jesse> it's like if we have a diagram where all packages are linked by dependencies, and we
               start picking from leaf nodes
12:23 < Mark__T> awk is becoming my friend
12:23 < Mark__T> ... slowly
12:25 < bertux> jesse: i agree with your dependencies tracking
12:41 < afranke> hey guys, why not have a look at oswatershed to see what packages they consider?
12:47 < jesse> could oswatershed cover all or most of our user-facing packages?
12:52 < afranke> I don't know, we should investigate

What do we mean by 'maintainer?

Also in #foresight, pscott questioned the notion of having a 'maintainer' field and suggested that we find a different term. afranke pointed out that one of the reasons for having the field in the first place is to get an idea of who uses/packages/maintains/takes care of the packages currently, and who would be willing to do so in the future. Pscott's suggestion was: "find something that doesn't assert ownership of the package" or perhaps have a list of users for each package.

11:11 < jesse> how do we find out Maintainer? everybody volunteers or use the committer?
11:12 < jesse> Mark__T: are all entries available from conary rq ?
11:12 < afranke> jesse: for maintainer, we should start with volunteers
11:13 < jesse> agrees
11:14 < Mark__T> I can check
11:14 < pscott> I still prefer having a list of users to a maintainer
11:15  * jesse adds one entry
11:15 < Mark__T> pscott: I think we think of a maintainer as the guy who usually takes care of thae
                 package and might know how things are done
11:16 < jesse> how many packages do you expect to go to the list?
11:16 < afranke> and by the way, I'd rather have co-maintainers than one maintainer
11:16 < pscott> Mark__T: I know what a maintainer is :/
11:17 < Mark__T> pscott: well Some think of the maintainer as the guy who is in charge of a package
                 and noone else will ever touch it, because he would get really upset
11:18 < pscott> then maybe we shouldn't call it maintainer at all
11:18 < jesse> pscott: i agree
11:18 < pscott> find something that doesn't assert ownership of the package
11:19 < Mark__T> jesse: no idea, depends on how we define 'user facing'
11:19 < jesse> some hundred?
11:19 < pscott> here is how I look at it though
11:20 < pscott> which is harder now, finding the person who might be the caretaker of the package
                or finding someone that users it to confirm an issue
11:21 < jesse> or maybe we can omit the 'maintainer' field
11:21 < afranke> pscott: what about something like "referring developer"?
11:23 < afranke> jesse: as was discussed during the meeting, the point of this inventory is also to
                 find who would be the maintainers, so we shouldn't leave that out as it's one of
                 our goals