Quantcast

Call to simplify Github's collective repository management

classic Classic list List threaded Threaded
9 messages Options
Malthe Borch-2 Malthe Borch-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Call to simplify Github's collective repository management

I think we should revert to the "native" way of managing repositories
on github. This applies for both Plone and the Collective.

Currently, there's a somewhat involved (and unfortunately broken)
system in place that automatically creates repositories from a list of
permissions. This is however entirely unnecessary and I dare say not
in the spirit of the original Subversion-based repository. The idea
was instead that you just needed to become a member and that would
grant you all rights; push, pull, delete, everything.

We just need to set up a script that automatically takes note of new
repositories and makes sure that its shared with all members. To my
understanding, that's the only issue we have right now. There will
probably always be some manual work in getting a new member added to
the organization. From then on, it should be smooth sailing.

I volunteer to write, test or help set up such a system.

\malthe

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
aclark aclark
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management

Hi Malthe,

On 1/17/12 5:33 PM, Malthe Borch wrote:
> I think we should revert to the "native" way of managing repositories
> on github. This applies for both Plone and the Collective.

+1. But that flies directly in the face of:

-
http://www.martinaspeli.net/articles/developer-centric-version-control-considered-harmful

Though maybe Martin has changed his mind by now ;-)


>
> Currently, there's a somewhat involved (and unfortunately broken)
> system in place that automatically creates repositories from a list of
> permissions. This is however entirely unnecessary and I dare say not
> in the spirit of the original Subversion-based repository. The idea
> was instead that you just needed to become a member and that would
> grant you all rights; push, pull, delete, everything.


I think you misunderstand the point of the current system, which is to
bolt-on a Subversion-like system on top of what is inherently unlike
Subversion.

In the old collective, if I add you as a member then you immediately
have access to everything in the repository. And if you delete it, I can
just "roll it back".

In the new collective, there are "granular" permissions and I have to
assign one of them to you if I want to "share" my repo with you
(push/pull/manage). If I "share" my repo with you and you delete it,
it's GONE.

So, this "involved system" is actually a way to create a collective-like
environment where none exists (not a way to add unnecessary complexity,
as you suggest.) It does this by:

- putting everyone in the Contributors team
- giving that team push/pull access to all the repos


> We just need to set up a script that automatically takes note of new
> repositories and makes sure that its shared with all members. To my
> understanding, that's the only issue we have right now. There will
> probably always be some manual work in getting a new member added to
> the organization. From then on, it should be smooth sailing.
>
> I volunteer to write, test or help set up such a system.


When you suggested doing things the "native" way I thought you meant
using github "as it was intended", i.e. via developer-centric
development and push/pull requests, which is what I'd like to do.

In any event, I'm not convinced it's as easy as you describe. When
someone does the manual work to add a member, what permissions do they
get? Can they add/remove repos? If so then you are back to "problem #1"
which is that the new member can now remove any repo from the
organization. I'm not saying this is a show stopper, but it's something
to think about.


As Rok explained to me, the real problem is that github's permissions
model sucks. And we are basically fighting the framework here.


Alex


>
> \malthe
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d


--
Alex Clark · http://pythonpackages.com


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Malthe Borch-2 Malthe Borch-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management

On 17 January 2012 23:55, Alex Clark <[hidden email]> wrote:
> In the new collective, there are "granular" permissions and I have to
> assign one of them to you if I want to "share" my repo with you
> (push/pull/manage). If I "share" my repo with you and you delete it,
> it's GONE.

To some extent, yes – your issue tracker and wiki will be – but you're
likely to have a local copy that you can just push back; or an
off-site backup.

> When you suggested doing things the "native" way I thought you meant
> using github "as it was intended", i.e. via developer-centric
> development and push/pull requests, which is what I'd like to do.

I actually think that model is nuts, i.e. the "fork me" model. I think
it's the "Acquisition" of Github – at least for team-based projects
like the Plone Collective.

> In any event, I'm not convinced it's as easy as you describe. When
> someone does the manual work to add a member, what permissions do they
> get? Can they add/remove repos? If so then you are back to "problem #1"
> which is that the new member can now remove any repo from the
> organization. I'm not saying this is a show stopper, but it's something
> to think about.

I think you're right.

Perhaps the clue is that it's good to have a process where you submit
an issue saying "I'd like to start up this new project". An e-mail
could be sent out to existing members and one of the admins could
decide to create the repository.

Is it a lot of work? I'm not sure – what are the numbers?

> As Rok explained to me, the real problem is that github's permissions
> model sucks. And we are basically fighting the framework here.

Gotcha.

Thanks for taking the time to go through it again here.

\malthe

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
toutpt toutpt
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management

Same here ! I have talked to Rok @garbas on IRC last week about this and asking to make it as svn collective is. You already know the answer.

I don't care if someone remove my repo (to do this you have to use the webUI with two levels of confirmation so ...) and it was also possible with svn and no one has complains about this.

The main reason that comes to me is not the bug on permissions, it can be fixed, but the time I have to waiting for when I have pushed a new repo on it.

The current process can take one week:

Adding to github/collective process is quite hard:
Create my repo, git init, git add, git commit, git push (easy)
Change owner to collective once the addon is working and about to be released
Update my fork of collective.github.com
Add configuration related to my repo
Pull request (wait the pull request to be merged : 0 to 5 days)
Wait for the script to be executed (1 day)

It should not take more than it was on svn (I mean 5 minutes)

Regards / Cordialement,
JeanMichel FRANCOIS


2012/1/18 Malthe Borch <[hidden email]>
On 17 January 2012 23:55, Alex Clark <[hidden email]> wrote:
> In the new collective, there are "granular" permissions and I have to
> assign one of them to you if I want to "share" my repo with you
> (push/pull/manage). If I "share" my repo with you and you delete it,
> it's GONE.

To some extent, yes – your issue tracker and wiki will be – but you're
likely to have a local copy that you can just push back; or an
off-site backup.

> When you suggested doing things the "native" way I thought you meant
> using github "as it was intended", i.e. via developer-centric
> development and push/pull requests, which is what I'd like to do.

I actually think that model is nuts, i.e. the "fork me" model. I think
it's the "Acquisition" of Github – at least for team-based projects
like the Plone Collective.

> In any event, I'm not convinced it's as easy as you describe. When
> someone does the manual work to add a member, what permissions do they
> get? Can they add/remove repos? If so then you are back to "problem #1"
> which is that the new member can now remove any repo from the
> organization. I'm not saying this is a show stopper, but it's something
> to think about.

I think you're right.

Perhaps the clue is that it's good to have a process where you submit
an issue saying "I'd like to start up this new project". An e-mail
could be sent out to existing members and one of the admins could
decide to create the repository.

Is it a lot of work? I'm not sure – what are the numbers?

> As Rok explained to me, the real problem is that github's permissions
> model sucks. And we are basically fighting the framework here.

Gotcha.

Thanks for taking the time to go through it again here.

\malthe

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Rok Garbas Rok Garbas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management

In reply to this post by Malthe Borch-2
On Tuesday 17 de January de 2012 at 23:33, Malthe Borch wrote:

> I think we should revert to the "native" way of managing repositories
> on github. This applies for both Plone and the Collective.
>  
> Currently, there's a somewhat involved (and unfortunately broken)
> system in place that automatically creates repositories from a list of
> permissions. This is however entirely unnecessary and I dare say not
> in the spirit of the original Subversion-based repository. The idea
> was instead that you just needed to become a member and that would
> grant you all rights; push, pull, delete, everything.
>  
> We just need to set up a script that automatically takes note of new
> repositories and makes sure that its shared with all members. To my
> understanding, that's the only issue we have right now. There will
> probably always be some manual work in getting a new member added to
> the organization. From then on, it should be smooth sailing.
>  
> I volunteer to write, test or help set up such a system.
>  
i'm currently the maintainer, but was out of time to fix this over the weekend, since i do this on volunteer basis.  

i had same idea as you described above and we are not restricting it without any reason. if you would look closer to github permission system you'll see that there is something strange happening. but maybe better to start explaining were it all begins.

difference between deleting a repo in svn/collective and now (github/collective) is that once you delete repository on github this is irreversible. one get "removing repo" permission with Administrative role. so it would make sense to only enable Pull & Push role for everybody, but then they don't have permission to create new repository. to gain permission to create new repository you have to have Administrative role in at least one of the repos. There is an old ticket about github permissions and "Create New Repo" permission, they've promised it, but that was 2 years ago. thats why in the beginning of github/collective i had 2 teams with all users, one team with push&pull permission, which was assign to all repos and second team with push&pull&admin rights which was not assign to no repository. this way ppl could create repository, but not delete it. then i couldn't keep up with requests about changing title/description, removing repos etc… so in one afternoon i created a script which we have now. it was running ok for last 6 month.

i hope i gave you some insight of why we are doing it this way. script we have currently i've written in 4h and was working until last weekend. i hope to find enough time today to look where is going wrong.

if you have better idea and time to implement, it i'm all in favor of changing from what we have now. i'm definitely aware its not perfect, but thats best we have right now.


lp rok






--  
Rok Garbas - http://www.garbas.si




------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Jean Jordaan Jean Jordaan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management

In reply to this post by Malthe Borch-2
On Wed, Jan 18, 2012 at 3:28 PM, Malthe Borch <[hidden email]> wrote:
> I actually think that model is nuts, i.e. the "fork me" model. I think
> it's the "Acquisition" of Github – at least for team-based projects
> like the Plone Collective.

It's not intended for teams; "fork me" is intended for loose collaboration,
where you have no affiliation with the source project beyond being a user.

Teams (such as Collective contributors) should have push/pull access and use
branches, as described at
  http://scottchacon.com/2011/08/31/github-flow.html

IIUC.

--
jean                                              . .. .... //\\\oo///\\

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Rok Garbas Rok Garbas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management


i missed the thread before i made the reply… meanwhile
github/collective is working.

i agree with all you said about the current process and i know its a
bit complicated, but thats what we're forced to do right now.

while somebody dont care if his repos are deleted i kinda do. i will
definetly remove repos from github/collective that i work on, if
everybody could _permanently_ delete my repositories. and i believe i'm
not alone here.

i also don't buy into: "i had to wait more that 5min" … its dvcs so you
can start working in your own account and the "fork it" to
github/collective at later stage. this way you dont have to "wait".

script (except for last few days) was working. problem was that there
was user added which not existed on github. a typo.

i was also thinking about creating web front end for this, but then to
create repo on github you would have to go off github? well it made
little sense for me. especially since i was hoping that permissions
issue will be finally solved. (since gihub changed their support site i
can not point you at this ticket but as they said they we planning this
for early 2011.)

and to be honest i dont have idea what to do to make things easier.


--
Rok Garbas
http://www.garbas.si




------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Malthe Borch-2 Malthe Borch-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management

On 18 January 2012 13:31, Rok Garbas - gmail.com <[hidden email]> wrote:
> i also don't buy into: "i had to wait more that 5min" … its dvcs so you
> can start working in your own account and the "fork it" to
> github/collective at later stage. this way you dont have to "wait".

Definitely.

As long as there's a process that does work, even if it's slow, it's okay.

> i was also thinking about creating web front end for this, but then to
> create repo on github you would have to go off github? well it made
> little sense for me. especially since i was hoping that permissions
> issue will be finally solved. (since gihub changed their support site i
> can not point you at this ticket but as they said they we planning this
> for early 2011.)

It works pretty well.

The permissions.cfg file is a little long and it's somewhat
error-prone to edit it – but it's not the end of the world.

\malthe

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Jens W. klein-2 Jens W. klein-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Call to simplify Github's collective repository management

In reply to this post by Rok Garbas
Rok you rock, thanks a lot for your time on this.

After doing work on other projects outside Plone I realised the value of
the collective. Its a collaboration model of trust and it works fine so
far, more: its a superpower of the Plone community. Having this way to
work available with git is great, even if its not the kind of process
git was invented for I think. But that way we have 2 superpowers squared.

Even if the current workflow of getting access and creating new
repositories is not very streamlined: it worked fine. git-beginners may
have problems with this, also the github docs arent matching! Anyway,
almost every pull request ticket was answered at working days after 24h,
some after 10 minutes. We may simplify the process, we may improve the
docs, well you can always do improve docs. But please dont change the
character of the collective only because github doesnt match our way to
work.

Jensens
--
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Loading...