Re: [SFE-devel] Managing all those packages and maintainers

[Alfred P. <alf...@gm...>]

It's great that we talk about the packages/specs management and maintenance
and start to put this forward :-)

When I tried to build some of the SFE specs, one thing comes to my mind is
whether it's necessary to categorize all the specs, just like we did for
encumbered. Some of the specs don't work for me, with some build failure,
some are just too old and need to be update to the latest versions, some of
the patches aren't well maintained. From my perspective, I'd like to know
which set of specs are in good shape(with active maintainer to update the
spec, push the patches up-stream, or even better, only branding patches...),
which set are in limited maintenance(the specs work and someone might want
to stand up to make the patches up-stream), and which set are
badly maintained(the specs don't work in the latest several builds and
someone could take the ownership of that). That's to say, we can make them
into Tier-1, Tier-2... categories. To make this happen, a review mechanism
should be ready. I agree that the the current JDS code review policy could
be a good model to base on.

BTW, is there any plan to make the build package from source even easier? As
I know, one good thing about Debian is that it maintains the source
dependency so that contributors can build the binary from source easily
without bothering about the dependency issues.

Cheers,
-Alfred

On Sat, Jun 7, 2008 at 10:17 AM, Albert Lee
<tri...@ac...<trisk%2Bo...@ac...>>
wrote:

> Hi folks,
>
> I think something that is sorely lacking for SFE right now is a good
> interface for the processes for maintaining each package. Maintainers
> should be able to assign themselves as package owners and coordinate
> patches with upstream easily, and users should be able to file bugs
> against each package individually. The processes for bringing in new
> packages and new maintainers (for example if we adopt a "mentor" system)
> should also be encapsulated.
>
>
> I talked to an engineer for Canonical's Launchpad service, and it
> appears their system can support SFE as a "distro" and provides most of
> the front-end interfaces we'd need for package maintenance. One downside
> is that their backend is tied to Bazaar DSCM, which has gateways for svn
> and (read-only) hg.
>
>
> As far as the SCM goes, I don't think our Sourceforge.net setup is going
> to scale, in terms of representing the access policy for a large number
> of contributors (which should be managed with a higher level interface
> anyway). Subversion is probably also not ideal if we want a more
> distributed model.
>
>
> I'm also thinking about the maintainer policy (the "community process").
> The JDS code review policy looks like a reasonable basis, but it
> probably does not map 1:1 with our requirements. Some existing practices
> we might want to model on are Debian and FreeBSD Ports.
>
>
> -Albert
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _________________________________________________________________
> SFE-devel mailing list - Pkg...@li...
> http://pkgbuild.wiki.sourceforge.net/SFE
> https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
>