marcuscom and www/epiphany-extensions

Michal Varga varga.michal at gmail.com
Mon Mar 8 02:10:03 UTC 2010


On Mon, Mar 8, 2010 at 02:18, Joe Marcus Clarke <marcus at marcuscom.com> wrote:
> We are spread thin, and we can always use help.  The major work, though,
> is typically with the first-time port or first-time minor version bump
> update.  After that, the micro revs are typically trivial.
>
> But there are a lot of components to GNOME, and even bumping versions
> and distinfos can get tiresome.  GNOME 2.29.92 is imminent, so if you
> want to jump in, and help with the updates, you are more than welcome to
> do so.
>
> Joe
>
Yep, that's what I had in mind.

Are there any mechanisms in place to 'book' a particular set of
components that I'd plan to keep an eye on? To explain, there are two
particular issues that concern me.

First - I have, for example, no accessibility users (incl. myself), or
the whole tomboy/mono hilarity, or say, packagekit. While I probably
could blindly port the next release in queue, see if it builds, run
some plist checks, etc., I wouldn't be able to see if it actually
works, as in the best case scanario, I wouldn't have a clue about the
proper function of that component (so let's say, while I'm aware what
Orca is generally supposed to achieve, I have no idea about particular
details of a common accessibility users's setup and how he uses it. So
I might pretty much port a version that has "well, it seems to be able
to start" as the only working feature).

Second is the work duplication - obviously it doesn't to any good when
two people spent last few hours on a bunch of ports, then submit them
at about the same time, only to see that they both also duplicated
half of the work of each other (and I can only do that probably few
times a week, there are those usual "full time job / kids" issues). I
can imagine that especially first few days after a new Gnome release,
this would happen regularly without any "these ports are mine, don't
touch them" in place, so I presume there is something that deals with
it.

So that would be my question, how does one properly jump in without
running straight into those issues? I don't expect a badge and a
baseball cap, but I guess there is some kind of semi-internal memo
about proper work protocols that I should read before I start.

m.


More information about the freebsd-gnome mailing list