on the todo list for a long time, as well as
review systems such as gerrit.
It is non trivial to implement
Other than the git repository size requiring a huge initial clone, it's
very easy to do. And yes, I've read all the headaches on the Gentoo
mailing lists about the git migration.
Also
tree and contributors sending patches to them or to official
package maintainers making the first review before they do the merge and
submit to the main maintainers. Something like the kernel with
the main maintainers, the lieutenants and open contributors.
Git workflow has been on the todo
g/responding to review) so you are forced to do everything over
the slow WebUI.
If you care at all about the codereview aspects, I would recommend gerrit
or phabricator. Both have cli utilities (git-review and arcanist) and while
some claim they are ugly (heard that one especially about gerrit) th
. git-push and
git-send-email are one shoot simple commands to get things done. Having
to open the web browser, connect to bugzilla, attach the patch and
comment online is too much busy.
With Gentoo, you have to find a mentor, officially call for
being a member, success the online tests, keep
benign in performing a solid code review ymmv.
If you want to work on writing patches for it, then it doesn't make as
much sense.
Some times code changes rarely. Like minicom. There is no GIT
or repository activity that amounts to anything. In general,
with active projects, you are right. Much
nless removing everything at lower
depths will remove the change records.
> ...and of course you'll need to set up a cron job or something to go
> cleaning up past history (you never NEED more than the last commit). If you
> browse the online git repo you can see about how many commits
On Tue, Jun 19, 2018 at 11:15 AM Ian Zimmerman wrote:
>
> On 2018-06-18 11:34, Rich Freeman wrote:
>
> > Oh, the other tool you'll want to use is etckeeper to manage /etc in a
> > git repo and auto-commit changes/etc with package manager hooks. That
> > is a cross-dist
Hello,
I'm looking for some EAPI-6 examples or ebuild templates to
to review.
Is there a simple way to parse the portage tree for EAPI=6 examples
regardless if they are testing, stable or still just beta in a git
repo somewhere? Maybe a particular dev has already revised a group
of ebuilds
On Mon, 21 Mar 2016 15:50:02 +
James wrote -
> Hello,
>
> I'm looking for some EAPI-6 examples or ebuild templates to
> to review.
>
>
> Is there a simple way to parse the portage tree for EAPI=6 examples
> regardless if they are testing, stable or still j
On Thu, Nov 27, 2014 at 2:04 AM, Rich Freeman ri...@gentoo.org wrote:
On Wed, Nov 26, 2014 at 12:29 PM, hasufell hasuf...@gentoo.org wrote:
I don't know of literally any big project except gentoo that still does
not _require_ a review workflow. Git would be the perfect excuse to
make it happen
ou care at all about the codereview aspects, I would recommend gerrit
> or phabricator. Both have cli utilities (git-review and arcanist) and
> while some claim they are ugly (heard that one especially about
> gerrit) they are 100x more practical.
> If you only care about having a r
you browse the
online git repo you can see about how many commits there are in a day
and estimate how many you want based on how many days you want.
Also, this value only matters for the first sync. After that portage
currently doesn't try to discard past commits, and it will always
fetch all
that still does
not _require_ a review workflow. Git would be the perfect excuse to
make it happen, but that's something people have to agree on.
Gentoo is a release-less distro. First, most projects that aren't
distros aren't really comparable to a linux distro because most
projects represent
, start
working on it, completely ignoring the nature of the issues brought up.
I don't know of literally any big project except gentoo that still does
not _require_ a review workflow. Git would be the perfect excuse to
make it happen, but that's something people have to agree on.
Instead we
interface og the bugzilla thing.
Git workflow has been on the todo list for a long time, as well as
review systems such as gerrit.
It is non trivial to implement
Other than the git repository size requiring a huge initial clone, it's
very easy to do.
Let's not make this yet another git migration
another command to run, just like git. As others have pointed out, the use
of
a bug-tracker is important in terms of managing the process. That still stands.
Git workflow has been on the todo list for a long time, as well as
review systems such as gerrit.
It is non trivial to implement
On 08/02/2013 01:16 PM, Nicolas Sebrecht wrote:
And if you cba to review the basics, stuff most users know, or can find out
easily,
what makes you think you're cut out to be a developer?
Please note I'm not discussing any technical ability you may or may not have
with
bash, ebuilds
Le 2 août 2013 13:59, hasufell hasuf...@gentoo.org a écrit :
On 08/02/2013 01:16 PM, Nicolas Sebrecht wrote:
And if you cba to review the basics, stuff most users know, or can
find out easily,
what makes you think you're cut out to be a developer?
Please note I'm not discussing any
required.
It is done ahead so it won't be too late, as you say... eudev is
minimal patch set over systemd.
Someone should have forked the logind as well ahead, so the whole
gmone discussion was irrelevant.
It's not too late to fork logind in anyway, it's down to 204 in git and
then review
hard, but not stepping down
In addition, this model requires a workflow that is long overdue,
including proper VCS like git or mercurial and a review culture. None of
this happens on a larger scale. Instead we are stuck with tools like
bugzilla for ebuild reviews and push our happy ebuilds to the CVS
, the whole review process is broken and the contribution process is
broken too.
About that, there's no other way than break the whole recruiting process
and change of tools. Have your core team handle git repositories and let
others request pull or send patches like almost all the other open
source
devs are asked to work with old tools like bugzilla. So
yes, the whole review process is broken and the contribution process is
broken too.
About that, there's no other way than break the whole recruiting process
and change of tools. Have your core team handle git repositories and let
others
something, not just complaints about all the
great stuff that could get done if somebody cared enough to even try.
In addition, this model requires a workflow that is long overdue,
including proper VCS like git or mercurial and a review culture. None of
this happens on a larger scale. Instead we
to this thread confort me in my opinion.
Please, take the critism the constructive way. The topic is not about me.
And if you cba to review the basics, stuff most users know, or can find out
easily,
what makes you think you're cut out to be a developer?
Please note I'm not discussing any technical
r this distro, but, close
examination, at least for me, is highly warranted.
So what commands do I run (git style) to see the history of the relevant
build/release dates for openssl? The changelog seems incomplete
> Upstream really dropped the ball on this. When I'm updating packages
> I
ead of me on practical gcc-5 experiments with offloading and other
> new features.
>
> You did not list your second reference. Where I can I get/git your
> compiler and some brief suggestions on taking it for a test drive.
>
> I'm not much interested in the Intel simulator, atm. I
26 matches
Mail list logo
