Pending commits, anyone ever thought about this feature?

["Andrés G. Aragoneses"-2]

I'm thinking that the following feature would improve the overall
experience for open source projects that use Subversion:

1) Instead of having anonymos read-only access and having a list of
users with write access (committers), everybody can commit.
2) Each subpath of the repository (modules) have a list of users
associated which are marked as maintainers.
3) Every commit is saved as "pending" and sent to the maintainers of the
subpath affected.
4) Maintainers of modules can commit jumping the "pending" phase (direct
commit).
5) User accounts are created, not by an admin, but by providing a
username and password (in a commit) that never existed before and the
commit is approved.
6) Subversion admin role is only mark the flag "maintainer" to "user
accounts" and "subpaths".


This way, we obtain the following advantages:

1) The first commits of a novice doesn't get "forged" by a maintainer.
2) Reduce admin efforts.
3) Support a very easy way to manage the review-approve/reject-commit
cycle problem.


So, my questions:

1) Is this already possible with subversion?
2) If yes, how?
3) If not, has anybody already thought about this? Is there a issue open
in the bug tracking tool for it?
4) Has any third-party tool support for this?
4) If not, would it be interesting to implement it? (Would the feature
get committed if contributed?)


Thanks in advance,

        Andrés

--


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[tg2k]

I can tell you that my company would appreciate such a feature.  We are likely to choose one of two mechanisms in the shorter term:

1.  Something involving a "maintainer":
    a.  Possibly automatically performed--can Crucible do this?
    b.  Or manually performed.
2.  A pre-commit hook that would make sure the commit log references an approved defect.

We would allow all of our developers to commit to certain areas, but to merge changes to "locked down" areas, one of the above would be required.

Pending commits would be even nicer, though naturally they're more prone to fail due to conflicts than both the #2 above and #1b (where you have a human looking at what goes in), but probably equally often with respect to #1a since that's another automated process that would sit for awhile before committing.
 
-----Original Message-----
From: news [mailto:news@...] On Behalf Of "Andrés G. Aragoneses"
Sent: Wednesday, July 02, 2008 5:05 AM
To: users@...
Subject: Pending commits, anyone ever thought about this feature?

I'm thinking that the following feature would improve the overall
experience for open source projects that use Subversion:

1) Instead of having anonymos read-only access and having a list of
users with write access (committers), everybody can commit.
2) Each subpath of the repository (modules) have a list of users
associated which are marked as maintainers.
3) Every commit is saved as "pending" and sent to the maintainers of the
subpath affected.
4) Maintainers of modules can commit jumping the "pending" phase (direct
commit).
5) User accounts are created, not by an admin, but by providing a
username and password (in a commit) that never existed before and the
commit is approved.
6) Subversion admin role is only mark the flag "maintainer" to "user
accounts" and "subpaths".


This way, we obtain the following advantages:

1) The first commits of a novice doesn't get "forged" by a maintainer.
2) Reduce admin efforts.
3) Support a very easy way to manage the review-approve/reject-commit
cycle problem.


So, my questions:

1) Is this already possible with subversion?
2) If yes, how?
3) If not, has anybody already thought about this? Is there a issue open
in the bug tracking tool for it?
4) Has any third-party tool support for this?
4) If not, would it be interesting to implement it? (Would the feature
get committed if contributed?)


Thanks in advance,

        Andrés

--


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Reedick, Andrew-2]

> -----Original Message-----
> From: news [mailto:news@...] On Behalf Of "Andrés G.
> Aragoneses"
> Sent: Wednesday, July 02, 2008 7:05 AM
> To: users@...
> Subject: Pending commits, anyone ever thought about this feature?
>
>
>
> So, my questions:
>
> 1) Is this already possible with subversion?
> 2) If yes, how?
> 3) If not, has anybody already thought about this? Is there a issue
> open
> in the bug tracking tool for it?
> 4) Has any third-party tool support for this?
> 4) If not, would it be interesting to implement it? (Would the feature
> get committed if contributed?)
>

Sounds like branching.
1. create a dir called "submitted_by_peons"
2. Allow anonymous read/write to the submitted_by_peons tree
3. Peons create a proper sub-branch under "submitted_by_peons" for their submissions
4. Maintainers review the submissions
5. Maintainers merge worthy submissions to trunk

Pros:  svn already supports this
Cons:  enforcing "proper" sub-branch creation by peons
Assumptions:  you have a bug/issue tracker to facilitate communication and tracking of submitted patches





*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

["Andrés G. Aragoneses"-2]

Reedick, Andrew wrote:

>
>> -----Original Message-----
>> From: news [mailto:news@...] On Behalf Of "Andrés G.
>> Aragoneses"
>> Sent: Wednesday, July 02, 2008 7:05 AM
>> To: users@...
>> Subject: Pending commits, anyone ever thought about this feature?
>>
>>
>>
>> So, my questions:
>>
>> 1) Is this already possible with subversion?
>> 2) If yes, how?
>> 3) If not, has anybody already thought about this? Is there a issue
>> open
>> in the bug tracking tool for it?
>> 4) Has any third-party tool support for this?
>> 4) If not, would it be interesting to implement it? (Would the feature
>> get committed if contributed?)
>>
>
>
> Sounds like branching.
> 1. create a dir called "submitted_by_peons"
> 2. Allow anonymous read/write to the submitted_by_peons tree
> 3. Peons create a proper sub-branch under "submitted_by_peons" for their submissions
> 4. Maintainers review the submissions
> 5. Maintainers merge worthy submissions to trunk
>
> Pros:  svn already supports this
> Cons:  enforcing "proper" sub-branch creation by peons
> Assumptions:  you have a bug/issue tracker to facilitate communication and tracking of submitted patches
>

Interesting! but:
1) As you noted, the free sub-branch creation by everyone would still be
needed as a configurable feature.
2) AFAIK we still don't have the necessary bits in Subversion to know
what is a "peon" subbranch and who is the maintainer responsible of
being able to merge.

Thanks for your comment,

        Andrés

--


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[John Peacock-4]

Andrés G. Aragoneses wrote:
> 5) If not, would it be interesting to implement it? (Would the feature
> get committed if contributed?)

I seriously doubt that this feature would be accepted in the core code.
  It would implement a workflow that seems ways too narrowly defined for
a general purpose tool like Subversion.  I'm also not aware of any
existing tool that does anything like this for Subversion; some of the
distributed version control systems (like git) have some elements of
this workflow (specifically that anyone can commit to "their branch" and
someone else can determine which changes should be merged to the "main
stream").

You could certainly wrap something around Subversion to accomplish this:
imagine a web app that automatically hands out novice commit ID's and
precreates a branch for them and updates the security stanza.
Maintainers would simply be set up to have rights to the main project
and get commit e-mails for anything under their purview...

John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Reedick, Andrew-2]

> -----Original Message-----
> From: John Peacock [mailto:john.peacock@...]
> Sent: Wednesday, July 02, 2008 2:54 PM
> To: "Andrés G. Aragoneses"
> Cc: users@...
> Subject: Re: Pending commits, anyone ever thought about this feature?

> I seriously doubt that this feature would be accepted in the core code.
>   It would implement a workflow that seems ways too narrowly defined
> for
> a general purpose tool like Subversion.
 
> imagine a web app that automatically hands out novice commit ID's and
> precreates a branch for them and updates the security stanza.
> Maintainers would simply be set up to have rights to the main project
> and get commit e-mails for anything under their purview...
>


Any decent bug/ticket/issue tracking system should be able to fire a trigger/hook/event script to precreate the branch, set auth permissions on it (match svn usernames to the issue tracker's login,) send emails, etc..

The submitter would simply flip a bit-field on the ticket, the ticket software does all the setup work, the submitter submits the code to the branch, and when done, flips a status flag in the ticket tracker to indicate that the code is ready to be looked at.  This has the benefit for forcing folks to go through the ticket system before delivering code.


So yeah, it's definitely not a subversion thing.  It's a bug/ticket/issue/workflow application thing.

Subversion == database
Bug/ticket/issue/workflow app == process control



*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

["Andrés G. Aragoneses"-2]

Reedick, Andrew wrote:

>
>> -----Original Message-----
>> From: John Peacock [mailto:john.peacock@...]
>> Sent: Wednesday, July 02, 2008 2:54 PM
>> To: "Andrés G. Aragoneses"
>> Cc: users@...
>> Subject: Re: Pending commits, anyone ever thought about this feature?
>
>> I seriously doubt that this feature would be accepted in the core code.
>>   It would implement a workflow that seems ways too narrowly defined
>> for
>> a general purpose tool like Subversion.
>  
>> imagine a web app that automatically hands out novice commit ID's and
>> precreates a branch for them and updates the security stanza.
>> Maintainers would simply be set up to have rights to the main project
>> and get commit e-mails for anything under their purview...
>>
>
>
> Any decent bug/ticket/issue tracking system should be able to fire a trigger/hook/event script to precreate the branch, set auth permissions on it (match svn usernames to the issue tracker's login,) send emails, etc..
>
> The submitter would simply flip a bit-field on the ticket, the ticket software does all the setup work, the submitter submits the code to the branch, and when done, flips a status flag in the ticket tracker to indicate that the code is ready to be looked at.  This has the benefit for forcing folks to go through the ticket system before delivering code.
>
>
> So yeah, it's definitely not a subversion thing.  It's a bug/ticket/issue/workflow application thing.

Well, the fact that this can be implemented in a third-party or a
wrapper doesn't mean it should. Maybe it should in the first place (like
it happened with the svnmerge contrib wrapper tool) but I see some
advantages in implementing it natively:

- If done in a third-party tool, only that tool could be used for
getting this workflow thing (and AFAIK there are a lot of them used
currently in the opensource ecosystem: Trac, Bugzilla, Mantis, and even
small bug tracking tools associated to many forges like SourceForge,
GoogleCode, etc.) and thus would prevent massive adoption.
- Giving a tool the power to create accounts upon anonymous intervention
could be considered a small security risk.

The only advantage I see is the force to use the bug tracking tool. Then
I'm wondering if this should be implemented in a library which then can
be supported by many bug tracking tools...

Regards,

        Andrés

--


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...