Date: Mon, 8 Mar 2010 03:09:41 +0100 From: Michal Varga <varga.michal@gmail.com> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: gnome@freebsd.org, Koop Mast <kwm@freebsd.org> Subject: Re: marcuscom and www/epiphany-extensions Message-ID: <3f1fd1ea1003071809i4ad35d6jf5e8cd500ac7ae02@mail.gmail.com> In-Reply-To: <1268011089.96436.22.camel@shumai.marcuscom.com> References: <3f1fd1ea1002250318o582bbd5ua5a695e3af5e3cb9@mail.gmail.com> <3f1fd1ea1002250713v29671732i57d89ad0f666d1b@mail.gmail.com> <1267112635.4439.27.camel@headache.rainbow-runner.nl> <3f1fd1ea1002250754i1b9f1096ma8d3b80b168f27f0@mail.gmail.com> <1267115639.4439.59.camel@headache.rainbow-runner.nl> <3f1fd1ea1002251321pddf7639g349b17f92db991ec@mail.gmail.com> <3f1fd1ea1003032019o59a92e3fhd3fdbd98b7479f0f@mail.gmail.com> <1267800450.91818.8.camel@headache.rainbow-runner.nl> <3f1fd1ea1003071706i6fde25fkc6a62632e19c9d9d@mail.gmail.com> <1268011089.96436.22.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 8, 2010 at 02:18, Joe Marcus Clarke <marcus@marcuscom.com> wrot= e: > We are spread thin, and we can always use help. =C2=A0The major work, tho= ugh, > is typically with the first-time port or first-time minor version bump > update. =C2=A0After 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. =C2=A0GNOME 2.29.92 is imminent, so if yo= u > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3f1fd1ea1003071809i4ad35d6jf5e8cd500ac7ae02>