| 1 |
AFAIK, we could manage the entire thing via cvs - no incoming dir, no |
| 2 |
commit-request emails. |
| 3 |
|
| 4 |
We would have several 'trees' in cvs: stable, unstable (=devel), external |
| 5 |
(any better names?), incoming (=user-submitted), trees for past releases |
| 6 |
which could get bugfixes, etc. |
| 7 |
|
| 8 |
A developer who wanted to change another developer's ebuild would have to |
| 9 |
commit a new revision of that ebuild to the 'external' tree. (That's what |
| 10 |
he'd have permissions to do.) The maintaining developer could then look over |
| 11 |
his changes (and the commit log message), and if he accepted them, merge the |
| 12 |
changes into his main devel tree. Once in there, the changes needed to be |
| 13 |
proven stable and good (like the maintainer's own work) and would then be |
| 14 |
merged into the stable tree. Non-developers who did 'emere rsync' could only |
| 15 |
get things from the stable tree. |
| 16 |
|
| 17 |
A similar procedure wuold be used for 'incoming' user ebuilds, with another |
| 18 |
cvs tree. |
| 19 |
|
| 20 |
What do you think? |
| 21 |
|
| 22 |
|
| 23 |
On Friday 03 August 2001 18:08, you wrote: |
| 24 |
> Hi! |
| 25 |
> |
| 26 |
> I renamed the thread since it's not about xchat 1.8.2 anymore. |
| 27 |
> |
| 28 |
> > I think if we choose to do this, then we had better rethink the |
| 29 |
> > incoming directory right now. While it may be okay for a few |
| 30 |
> > outstanding user-submitted ebuilds, this scheme has the potential to |
| 31 |
> > cause a lot problems. What we really need is an unstable cvs tree; |
| 32 |
> > then user-submitted ebuilds and non-team developer-hacked ebuilds can |
| 33 |
> > go there until they are verified by team members. |
| 34 |
> |
| 35 |
> If we have maintainer of ebuilds (which I think we shall have) I don't |
| 36 |
> think that other people should commit into the CVS tree without his |
| 37 |
> aproval (neither unstable nor stable). It will be very hard for a |
| 38 |
> maintainer of many packages to keep track of what's happening if |
| 39 |
> people just commit at will. |
| 40 |
> |
| 41 |
> > I think all we need is maintainer. This is the guy who "puts his rep |
| 42 |
> > on the line." cvs log keeps all the other information. The person |
| 43 |
> > you really want to complain to about a bad ebuild is the maintainer |
| 44 |
> > anyway. Then he can do a cvs log to see who the culprit is and get in |
| 45 |
> > touch. |
| 46 |
> |
| 47 |
> This will not be a problem if only the maintainer are allowed to |
| 48 |
> commit (or aprove commits). I think this is the best way to do it. |
| 49 |
> |
| 50 |
> If you want to make a commit to an ebuild that you are not maintainer |
| 51 |
> of: |
| 52 |
> |
| 53 |
> If you are a developer: |
| 54 |
> 1) Send the patch to the maintainer asking if you may commit. |
| 55 |
> 2) The maintainer might commit or aprove of you commiting or tell you |
| 56 |
> why it won't go in (and perhaps what you need to fix first). |
| 57 |
> |
| 58 |
> Otherwise: |
| 59 |
> 1) Send the patch to the maintainer which will either commit or tell |
| 60 |
> you to change the patch in some way. |
| 61 |
> |
| 62 |
> This will make it harder for people to commit to all kinds of ebuilds |
| 63 |
> but I think that this is the way we have to do it in the future. |
| 64 |
> |
| 65 |
> Of course a maintainer might give a certain person commit rights if he |
| 66 |
> trusts the other developer to do it right. |
| 67 |
> |
| 68 |
> Regards, |
| 69 |
> Mikael Hallendal |
| 70 |
|
| 71 |
-- |
| 72 |
|
| 73 |
Dan Armak |
| 74 |
Gentoo Linux Developer, Desktop Team |
| 75 |
Matan, Israel |
Archives