On 01/02/2013 04:25 PM, Pranav Saxena wrote:
Wido , you are right .
What Sateesh seems to be referring to is to have a safe and secure location for a non-committer
where he could push his changes while working on an "individual" feature. And since a
non-committer cannot push a feature branch to asf , Sateesh seems to be interested in maintaining a
public "github" repo which is open source .But the demerit is , as you very rightly
pointed that it won't be visible to the community , unless few users in the community are
sincerely interested in forking that specific github repo for contributing to the feature
development , where Sateesh can grant permissions . For a non-committer it might seem easy to
maintain his code commits like that . But then , when one has to merge it with asf/master , the
user has to continuously rebase it with asf/master else it t will definitely lead to conflicts.
I did the RBD implementation that way. I kept rebasing my RBD branch
against master until it was ready for inclusion.
A final rebase and "git format-patch" were enough to get it in the
master branch.
Secondly , merging a public git hub repo without incessant community vigilance
would lead to issues and arguments later on since a similar case was
encountered while development of Autoscale feature in the recent past .
True, but it somebody is not a committer he/she has to go on to the
mailinglist and ask for somebody to get it merged in.
You are always welcome to sent status updates to the ml during
development to keep people posted.
Otherwise , the trivial way of developing your feature on a private repo and
then sending small patches for review has been working out well in the past.
If you rebase and keep your commits small a merge should indeed be easier.
I think a lot depends on your GIT workflow and how you (ab)use GIT.
Wido
Any elegant ideas for a non-committer to contribute and maintain his code base
?
I know Brian , one of the UI-devs has been maintaining git hub repos for his
widgets framework .
Regards,
Pranav
-----Original Message-----
From: Wido den Hollander [mailto:[email protected]]
Sent: Wednesday, January 02, 2013 8:40 PM
To: [email protected]
Subject: Re: Private development branch
On 01/02/2013 02:32 PM, Likitha Shetty wrote:
Even if a new branch is created won't a contributor's work flow for feature
development remain the same? Because from what I understand git by itself does
not allow branch-level access control.
Does that reflect back on the original question? I think Sateesh meant that a
"secure" location had to be non-local in case of data loss? Or did I
misunderstood?
Anyway, GIT doesn't support branch level access control, but does that matter
for an Open Source project?
Wido
Thank you,
Likitha
-----Original Message-----
From: Wido den Hollander [mailto:[email protected]]
Sent: Wednesday, January 02, 2013 5:59 PM
To: [email protected]
Subject: Re: Private development branch
On 01/02/2013 10:26 AM, Sateesh Chodapuneedi wrote:
Hi,
I think the current work flow for development (non-committer) fits well for
small patch development.
But in case of feature development or bigger patches which might need longer
period of development, developer need some place to push the code changes. It's
needed to push code changes to secure location rather than depend on commits to
local repository (in their development machine).
Would forking ASFCS on any public git host (github.com) sound good? Is that a
legitimate idea?
Why not create a new branch on the ASF repo? This way other committers can
easily see that a new feature is being worked on.
That said, you need to have committer rights to do so.
If you place the code on Github it will not be seen by other community members
and it could also mislead other users who find the code on Github.
Wido
Regards,
Sateesh
