[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for 2008-10-29]



Le mardi 04 novembre 2008 à 14:52 -0500, Bill Nottingham a écrit :
> Nicolas Mailhot (nicolas mailhot laposte net) said: 
> > 2. this stuff can change during the (sub)package life, bugzilla only has
> > the initial state (and not even all the packages, early packages are not
> > in there)
> 
> Then do packagedb, and it's even a per-release flag. Realistically, if
> someone isn't editing comps when they split things into subpackages, I
> don't know that having to have a defined person always going through
> and cleaning up after them is better.

The aim is not to have a defined person going there and cleaning up
after people (quick burn-out receipe).

The aim is to have regular automated checks and packager nagmail if
their package is not listed in comps at all. Just like we already do for
lots of other stuff (packages approved but not built, dependency
breakage, etc)

> > 3. that pushes more logic infra-side, which is not nice for third
> > parties (and we want third parties to be comfortable creating their own
> > private additions to Fedora)
> 
> ???? If they're doing their own repo, they already are doing any
> infrastructure work themselves in their own file. However we verify
> ours doesn't really matter.

If we move validation then generation packagedb side it certainly does.

> > The KISS solution is to just add everything in comps and run basic
> > scripts that check every package we ship appears there (say in a
> > dev-null group for libs or such stuff). You can easily cull the dev-null
> > group at comps.xml.in -> comps.xml stage if needed.
> > 
> > Granted, just because a package appears in comps does not mean it
> > appears in the right place, but usually packagers that make the effort
> > to edit comps try to do it properly.
> 
> This doesn't actually help you get *useful* comps, as the first step
> would be 'add all packages not listed to the devnull group', 

The first step would be "for release foo (I guess 11), please *think*
where your packages should appear in comps, and put them here (including
in the dev-null group if that's the best choice), if you don't want to
get nagmails and appear in the daily breakage status report"

> repeated
> weekly. Which doesn't actually help you with respect to missing packages.

That does not help you only if you forget weekly which packages you've
decided should not be exposed to users in comps. Which is exactly what
happens if you refuse to list them somewhere.

If you do have a packager-provided list of packages to exclude, and
scripts that check it regularly, you have a nicely converging system
that does not require one poor person doing all the tedious work alone
manually.

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]