Due to the current situation, pending changes to the main tree that are handled by proxy maintainers are spread over many places: bugs.gentoo.org, several pastebins, several overlays. We should think about adding a centralized overlay for proxied maintainers. This enables: - wider testing due to "early adopters", that use the overlay via layman on a daily basis - improved repoman usage (proxied maintainers are able to commit via repoman) - proxy maintainers can work on a filesystem basis (no attachements downloading anymore) - track progress of proxied maintainers (and get them into recruitment) - no forgotten fixes/bumps (just "overlint-cli ." the overlay)
Hm, i was strongly against such proposals, as we should push things directly from bugzilla to main tree, that's why we are here. But your arguments are quite good, so let's wait for other team members opinion.
The one thing i should notice, that we should not stick to git.o.g.o More feasible solution would be using Github or other service that allows to create/accept pull requests easy both for contributors and developers.
(In reply to Sergey Popov from comment #2) > The one thing i should notice, that we should not stick to git.o.g.o > > More feasible solution would be using Github or other service that allows to > create/accept pull requests easy both for contributors and developers. I am fine with an overlay though it adds some overhead managing it (adding members, reviewing pull requests, deleting ebuilds after moving them to tree etc)
I think that repository/overlay should not be central or required but it may be a good way to create just another good interface for submitting ebuilds. I think that github (or another social coding site like gitorius or bitbucket, if their licenses or policies are suites gentoo better) as its much easier for users to submit patches.
Currently I see the benefits on working with github (no member management, just run it as gentoo/proxy-maintainers-overlay and wait for pull-requests). It is not intended to become a requirement for proxied-maintainers. I'd like to push the idea forward and add the overlay to our github organisation during the next week, if nobody complains about it. :-)
I suppose basic things are set up here[1] [1] - https://github.com/gentoo/proxy-maintainers
(In reply to Sergey Popov from comment #6) > I suppose basic things are set up here[1] > > [1] - https://github.com/gentoo/proxy-maintainers We need someway to communicate that to users (anybody fancy a gentoo-dev post? or maybe a GMN item?)
(In reply to Markos Chandras from comment #7) > (In reply to Sergey Popov from comment #6) > > I suppose basic things are set up here[1] > > > > [1] - https://github.com/gentoo/proxy-maintainers > > We need someway to communicate that to users (anybody fancy a gentoo-dev > post? or maybe a GMN item?) Please let me add a suitable .gitignore, layout.conf and Readme first. :)
(In reply to Manuel Rüger from comment #8) > (In reply to Markos Chandras from comment #7) > > (In reply to Sergey Popov from comment #6) > > > I suppose basic things are set up here[1] > > > > > > [1] - https://github.com/gentoo/proxy-maintainers > > > > We need someway to communicate that to users (anybody fancy a gentoo-dev > > post? or maybe a GMN item?) > > Please let me add a suitable .gitignore, layout.conf and Readme first. :) I added a minimal setup, which should work fine. Feel free to improve it.
(In reply to Manuel Rüger from comment #9) > (In reply to Manuel Rüger from comment #8) > > (In reply to Markos Chandras from comment #7) > > > (In reply to Sergey Popov from comment #6) > > > > I suppose basic things are set up here[1] > > > > > > > > [1] - https://github.com/gentoo/proxy-maintainers > > > > > > We need someway to communicate that to users (anybody fancy a gentoo-dev > > > post? or maybe a GMN item?) > > > > Please let me add a suitable .gitignore, layout.conf and Readme first. :) > > I added a minimal setup, which should work fine. Feel free to improve it. Can i ask two questions? - Workflow? Who has access? Only devs (members of the @gentoo team) and we accept pull requests and then move them to tree? - Announcement?
(In reply to Markos Chandras from comment #10) > - Workflow? Who has access? Only devs (members of the @gentoo team) and we > accept pull requests and then move them to tree? GH --> g-x86: Pull request, we review, we pull, we push to the Portage tree. g-x86 --> GH: Either developer or user brings tree changes to the overlay. Tracking differences between GH and g-x86 can be done using overlint; it is also possible to script up some syncing later on, so, if we get more attention than foreseen it should still be fairly scalable. All Gentoo devs can help, we need to encourage them to speak to us first. Something like this? Based on what mrueg has said and/or personal opinion. > - Announcement? Forum, mailing lists, ...; but I'm wondering whether it would be appropriate to also send a mail out to all non-Gentoo non-upstream e-mails in the metadata.xml files of the whole Portage tree? Maybe we could first set up a gentoo-dev-help or gentoo-proxy-maint ML for improving communication with most proxy maintainers?
(In reply to Tom Wijsman (TomWij) from comment #11) > (In reply to Markos Chandras from comment #10) > > - Workflow? Who has access? Only devs (members of the @gentoo team) and we > > accept pull requests and then move them to tree? > > GH --> g-x86: Pull request, we review, we pull, we push to the Portage > tree. > g-x86 --> GH: Either developer or user brings tree changes to the > overlay. > > Tracking differences between GH and g-x86 can be done using overlint; > it is also possible to script up some syncing later on, so, if we get > more > attention than foreseen it should still be fairly scalable. > > All Gentoo devs can help, we need to encourage them to speak to us first. > > Something like this? Based on what mrueg has said and/or personal opinion. > Ok > > - Announcement? > > but I'm wondering whether it would be appropriate > to also send a mail out to all non-Gentoo non-upstream e-mails in the > metadata.xml files of the whole Portage tree? Maybe we could first set up a > gentoo-dev-help or gentoo-proxy-maint ML for improving communication with > most proxy maintainers? Please don't email all people in metadata. That would be rather annoying. We can inform them gradually. and we don't need another ML for proxy-maint. We can use github for reviews.
(In reply to Markos Chandras from comment #12) > (In reply to Tom Wijsman (TomWij) from comment #11) > > (In reply to Markos Chandras from comment #10) > > > - Workflow? Who has access? Only devs (members of the @gentoo team) and we > > > accept pull requests and then move them to tree? > > > > GH --> g-x86: Pull request, we review, we pull, we push to the Portage > > tree. > > g-x86 --> GH: Either developer or user brings tree changes to the > > overlay. > > > > Tracking differences between GH and g-x86 can be done using overlint; > > it is also possible to script up some syncing later on, so, if we get > > more > > attention than foreseen it should still be fairly scalable. > > > > All Gentoo devs can help, we need to encourage them to speak to us first. Yes, as Tom said. All Gentoo devs should have access if they are member of the gentoo github organization. We can also try to integrate unified diffs to the current main tree into travis.yml. What do you think? > > > > Something like this? Based on what mrueg has said and/or personal opinion. > > > Ok > > > > - Announcement? > > > > but I'm wondering whether it would be appropriate > > to also send a mail out to all non-Gentoo non-upstream e-mails in the > > metadata.xml files of the whole Portage tree? Maybe we could first set up a > > gentoo-dev-help or gentoo-proxy-maint ML for improving communication with > > most proxy maintainers? > > Please don't email all people in metadata. That would be rather annoying. We > can inform them gradually. and we don't need another ML for proxy-maint. We > can use github for reviews. ++ I think we should change/notify users via: - wiki project page - default welcome message for proxy-maintainer ebuilds - GMN - planet.gentoo.org - new bugs assigned to proxy-maint (for the first month) - IRC
(In reply to Manuel Rüger from comment #13) > (In reply to Markos Chandras from comment #12) > > (In reply to Tom Wijsman (TomWij) from comment #11) > > > (In reply to Markos Chandras from comment #10) > > > > - Workflow? Who has access? Only devs (members of the @gentoo team) and we > > > > accept pull requests and then move them to tree? > > > > > > GH --> g-x86: Pull request, we review, we pull, we push to the Portage > > > tree. > > > g-x86 --> GH: Either developer or user brings tree changes to the > > > overlay. > > > > > > Tracking differences between GH and g-x86 can be done using overlint; > > > it is also possible to script up some syncing later on, so, if we get > > > more > > > attention than foreseen it should still be fairly scalable. > > > > > > All Gentoo devs can help, we need to encourage them to speak to us first. > > Yes, as Tom said. All Gentoo devs should have access if they are member of > the gentoo github organization. > We can also try to integrate unified diffs to the current main tree into > travis.yml. What do you think? I have no idea how travis work so i can't comment on that.
(In reply to Markos Chandras from comment #12) > Please don't email all people in metadata. That would be rather annoying. We > can inform them gradually. and we don't need another ML for proxy-maint. We > can use github for reviews. Hmm, yeah, unsolicited mail could indeed not be welcome; was just wondering whether it was appropriate for others, if nobody else wants it then the other mediums should work out well. We'll then just rely on the news propagation. (In reply to Manuel Rüger from comment #13) > We can also try to integrate unified diffs to the current main tree into > travis.yml. What do you think? That output would be huge, don't you think so? Or do we really try to keep this at zero? I'm not sure how well that'll work out. If we plan to go for this, I suggest to do this after the repoman output and don't make it fail the build. Also, there might have been change in the Portage tree since the Travis output was generated; it could be useful for a quick check, but might not be reliable. (In reply to Markos Chandras from comment #14) > I have no idea how travis work so i can't comment on that. For most commits and/or pull requests, Travis uses a .travis.yml which contains instructions what Travis should do in a virtual container where you have root access. In the case of our overlay, this virtual container fetches Portage and the Portage tree and then does a repoman run over the entire overlay. The return status code of the repoman job determines if the Travis build succeeds or fails. See https://travis-ci.org/gentoo/proxy-maintainers for an example.
(In reply to Tom Wijsman (TomWij) from comment #11) > GH --> g-x86: Pull request, we review, we pull, we push to the Portage tree. > g-x86 --> GH: Either developer or user brings tree changes to the overlay. > > Tracking differences between GH and g-x86 can be done using overlint; > it is also possible to script up some syncing later on, so, if we get > more attention than foreseen it should still be fairly scalable. Do we want to have the overlay and g-x86 synchronized? I would rather expect ebuilds that are pushed to the tree to be removed from the overlay, not? What I usually do is remove from the overlay an hour after the g-x86 has been committed so that users who update their system always have the ebuild, either still as part of the overlay (because the g-x86 sync with rsync hasn't been done yet) or as g-x86.
(In reply to Sven Vermeulen from comment #16) > (In reply to Tom Wijsman (TomWij) from comment #11) > > GH --> g-x86: Pull request, we review, we pull, we push to the Portage tree. > > g-x86 --> GH: Either developer or user brings tree changes to the overlay. > > > > Tracking differences between GH and g-x86 can be done using overlint; > > it is also possible to script up some syncing later on, so, if we get > > more attention than foreseen it should still be fairly scalable. > > Do we want to have the overlay and g-x86 synchronized? I would rather expect > ebuilds that are pushed to the tree to be removed from the overlay, not? Definitely. The overlay is a staging area. As soon as you move them to tree, feel free to drop the ebuilds from the overlay
I am closing this as it seems that already has been set up properly now
