You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Om <bi...@gmail.com> on 2013/04/04 19:44:25 UTC
Re: [DISCUSS] How do we want to handle Whiteboard?
Any more thoughts on how to manage the whiteboard repo? If its okay with
everyone, I will go ahead and start a VOTE thread soon.
Personally, I like the option of working on GitHub for the whiteboard. In
a way it levels the playing field of committer vs. non-committer. This
could foster more community involvement. Going back to my first days of
contributing to Apache Flex, I did all my Installer related work on GitHub
and just posted the link on the dev forum here. After a lot of discussion,
Justin (who was a committer by then) and a couple of non-committers forked
my project and started sending me Pull requests. This gave me a more
flexibility in how I contributed as a non-committer. The fork that Justin
did on GitHub can be considered as a whiteboard area, except that it let
him foster community participation (like me and the other non-committers)
And of course, working with GitHub is a breeze. Once you create your own
space, you can create unlimited projects and branches.
Thanks,
Om
On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui <ah...@adobe.com> wrote:
> The way I see it:
>
> #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work
> with
> a rich branching history retains that history when landing in the main
> repos.
> #1 Cons: 240MB initial download. It took several hours for some folks.
>
> #2 Pros: Not sure.
> #2 Cons: I think it would be hard to switch between branches when you have
> changes pending if you want to help out on someone else's whiteboard? Fred
> seemed to have other concerns.
>
> #3 Pros: Much easier to set up repos, I think.
> #3 Cons: Unclear about Apache approval. Have to be careful about who else
> contributes to your code.
>
> #4 Pros: Smaller initial download
> #4 Cons: Might be more work to transfer source from SVN to Git with
> history?
>
> For me, retaining history is way more important than waiting 2.5 hours once
> for the initial download.
>
>
> On 3/21/13 1:34 PM, "Om" <bi...@gmail.com> wrote:
>
> > Sorry, I have not been tracking the votes. Let me start up a new vote
> with
> > these options:
> >
> > ===================================
> > What to do with Whiteboard?
> >
> > 1. Use the sparse checkout option as described here (
> > http://markmail.org/message/dg7hplezkzwiroes)
> > 2. Create a branch per user in the whiteboard
> > 3. Move to github for whiteboards
> > 4. Let whiteboards remain in SVN
> >
> > ===================================
> >
> > If there are more options, please add it to the discussion here. I will
> > give some time for discussion before starting an official VOTE thread.
> >
> > Thanks,
> > Om
> >
> > On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS
> > <we...@hotmail.com>wrote:
> >
> >> Om,
> >>
> >> Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn),
> >> that's a lazy vote, I can change my mind ?
> >>
> >> -Fred
> >>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [DISCUSS] How do we want to handle Whiteboard?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi,
I see another point, how to conserve the history of what has been done in
github, I mean, is there a way to apply a patch if the parent commit of the
patch hasn't got the same hash in the Apache whiteboard repo than the github
one ?
-Fred
-----Message d'origine-----
From: Greg Reddin
Sent: Thursday, April 04, 2013 8:59 PM
To: dev@flex.apache.org
Subject: Re: [DISCUSS] How do we want to handle Whiteboard?
On Thu, Apr 4, 2013 at 12:44 PM, Om <bi...@gmail.com> wrote:
> Personally, I like the option of working on GitHub for the whiteboard. In
> a way it levels the playing field of committer vs. non-committer. This
> could foster more community involvement.
I like the idea of using Github for all the reasons mentioned. But I
think there are three issues that need some discussion before we go forward
with it.
First, how will we ensure that we are developing software in community? If
everything is worked in our repo or submitted patches, then I can follow
the development by subscribing to the commits list. If it's at Github, then
I have to know about it and I have to subscribe to an external feed for
updates. So, for it to work in the Apache Way, the dev list needs to know
where and how to watch it or contribute to it. This seems doable, but it's
not automatic. One thing we want to avoid is one or more people working on
something externally for a long period of time, then bringing it to the
project as a large chunk.
The second issue is ensuring provenance. If a committer commits something
or a contributor submits a patch in Jira we know where it came from and who
contributed it. Does a Github whiteboard give us the same traceability of
contributions? Granted, it's possible for someone to contribute something
they don't have rights to even in the current model, but would we still
have the traceability at Github?
Thirdly, how will we identify folks who should be nominated as committers?
We'd need to know all the places at Github to keep track of and we'd need a
way to be made aware of someone's contributions.
Again, I think these are doable, but I think we need to consider how and
what.
Greg
Re: [DISCUSS] How do we want to handle Whiteboard?
Posted by Greg Reddin <gr...@gmail.com>.
On Thu, Apr 4, 2013 at 12:44 PM, Om <bi...@gmail.com> wrote:
> Personally, I like the option of working on GitHub for the whiteboard. In
> a way it levels the playing field of committer vs. non-committer. This
> could foster more community involvement.
I like the idea of using Github for all the reasons mentioned. But I
think there are three issues that need some discussion before we go forward
with it.
First, how will we ensure that we are developing software in community? If
everything is worked in our repo or submitted patches, then I can follow
the development by subscribing to the commits list. If it's at Github, then
I have to know about it and I have to subscribe to an external feed for
updates. So, for it to work in the Apache Way, the dev list needs to know
where and how to watch it or contribute to it. This seems doable, but it's
not automatic. One thing we want to avoid is one or more people working on
something externally for a long period of time, then bringing it to the
project as a large chunk.
The second issue is ensuring provenance. If a committer commits something
or a contributor submits a patch in Jira we know where it came from and who
contributed it. Does a Github whiteboard give us the same traceability of
contributions? Granted, it's possible for someone to contribute something
they don't have rights to even in the current model, but would we still
have the traceability at Github?
Thirdly, how will we identify folks who should be nominated as committers?
We'd need to know all the places at Github to keep track of and we'd need a
way to be made aware of someone's contributions.
Again, I think these are doable, but I think we need to consider how and
what.
Greg
Re: [DISCUSS] How do we want to handle Whiteboard?
Posted by Jonathan Campos <jo...@gmail.com>.
On Thu, Apr 4, 2013 at 12:44 PM, Om <bi...@gmail.com> wrote:
> Personally, I like the option of working on GitHub for the whiteboard. In
> a way it levels the playing field of committer vs. non-committer.
>
I like the idea of the whiteboard being github based. Stops all the
discussion of what a non-committer can/cannot do.
--
Jonathan Campos
Re: [DISCUSS] How do we want to handle Whiteboard?
Posted by Om <bi...@gmail.com>.
On Thu, Apr 4, 2013 at 11:41 AM, Harbs <ha...@gmail.com> wrote:
> Github definitely simplifies things. Are there any advantages to keeping
> content on Apache's domain?
>
> Harbs
>
To be clear, we are talking only about moving the Whiteboard repo to
GitHub. There are no plans to move all the other repos to GitHub any time
soon.
Thanks,
Om
>
> On Apr 4, 2013, at 8:44 PM, Om wrote:
>
> > Any more thoughts on how to manage the whiteboard repo? If its okay with
> > everyone, I will go ahead and start a VOTE thread soon.
> >
> > Personally, I like the option of working on GitHub for the whiteboard.
> In
> > a way it levels the playing field of committer vs. non-committer. This
> > could foster more community involvement. Going back to my first days of
> > contributing to Apache Flex, I did all my Installer related work on
> GitHub
> > and just posted the link on the dev forum here. After a lot of
> discussion,
> > Justin (who was a committer by then) and a couple of non-committers
> forked
> > my project and started sending me Pull requests. This gave me a more
> > flexibility in how I contributed as a non-committer. The fork that
> Justin
> > did on GitHub can be considered as a whiteboard area, except that it let
> > him foster community participation (like me and the other non-committers)
> >
> > And of course, working with GitHub is a breeze. Once you create your own
> > space, you can create unlimited projects and branches.
> >
> > Thanks,
> > Om
> >
> > On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> The way I see it:
> >>
> >> #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work
> >> with
> >> a rich branching history retains that history when landing in the main
> >> repos.
> >> #1 Cons: 240MB initial download. It took several hours for some folks.
> >>
> >> #2 Pros: Not sure.
> >> #2 Cons: I think it would be hard to switch between branches when you
> have
> >> changes pending if you want to help out on someone else's whiteboard?
> Fred
> >> seemed to have other concerns.
> >>
> >> #3 Pros: Much easier to set up repos, I think.
> >> #3 Cons: Unclear about Apache approval. Have to be careful about who
> else
> >> contributes to your code.
> >>
> >> #4 Pros: Smaller initial download
> >> #4 Cons: Might be more work to transfer source from SVN to Git with
> >> history?
> >>
> >> For me, retaining history is way more important than waiting 2.5 hours
> once
> >> for the initial download.
> >>
> >>
> >> On 3/21/13 1:34 PM, "Om" <bi...@gmail.com> wrote:
> >>
> >>> Sorry, I have not been tracking the votes. Let me start up a new vote
> >> with
> >>> these options:
> >>>
> >>> ===================================
> >>> What to do with Whiteboard?
> >>>
> >>> 1. Use the sparse checkout option as described here (
> >>> http://markmail.org/message/dg7hplezkzwiroes)
> >>> 2. Create a branch per user in the whiteboard
> >>> 3. Move to github for whiteboards
> >>> 4. Let whiteboards remain in SVN
> >>>
> >>> ===================================
> >>>
> >>> If there are more options, please add it to the discussion here. I
> will
> >>> give some time for discussion before starting an official VOTE thread.
> >>>
> >>> Thanks,
> >>> Om
> >>>
> >>> On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS
> >>> <we...@hotmail.com>wrote:
> >>>
> >>>> Om,
> >>>>
> >>>> Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn),
> >>>> that's a lazy vote, I can change my mind ?
> >>>>
> >>>> -Fred
> >>>>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >>
>
>
Re: [DISCUSS] How do we want to handle Whiteboard?
Posted by Harbs <ha...@gmail.com>.
Github definitely simplifies things. Are there any advantages to keeping content on Apache's domain?
Harbs
On Apr 4, 2013, at 8:44 PM, Om wrote:
> Any more thoughts on how to manage the whiteboard repo? If its okay with
> everyone, I will go ahead and start a VOTE thread soon.
>
> Personally, I like the option of working on GitHub for the whiteboard. In
> a way it levels the playing field of committer vs. non-committer. This
> could foster more community involvement. Going back to my first days of
> contributing to Apache Flex, I did all my Installer related work on GitHub
> and just posted the link on the dev forum here. After a lot of discussion,
> Justin (who was a committer by then) and a couple of non-committers forked
> my project and started sending me Pull requests. This gave me a more
> flexibility in how I contributed as a non-committer. The fork that Justin
> did on GitHub can be considered as a whiteboard area, except that it let
> him foster community participation (like me and the other non-committers)
>
> And of course, working with GitHub is a breeze. Once you create your own
> space, you can create unlimited projects and branches.
>
> Thanks,
> Om
>
> On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> The way I see it:
>>
>> #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work
>> with
>> a rich branching history retains that history when landing in the main
>> repos.
>> #1 Cons: 240MB initial download. It took several hours for some folks.
>>
>> #2 Pros: Not sure.
>> #2 Cons: I think it would be hard to switch between branches when you have
>> changes pending if you want to help out on someone else's whiteboard? Fred
>> seemed to have other concerns.
>>
>> #3 Pros: Much easier to set up repos, I think.
>> #3 Cons: Unclear about Apache approval. Have to be careful about who else
>> contributes to your code.
>>
>> #4 Pros: Smaller initial download
>> #4 Cons: Might be more work to transfer source from SVN to Git with
>> history?
>>
>> For me, retaining history is way more important than waiting 2.5 hours once
>> for the initial download.
>>
>>
>> On 3/21/13 1:34 PM, "Om" <bi...@gmail.com> wrote:
>>
>>> Sorry, I have not been tracking the votes. Let me start up a new vote
>> with
>>> these options:
>>>
>>> ===================================
>>> What to do with Whiteboard?
>>>
>>> 1. Use the sparse checkout option as described here (
>>> http://markmail.org/message/dg7hplezkzwiroes)
>>> 2. Create a branch per user in the whiteboard
>>> 3. Move to github for whiteboards
>>> 4. Let whiteboards remain in SVN
>>>
>>> ===================================
>>>
>>> If there are more options, please add it to the discussion here. I will
>>> give some time for discussion before starting an official VOTE thread.
>>>
>>> Thanks,
>>> Om
>>>
>>> On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS
>>> <we...@hotmail.com>wrote:
>>>
>>>> Om,
>>>>
>>>> Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn),
>>>> that's a lazy vote, I can change my mind ?
>>>>
>>>> -Fred
>>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>