Projects/GitoriousKDE - Revision history

Tampakrap at 13:20, 14 July 2008

2008-07-14T13:20:52Z

Tampakrap at 14:59, 26 May 2008

2008-05-26T14:59:31Z

Tampakrap at 12:42, 26 May 2008

2008-05-26T12:42:44Z

Tampakrap at 12:41, 26 May 2008

2008-05-26T12:41:41Z

Patcito: update following comments from Thiago and co

2008-05-09T22:27:09Z

update following comments from Thiago and co

Patcito at 21:41, 4 May 2008

2008-05-04T21:41:59Z

Patcito: initial irc conversation

2008-05-04T21:40:42Z

initial irc conversation

Patcito at 18:57, 2 May 2008

2008-05-02T18:57:42Z

Patcito at 18:56, 2 May 2008

2008-05-02T18:56:26Z

Patcito: feature plan suggestion

2008-05-02T18:54:37Z

feature plan suggestion

@@ Line 35: / Line 35: @@
 * all repositories are readable (clone, fetch)
 * "private" repositories are only push-accessible by its owner
-* "project" repositories have ACLs that can be controlled by whoever created
+* "project" repositories have ACLs that can be controlled by whoever created that project
-       that project
 * "mainline" repositories are push-accessible by anyone with an account
-* "release" repositories are locked and are writable by the "release dude"
+* "release" repositories are locked and are writable by the "release dude" (Admins do manual control on these).
-       Admins do manual control on these.
 =KDE commit politic=

← Older revision		Revision as of 14:59, 26 May 2008
Line 132:		Line 132:

	* adapt gitorious design to KDE web style		* adapt gitorious design to KDE web style
		+
		+	* CIA integration...

	=initial IRC conversation=		=initial IRC conversation=

@@ Line 72: / Line 72: @@
 '''According to Mario Ðanić''':
 ) first question: any commiter to mainline can grant access. It is assumed that developers will discuss that between themselves anyway.
 ) If there are submodules admins, who does grant them there role? the supermodule admin?  --> Submodules admins are just commiters to mainline of the submodule.
 ) Gitorious would be a websvn replacement only, and not a bugzilla replacement
 ) it is neccessary to implement applying for developer status
 '''ruphy thinks that...'''
 ) Several admins, for sure... but... do we really need that? I'd say that anyone should be able to send the occasional bugfix upstream. (at least in a mob-branch-fashon way?). However, this could be avoided if we make forking extremely trivial (as in pusing a button and waiting <5sec), and similarly also pull requests.
 ) I really think so....
 ) I know bugzilla sucks, but we're going to stick with it for a while still... handling bugs for KDE is just extremely complicated. :\
 ) I... guess so? however, the simpler it is, the better.

@@ Line 71: / Line 71: @@
 ==Answers to these questions we have so far==
 '''According to Mario Ðanić''':
-* first question: any commiter to mainline can grant access. It is assumed that developers will discuss that between themselves anyway.
+) first question: any commiter to mainline can grant access. It is assumed that developers will discuss that between themselves anyway.
-* If there are submodules admins, who does grant them there role? the supermodule admin?  --> Submodules admins are just commiters to mainline of the submodule.
+) If there are submodules admins, who does grant them there role? the supermodule admin?  --> Submodules admins are just commiters to mainline of the submodule.
-* Gitorious would be a websvn replacement only, and not a bugzilla replacement
+) Gitorious would be a websvn replacement only, and not a bugzilla replacement
-* it is neccessary to implement applying for developer status
+) it is neccessary to implement applying for developer status
 =Suggestions=

@@ Line 9: / Line 9: @@
 =KDE repository structure=
-First we need to study the KDE repository structure with Git.
+The goal is to have a git repository for each KDE module, (Thiago: "given the current level of cross-repository copy/move support in Git, I'd be tempted to lump kdelibs and kdebase together"). Only playground would make use of submodules.
-KDE is an umbrella of many big projects, each of them is made of several smaller parts that are projects of their own.
-What seems to be the current agreement is that KDE big projects would be git supermodules and KDE sub-projects would be git submodules.
 '''This is what it looks like''':
@@ Line 21: / Line 19: @@
    includes
    doc
-  ...
+   kdecore/
-   kdecore.git    (module)
+   kdeui/
-   kdeui.git      (module)
+   kio/
-   kio.git        (module)
+   knewstuff/
-   knewstuff.git  (module)
-  ...
 kdebase.git
@@ Line 33: / Line 29: @@
    doc
    ...
-   plasma.git     (module)
+   plasma/
-    ruphy-plasma.git
+   kdm/
-    notmart-plasma.git
-    chani-plasma.git
-    someone-plasma.git
-    ...
-   kdm.git        (module)
    ...
 =KDE commit politic=
@@ Line 53: / Line 51: @@
 ==Type of users and their abilities==
-===regular users===
+===Developer rights===
-* ability to create clones and commit to their clones
+* create "project" or "private" repositories, either as clones or new repos
-* ability to make merge request to mainline
+* submit to any mainline repository
-* ability to apply for developer status
-* ability to request for the creation of a new supermodule/submodule
-* ability to make bug reports/whishes
-===KDE developers===
-* ability to make commits to mainline
-* ability to accept or reject appliances for developer status (see question 2)
-* ability to request for the creation of a new supermodule/submodule
-===Administrator===
-* ability to create (and remove?) supermodules and submodule
-* ability to move submodule from one supermodule to another supermodule (ex: kdeplayground=>kdeedu )
-* ability to accept creation of new projects inside of supermodules
 =We have a few questions too=

@@ Line 135: / Line 135: @@
 =initial IRC conversation=
-trapni:  thiago: I was looking for a git hosting service as my local host can't be up as good as a server, so I had to push the repo (including history, ideally) to such a service (I decided to use gitorious - hopefully it's good though :)
+ trapni:  thiago: I was looking for a git hosting service as my local host can't be up as good as a server, so I had to push the repo (including history, ideally) to such a service (I decided to use gitorious - hopefully it's good though :)
   thiago:  ok
   trapni:  thiago: finally, is kde moving from svn to git anytime soon? do you have an idea? (just to be curious)

← Older revision		Revision as of 21:40, 4 May 2008
Line 133:		Line 133:

	* adapt gitorious design to KDE web style		* adapt gitorious design to KDE web style
		+
		+	=initial IRC conversation=
		+	trapni: thiago: I was looking for a git hosting service as my local host can't be up as good as a server, so I had to push the repo (including history, ideally) to such a service (I decided to use gitorious - hopefully it's good though :)
		+	thiago: ok
		+	trapni: thiago: finally, is kde moving from svn to git anytime soon? do you have an idea? (just to be curious)
		+	thiago: hasn't had the time to do that
		+	thiago: which means it hasn't moved, since I am the only person trying to do it
		+	trapni: i know tha lag of time, yep
		+	trapni: what are the issues?
		+	trapni: are there some?
		+	thiago: submodule support isn't good enough, we haven't finished writing the import rules, we don't know the layout of the repositories yet, we need some server software (web service) for creating and cloning repositories, setting ACLs; getting rid of svn:externals
		+	trapni: might be interesting to know wether there actually is an interest in moving from svn to git for the majority of kde devs or not
		+	thiago: ah, and support for copy-with-history
		+	trapni: ah, yeah
		+	trapni: one big lag of all those git hosting services is, that they don't provide a homepage for your project - to sad :)
		+	pygi: yet ;)
		+	thiago: we decided that all our repositories will have a mandatory wiki homepage
		+	trapni: a wiki is nice, yeah
		+	thiago: if you request a repo on the server, you have to write a wiki page saying what your repo is for
		+	trapni: on what server are you talking about?
		+	trapni: you mean the kde repository?
		+	thiago: git.kde.org
		+	trapni: oh, you really have one?
		+	thiago: no
		+	trapni: :(
		+	pygi: could volunteer during SoC to work with thiago to improve gitorious for kde needs ;)
		+	trapni: i also thought about having one of my libraries to be hosted at kde, in case you'd have a homepage and git for me (it's the capseo/libcaptury video capturing framework used by kwin) ;)
		+	trapni: pygi++
		+	thiago: I don't see why not
		+	thiago: we also need a central DNS registry for us because of D-Bus names
		+	trapni: yep
		+	trapni: thiago: what do you need me to do got get my git repositories (and wiki pages) hosted their?
		+	trapni: i'd be glad in fullfilling the requirements though :)
		+	thiago: 1) get the server to exist
		+	thiago: 2) get the software running on the server that doesn't exist yet
		+	thiago: 3) get kde to convert
		+	trapni: aha, you mentioned the 'server' word - which i can't provide currently :D
		+	thiago: we have the machine already
		+	trapni: oh
		+	pygi: trapni, would be nice to have ability to request project addition, admins allow it, and then the space for website and git are provided for you
		+	pygi: (eventually even mailman auto-create magic even ;))
		+	trapni: pygi: exactly
		+	thiago: in half the cases, the new repositories are project branches
		+	trapni: while i noticed very very poor feedpack performance on savannah.[non]gnu.org where I first tried to host my capturing libraries on
		+	pygi: thiago, branches can be done without approval
		+	thiago: so the software should clone and set up the alternates link
		+	trapni: they do require admin acceptance, gitorious didn't - which i quited liked
		+	pygi: thiago, yup, one would be able to see a network of folks who cloned certain repos/branches
		+	pygi: only addition of new modules (repositories) would require admin approval
		+	pygi: cloned/forked branches dont need web-space, or mailing list, or anything, anyway
		+	thiago: pygi: right
		+	thiago: but we still want to enforce a wiki page describing the project
		+	trapni: forked branches maybe do, but general purpose branches don't (they're most likely to be merged back)
		+	thiago: so that we can have a proper list of repositories with their purpose
		+	pygi: thiago, well, yes ... wiki page per project, not per branch :)
		+	thiago: instead of a "braindump" like http://git.kernel.org/
		+	thiago: no, per repository
		+	trapni: thiago: i highly encourage the wiki-requirement, i guess nobody will have a problem with it, at least I were explicitely looking for a git hosting service with homepage feature (which I failed in finding yet anyways)
		+	pygi: thiago, yup
		+	pygi: trapni, that's what I meant, yes
		+	thiago: the idea of the wiki homepage is to describe what the repository is for, who's working on it, etc.
		+	pygi: yea, basic description of it and stuff
		+	thiago: exactly
		+	thiago: for separate projects (like trapni's idea), it might need some actual webspace and a domain name
		+	thiago: under the .kde.org hierarchy, so the project can have its own D-Bus namespace
		+	pygi: a lot of magic under :)
		+	pygi: so the "application" process would involve selection of services one needs, and a link to wikipage describing what the repository will be for, descriptions, and such
		+	thiago: yep
		+	thiago: the admin would also be able to select from the account list who's allowed to push there
		+	pygi: thiago, why not the repository owner?
		+	thiago: the admin = the repository owner
		+	pygi: ah, ok! I was thinking of complete system admin
		+	thiago: or anyone with push permissions. I don't see the need for making the distinction.
		+	pygi: aha, got it
		+	trapni: still admin != owner, their _maybe_ shall be a distinction, shouldn't it?
		+	thiago: I don't see the need
		+	pygi: ok, so no need for manual review process I take it
		+	thiago: whoever requests the repository is given push/admin rights over it
		+	thiago: and he can give those rights to anyone else
		+	pygi: thiago, nod, but who has the ability to approve the request?
		+	pygi: or is it approved magically?
		+	thiago: should be automatic for clones
		+	pygi: yea, but what for new repos? :p
		+	thiago: for brand-new projects, sysadmins
		+	pygi: yea, well .. that's what we're talking here =)
		+	thiago: you have to fit it into one of the supermodules anyways
		+	trapni: in my case, it's not a brand new project, I'm just looking for a sweet home :)
		+	thiago: you'd have to justify the relation to kde
		+	thiago: if it's in kdesupport, it's something kde uses
		+	thiago: if it's in extragear, it's kde-based
		+	pygi: ah, so one should be able to create project (say kdesupport) and then module under it!
		+	thiago: yeah, things have to be organised
		+	pygi: a lot of things to think about =)
		+	trapni: kdesupport is the relation
		+	thiago: my idea was to have a top-level hierarchy "stable" with kdesupport, kde, koffice and extragear supermodules
		+	thiago: then a top-level hierarchy "projects" with cloned repositories as well as new stuff (i.e., current playground)
		+	thiago: then a top-level hierarchy "users" for someone's own branches (no wiki page required)
		+	thiago: people don't get today in SVN the difference between /branches/work and /trunk/playground, so we might as well merge the concepts
		+	pygi: supermodules with projects under them
		+	pygi: joy :)
		+

	* Annex: create plasmoids that will make use of the Gitorious web service api.		* Annex: create plasmoids that will make use of the Gitorious web service api.

← Older revision		Revision as of 18:57, 2 May 2008
Line 117:		Line 117:
	4) If KDE is going to keep bugzilla, we can still hook up gitorious with bugzilla in order to make them work together. As an example when a commit message has "closes #123" it will close the bugzilla bug #123, that's just an example of interaction. To have this kind of interaction, we'd need bugzilla xml-rpc web service API turned on, is that the case?		4) If KDE is going to keep bugzilla, we can still hook up gitorious with bugzilla in order to make them work together. As an example when a commit message has "closes #123" it will close the bugzilla bug #123, that's just an example of interaction. To have this kind of interaction, we'd need bugzilla xml-rpc web service API turned on, is that the case?

−	5) Automatically generate [[Schedules/KDE4/4.1_Feature_Plan \| Feature Plans]], when a branch is created its status is marked as "TODO", when it starts ~~get~~ some commits, its status is marked as "IN PROGRESS", when the branch is merged back in mainline its status is marked as "DONE".	+	5) Automatically generate [[Schedules/KDE4/4.1_Feature_Plan \| Feature Plans]] by mapping branches to feature, when a branch is created its status is marked as "TODO", when it starts getting some commits, its status is marked as "IN PROGRESS", when the branch is merged back in mainline its status is marked as "DONE".

← Older revision		Revision as of 18:56, 2 May 2008
Line 117:		Line 117:
	4) If KDE is going to keep bugzilla, we can still hook up gitorious with bugzilla in order to make them work together. As an example when a commit message has "closes #123" it will close the bugzilla bug #123, that's just an example of interaction. To have this kind of interaction, we'd need bugzilla xml-rpc web service API turned on, is that the case?		4) If KDE is going to keep bugzilla, we can still hook up gitorious with bugzilla in order to make them work together. As an example when a commit message has "closes #123" it will close the bugzilla bug #123, that's just an example of interaction. To have this kind of interaction, we'd need bugzilla xml-rpc web service API turned on, is that the case?

−	5) Automatically generate [[4.1_Feature_Plan Feature Plans]], when a branch is created its status is marked as "TODO", when it starts get some commits, its status is marked as "IN PROGRESS", when the branch is merged back in mainline its status is marked as "DONE".	+	5) Automatically generate [[Schedules/KDE4/4.1_Feature_Plan \| Feature Plans]], when a branch is created its status is marked as "TODO", when it starts get some commits, its status is marked as "IN PROGRESS", when the branch is merged back in mainline its status is marked as "DONE".

← Older revision		Revision as of 18:54, 2 May 2008
Line 116:		Line 116:

	4) If KDE is going to keep bugzilla, we can still hook up gitorious with bugzilla in order to make them work together. As an example when a commit message has "closes #123" it will close the bugzilla bug #123, that's just an example of interaction. To have this kind of interaction, we'd need bugzilla xml-rpc web service API turned on, is that the case?		4) If KDE is going to keep bugzilla, we can still hook up gitorious with bugzilla in order to make them work together. As an example when a commit message has "closes #123" it will close the bugzilla bug #123, that's just an example of interaction. To have this kind of interaction, we'd need bugzilla xml-rpc web service API turned on, is that the case?
		+
		+	5) Automatically generate [[4.1_Feature_Plan Feature Plans]], when a branch is created its status is marked as "TODO", when it starts get some commits, its status is marked as "IN PROGRESS", when the branch is merged back in mainline its status is marked as "DONE".
		+

	=Sum up of the evaluation=		=Sum up of the evaluation=