[haiku-development] Re: Request to work on newer buildtools integration (GCC/Binutils)
- From: Joseph Prostko <joe.prostko+haiku@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 2 Nov 2009 22:03:22 -0500
On Mon, Nov 2, 2009 at 1:41 PM, Niels Reedijk <niels.reedijk@xxxxxxxxx> wrote:
> First of all, the operations you are going to do require working with
> vendor branches, and also performing operations that bypass a working
> copy (and thus any optical checks beforehand). The fact that you do
> not have any experience in working with svn as committer discourages
> me to trust you to do well. And even if you work in a different
> branch, our repository is not a sandbox and any muddling about will be
> stored for the rest of time.
Yes, it's true I haven't used SVN in a committer role before. I was
at least honest and upfront about it. That said, I have a perfectly
good mirror of the whole repository sitting on a server on my network
waiting for me to utilize it for learning all I need to know about
Subversion. At the same time, I am pragmatic, and have no interest in
going through learning something if the whole idea of me getting
commit access is shot down. I don't like to learn something halfway
either, as I'm more of an all-or-nothing kind of person. In other
words, if I was granted access, my local repository would be my
sandbox, and I'd only work on the Haiku repository in logical steps
only after I knew what I was doing. And even if I had questions about
anything after all of that, I know enough of the devs in IRC well
enough that I could always pose a question to them if in doubt. That
and I have real-life friends that are quite familiar with SVN as well.
The branch itself was primarily suggested to keep things
clean/organized, not so I could use part of the repository as my
personal playground.
> Secondly, and you may correct me if I have the wrong impression. A
> quick mail history search shows you're around since 2006
I've been around since way before the name change even occurred, but
have used several email addresses over the years. I was also much
more of a lurker in the past. In other words, I have been reading the
lists and learning about Haiku for quite a long time. (I know this
fact in no way really enhances my qualifications, other than to state
that I am familiar with Haiku for quite some time.)
> - There has been past work which has been accepted into the tree (so
> by peer review).
As you've noticed, I have submitted a few tiny patches for various
things, none of them being substantial (at least according to size).
I don't really have goals for working on Haiku itself very much (as my
interest mostly lies with the buildtools for now). That is why I said
I wouldn't mind having limited permissions, as I wouldn't need full-on
access anyways.
> You satisfy the future plans condition perfectly, but I cannot judge
> the quality of any past work (and a few patches for GCC 4.x fixes do
> not compare to the work you intend to do).
I have some of the larger patches for GCC 4.4 here:
http://dev.haiku-os.org/ticket/4204
That said, a lot of that code is quite similar (or exactly the same)
as what exists for 4.3.3. I do have other patches locally to fix some
things a bit more properly, but figured any initial patching should
match what is currently in our repository as closely as possible for
familiarity reasons.
> This is by no means a judgement of your plans, which seem to be
> well-considered, or a rejection based on personal grounds, but I would
Don't worry, I didn't construe it as such, and am glad you took the
time to write what you did.
> rather see you work with one of the more experienced Haiku developers
> (preferably ones that know the buildtools) to work on these major
> changes. If at some point he says your work is of a good quality, then
> I will gladly change the vote.
Honestly, the main reason I am even making this request is because
after talking to mmlr and zooey personally about updating the
buildtools over the past months, they both kind of admitted that
neither one of them is really a maintainer of the buildtools, but they
were doing the work because nobody else was. It was also mentioned
that it would be nice if somebody else took over maintaining the
buildtools to free them up for taking care of other OS-specific
things. mmlr even asked if I was going to commit GCC 4.4 to the tree
in time for the first alpha, but naturally me not having commit access
at that time made that an impossibility.
So in other words, if somebody else really wanted to hold my hand in
doing this, I think the work have been already committed a long time
ago. I think the devs realize that having the latest/greatest GCC
isn't mission critical at the moment, so they would rather work on the
OS itself. Having somebody else with the time/motivation to work
primarily on the buildtools would be a welcome addition though, since
it would be nice to have that maintained in a current state without
the main devs having to worry about it.
I'm not really trying to counter-argue you into giving me your vote,
but did want to add some additional details there. The bottom line
being that I want to do the work that nobody else really has a strong
drive or the time to do. I know you fear I may bork or pollute the
repository, but frankly, that's the last thing on my agenda. Could it
happen? Sure, it's possible. Would my commit access be stripped as a
result? I would surely hope so. So yeah, I think the reward
outweighs the risk. I'm sure a lot of the devs feel the same way.
- joe
Other related posts:
