Bo Peng ben@gmail.com writes:
Rember the claim put forward a couple of posts ago: IMHO, we do not
have enough manpower to use the git model.
Which is just FUD.
| Linux/core is huge and there are many components and subcomponents.
| Groups of people work on these subcomponents and submit
Bo Peng ben@gmail.com writes:
LyX is a totally different story. LyX is a much smaller project. If
two major features are developed separately, there are high
probability of conflict.
Did we ever had that situation?
| Then what happened to XML and other branches?
You really think that
Pavel Sanda sa...@lyx.org writes:
| Lars Gullik Bj?nnes wrote:
| i can continue with the problems for updating from the main tree compared
| to svn if you like (these are not to prove git is something worse, but
| to discard your claims that git know everything what svn plus something
| more
Lars Gullik Bj?nnes wrote:
Also since I find git-svn such a good solution I think there should be
an official git repo that can be used to base a git clone on, and a
cookbook on how to setup this repo for git-svn-svn interaction.
if the intention was not to destroy svn i have no problem with
What has linux kernel development to do with lyx and its possible
usage
of git?
I guess one can say with confidence that the way git was designed is
related to
linux development process.
If you feel that your world is shattered because git commit dost not
also push to the subversion
Bo Peng writes:
>> Rember the claim put forward a couple of posts ago: "IMHO, we do not
>> have enough manpower to use the git model."
>>
>> Which is just FUD.
>
| Linux/core is huge and there are many components and subcomponents.
| Groups of people work on these
Bo Peng writes:
>>> LyX is a totally different story. LyX is a much smaller project. If
>>> two major features are developed separately, there are high
>>> probability of conflict.
>>
>> Did we ever had that situation?
>
| Then what happened to XML and other branches?
You
Pavel Sanda writes:
| Lars Gullik Bj?nnes wrote:
>> | i can continue with the problems for updating from the main tree compared
>> | to svn if you like (these are not to prove git is something worse, but
>> | to discard your claims that git know everything what svn plus something
Lars Gullik Bj?nnes wrote:
> Also since I find git-svn such a good solution I think there should be
> an official git repo that can be used to base a git clone on, and a
> cookbook on how to setup this repo for git-svn<->svn interaction.
if the intention was not to destroy svn i have no problem
What has linux kernel development to do with lyx and its possible
usage
of git?
I guess one can say with confidence that the way git was designed is
related to
linux development process.
If you feel that your world is shattered because git commit dost not
also push to the subversion
Pavel Sanda sa...@lyx.org writes:
| Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
| to me this depends on what kind of development model you use and given
| the number of lyx
Jean-Marc Lasgouttes lasgout...@lyx.org writes:
| Pavel Sanda sa...@lyx.org writes:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of
Lars Gullik Bj?nnes wrote:
git supports it as well
it does, but not as well.
pavel
Bo Peng ben@gmail.com writes:
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
| This is not that useful if we keep the one developer - one feature
| developing model. Right now, when you work on a
Abdelrazak Younes you...@lyx.org writes:
| Bo Peng wrote:
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right
Abdelrazak Younes you...@lyx.org writes:
| Jean-Marc Lasgouttes wrote:
Pavel Sanda sa...@lyx.org writes:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is
a different mental model indeed, but not not a loss of function
IMHO.
to me
Lars Gullik Bj?nnes wrote:
This is just bull. You are creating a model that is not optimal and
saying this is due to git.
| IMHO, we do not have enough manpower to use the git model.
There is no such thing as the git model.
for example i would like to hear how you directly commit to the
On Wed, 4 Mar 2009, Lars Gullik Bjonnes wrote:
| using git in the day job a while ago. The bright side is that there
| are lots of helpful people around ;-)
you is the general you, and personally is the, well, person you.
So, you, as in Andre, already got experience with git ,great.
(I would
Lars Gullik Bjønnes a écrit :
| For users that (try to) help us find bugs (and we need these people),
| saying it did work at r1234 is easier that giving a hash (isn't this
| how a git state is defined? here I show my ignorance about it).
I do not quite get that... who is it easer to say r1234
On Wed, 4 Mar 2009, Lars Gullik Bjønnes wrote:
I belive github might be a good place for the repo and the wiki (other
can judge better than me). And do we really need the regular web space
if the wiki is good?
What's the'regular web space'? Does that mean the web pages?
/C
--
Christian
Pavel Sanda sa...@lyx.org writes:
| Lars Gullik Bj?nnes wrote:
This is just bull. You are creating a model that is not optimal and
saying this is due to git.
| IMHO, we do not have enough manpower to use the git model.
There is no such thing as the git model.
| for example i would like
Christian Ridderström
christian.ridderst...@gmail.com writes:
| On Wed, 4 Mar 2009, Lars Gullik Bjønnes wrote:
I belive github might be a good place for the repo and the wiki
(other can judge better than me). And do we really need the regular
web space if the wiki is good?
| What's
On Sat, 7 Mar 2009, Jean-Marc Lasgouttes wrote:
I do not quite get that... who is it easer to say r1234 instead of
23ae45?
I like the fact that revision numbers form an increasing timeline.
I guess one advantage with r1234 is if you manually bisect between
revisions to see when a bug
On Thu, 5 Mar 2009, Lars Gullik Bjønnes wrote:
I'd love to get rid of bugzilla anyway... it is a superhassle to
upgrade...
Is it practical to stop using bugzilla if we already have many references
to issues in bugzilla, or to changesets or whatever?
I think this was asked elsewhere by
On Sat, 7 Mar 2009, Lars Gullik Bjønnes wrote:
| On Wed, 4 Mar 2009, Lars Gullik Bjønnes wrote:
I belive github might be a good place for the repo and the wiki
(other can judge better than me). And do we really need the regular
web space if the wiki is good?
| What's the'regular web
Lars Gullik Bj?nnes wrote:
| IMHO, we do not have enough manpower to use the git model.
There is no such thing as the git model.
| for example i would like to hear how you directly commit to the main
| repository - some _one_ command equivalent to svn ci.
why is it bad to use _two_?
Christian Ridderström wrote:
On Sat, 7 Mar 2009, Jean-Marc Lasgouttes wrote:
I do not quite get that... who is it easer to say r1234 instead of
23ae45?
I like the fact that revision numbers form an increasing timeline.
I guess one advantage with r1234 is if you manually bisect between
Pavel Sanda sa...@lyx.org writes:
| Lars Gullik Bj?nnes wrote:
| IMHO, we do not have enough manpower to use the git model.
There is no such thing as the git model.
| for example i would like to hear how you directly commit to the main
| repository - some _one_ command equivalent to
Lars Gullik Bj?nnes wrote:
Jean-Marc Lasgouttes lasgout...@lyx.org writes:
| Pavel Sanda sa...@lyx.org writes:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me
Rember the claim put forward a couple of posts ago: IMHO, we do not
have enough manpower to use the git model.
Which is just FUD.
Linux/core is huge and there are many components and subcomponents.
Groups of people work on these subcomponents and submit their tested
patches to their
On Thu, 5 Mar 2009, Lars Gullik Bjønnes wrote:
main ftp is not on aussie
malinglist (mainly) is not on aussie
dns servers is not on aussie
To start a list of services. I thought I'd e-mailed that earlier, but it
seems lost.
/C
--
Christian Ridderström Mobile:
Lars Gullik Bj?nnes wrote:
| i can continue with the problems for updating from the main tree compared
| to svn if you like (these are not to prove git is something worse, but
| to discard your claims that git know everything what svn plus something
| more
| - two different tools for two
On Sat, 7 Mar 2009, Christian Ridderström wrote:
Here's an updated list of services. Should probably put this on a wiki
page eventually. Please add/comment about stuff I've forgotten.
!!! Services related to LyX and LyX development.
* Web site http://www.lyx.org On aussie.
* Wiki
On Sat, Mar 07, 2009 at 11:39:07AM -0600, Bo Peng wrote:
LyX is a totally different story. LyX is a much smaller project. If
two major features are developed separately, there are high
probability of conflict.
Did we ever had that situation?
Subversion does this perfectly because everyone is
LyX is a totally different story. LyX is a much smaller project. If
two major features are developed separately, there are high
probability of conflict.
Did we ever had that situation?
Then what happened to XML and other branches? LyX is sufficiently
small so that you can not leave trunk
On 07/03/2009 18:57, Pavel Sanda wrote:
Lars Gullik Bj?nnes wrote:
| i can continue with the problems for updating from the main tree compared
| to svn if you like (these are not to prove git is something worse, but
| to discard your claims that git know everything what svn plus something
|
Pavel Sanda writes:
| Abdelrazak Younes wrote:
>> As for refering to a svn revision instead of a git branch, this is a
>> different mental model indeed, but not not a loss of function IMHO.
>
| to me this depends on what kind of development model you use and given
| the number of
Jean-Marc Lasgouttes writes:
| Pavel Sanda writes:
>
>> Abdelrazak Younes wrote:
>>> As for refering to a svn revision instead of a git branch, this is a
>>> different mental model indeed, but not not a loss of function IMHO.
>>
>> to me this depends on what
Lars Gullik Bj?nnes wrote:
> git supports it as well
it does, but not as well.
pavel
Bo Peng writes:
>> Not quite true. In a git world, a bug fixing would _always_ happen in a
>> specific branch and be merged to the main repo when it's done;
>
| This is not that useful if we keep the one developer - one feature
| developing model. Right now, when you work on a
Abdelrazak Younes writes:
| Bo Peng wrote:
>>> Not quite true. In a git world, a bug fixing would _always_ happen in a
>>> specific branch and be merged to the main repo when it's done;
>>>
>>
>> This is not that useful if we keep the one developer - one feature
>>
Abdelrazak Younes writes:
| Jean-Marc Lasgouttes wrote:
>> Pavel Sanda writes:
>>
>>
>>> Abdelrazak Younes wrote:
>>>
As for refering to a svn revision instead of a git branch, this is
a different mental model indeed, but not not a loss of
Lars Gullik Bj?nnes wrote:
> This is just bull. You are creating a model that is not optimal and
> saying this is due to git.
>
> | IMHO, we do not have enough manpower to use the git model.
>
> There is no such thing as the "git model".
for example i would like to hear how you directly commit
On Wed, 4 Mar 2009, Lars Gullik Bjonnes wrote:
| using git in the day job a while ago. The bright side is that there
| are lots of helpful people around ;-)
you is the general you, and personally is the, well, person you.
So, you, as in Andre, already got experience with git ,great.
(I would
Lars Gullik Bjønnes a écrit :
| For users that (try to) help us find bugs (and we need these people),
| saying "it did work at r1234" is easier that giving a hash (isn't this
| how a git state is defined? here I show my ignorance about it).
I do not quite get that... who is it easer to say
On Wed, 4 Mar 2009, Lars Gullik Bjønnes wrote:
I belive github might be a good place for the repo and the wiki (other
can judge better than me). And do we really need the regular web space
if the wiki is good?
What's the'regular web space'? Does that mean the web pages?
/C
--
Christian
Pavel Sanda writes:
| Lars Gullik Bj?nnes wrote:
>> This is just bull. You are creating a model that is not optimal and
>> saying this is due to git.
>>
>> | IMHO, we do not have enough manpower to use the git model.
>>
>> There is no such thing as the "git model".
>
| for
Christian Ridderström
writes:
| On Wed, 4 Mar 2009, Lars Gullik Bjønnes wrote:
>
>> I belive github might be a good place for the repo and the wiki
>> (other can judge better than me). And do we really need the regular
>> web space if the wiki is good?
>
| What's
On Sat, 7 Mar 2009, Jean-Marc Lasgouttes wrote:
I do not quite get that... who is it easer to say r1234 instead of
23ae45?
I like the fact that revision numbers form an increasing timeline.
I guess one advantage with r1234 is if you manually bisect between
revisions to see when a bug
On Thu, 5 Mar 2009, Lars Gullik Bjønnes wrote:
I'd love to get rid of bugzilla anyway... it is a superhassle to
upgrade...
Is it practical to stop using bugzilla if we already have many references
to issues in bugzilla, or to changesets or whatever?
I think this was asked elsewhere by
On Sat, 7 Mar 2009, Lars Gullik Bjønnes wrote:
| On Wed, 4 Mar 2009, Lars Gullik Bjønnes wrote:
I belive github might be a good place for the repo and the wiki
(other can judge better than me). And do we really need the regular
web space if the wiki is good?
| What's the'regular web
Lars Gullik Bj?nnes wrote:
> >> | IMHO, we do not have enough manpower to use the git model.
> >>
> >> There is no such thing as the "git model".
> >
> | for example i would like to hear how you directly commit to the main
> | repository - some _one_ command equivalent to svn ci.
>
> why is it
Christian Ridderström wrote:
> On Sat, 7 Mar 2009, Jean-Marc Lasgouttes wrote:
>
>>> I do not quite get that... who is it easer to say r1234 instead of
>>> 23ae45?
>>
>> I like the fact that revision numbers form an increasing timeline.
>
> I guess one advantage with r1234 is if you manually
Pavel Sanda writes:
| Lars Gullik Bj?nnes wrote:
>> >> | IMHO, we do not have enough manpower to use the git model.
>> >>
>> >> There is no such thing as the "git model".
>> >
>> | for example i would like to hear how you directly commit to the main
>> | repository - some _one_
Lars Gullik Bj?nnes wrote:
> Jean-Marc Lasgouttes writes:
>
> | Pavel Sanda writes:
> >
> >> Abdelrazak Younes wrote:
> >>> As for refering to a svn revision instead of a git branch, this is a
> >>> different mental model indeed, but not not a loss of
> Rember the claim put forward a couple of posts ago: "IMHO, we do not
> have enough manpower to use the git model."
>
> Which is just FUD.
Linux/core is huge and there are many components and subcomponents.
Groups of people work on these subcomponents and submit their tested
patches to their
On Thu, 5 Mar 2009, Lars Gullik Bjønnes wrote:
main ftp is not on aussie
malinglist (mainly) is not on aussie
dns servers is not on aussie
To start a list of services. I thought I'd e-mailed that earlier, but it
seems lost.
/C
--
Christian Ridderström Mobile:
Lars Gullik Bj?nnes wrote:
> | i can continue with the problems for updating from the main tree compared
> | to svn if you like (these are not to prove git is something worse, but
> | to discard your claims that git know everything what svn plus something
> | more
> | - two different tools for two
On Sat, 7 Mar 2009, Christian Ridderström wrote:
Here's an updated list of services. Should probably put this on a wiki
page eventually. Please add/comment about stuff I've forgotten.
!!! Services related to LyX and LyX development.
* Web site http://www.lyx.org On aussie.
* Wiki
On Sat, Mar 07, 2009 at 11:39:07AM -0600, Bo Peng wrote:
> LyX is a totally different story. LyX is a much smaller project. If
> two major features are developed separately, there are high
> probability of conflict.
Did we ever had that situation?
> Subversion does this perfectly because
>> LyX is a totally different story. LyX is a much smaller project. If
>> two major features are developed separately, there are high
>> probability of conflict.
>
> Did we ever had that situation?
Then what happened to XML and other branches? LyX is sufficiently
small so that you can not leave
On 07/03/2009 18:57, Pavel Sanda wrote:
Lars Gullik Bj?nnes wrote:
| i can continue with the problems for updating from the main tree compared
| to svn if you like (these are not to prove git is something worse, but
| to discard your claims that git know everything what svn plus something
|
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and given
the number of lyx developers and the way we proceed i think
Pavel Sanda wrote:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and given
the number of lyx developers and
Abdelrazak Younes wrote:
to me this depends on what kind of development model you use and given
the number of lyx developers and the way we proceed i think the
centralized
way is the better one.
So the LyX devs are a bunch of old, lazy and stubborn guys?
somehow i fail to follow your
Pavel Sanda sa...@lyx.org writes:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and given
the number of lyx
Jean-Marc Lasgouttes wrote:
From what I understand about git, it is lost in the new world.
yes
pavel
Jean-Marc Lasgouttes wrote:
Pavel Sanda sa...@lyx.org writes:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right now, when you work on a feature, all others
are forced to check it
Bo Peng wrote:
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right now, when you work on a feature, all others
are
Abdelrazak Younes wrote:
IMHO, we do not have enough manpower to use the git model.
Well, we are not _forced_ to use only one merging per feature, this can be
split into logical steps (at the intiative of the developer).
but this split is what makes revision numbers useful. i just see
Abdelrazak Younes you...@lyx.org writes:
Anyway, I'll use whatever is decided...
Really? I thought you were an old, lazy and stubborn guy...
Lazy is the operative word. I am not contributing that much, so I cannot
complain. At worst I'll send patches to the list so that others apply
them :)
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes you...@lyx.org writes:
Anyway, I'll use whatever is decided...
Really? I thought you were an old, lazy and stubborn guy...
Lazy is the operative word. I am not contributing that much, so I cannot
complain. At worst I'll send
On Fri, Mar 06, 2009 at 07:29:54AM -0600, Bo Peng wrote:
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right now,
Andre Poenitz wrote:
On Fri, Mar 06, 2009 at 07:29:54AM -0600, Bo Peng wrote:
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
On Fri, Mar 06, 2009 at 06:52:41PM +0100, Pavel Sanda wrote:
Andre Poenitz wrote:
the same way as LyX svn trunk is currently treated. You can push your
work pretty much in the same chunks as you would today.
but the flamed point was not about _pushing_. rather it was about commit
Abdelrazak Younes wrote:
> As for refering to a svn revision instead of a git branch, this is a
> different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and given
the number of lyx developers and the way we proceed i think
Pavel Sanda wrote:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and given
the number of lyx developers and
Abdelrazak Younes wrote:
>> to me this depends on what kind of development model you use and given
>> the number of lyx developers and the way we proceed i think the
>> centralized
>> way is the better one.
>>
>
> So the LyX devs are a bunch of old, lazy and stubborn guys?
somehow i fail to
Pavel Sanda writes:
> Abdelrazak Younes wrote:
>> As for refering to a svn revision instead of a git branch, this is a
>> different mental model indeed, but not not a loss of function IMHO.
>
> to me this depends on what kind of development model you use and given
> the number of
Jean-Marc Lasgouttes wrote:
> From what I understand about git, it is lost in the new world.
yes
pavel
Jean-Marc Lasgouttes wrote:
Pavel Sanda writes:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development
> Not quite true. In a git world, a bug fixing would _always_ happen in a
> specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right now, when you work on a feature, all others
are forced to check it
Bo Peng wrote:
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right now, when you work on a feature, all others
are
Abdelrazak Younes wrote:
>> IMHO, we do not have enough manpower to use the git model.
>>
>
> Well, we are not _forced_ to use only one merging per feature, this can be
> split into logical steps (at the intiative of the developer).
but this split is what makes revision numbers useful. i just
Abdelrazak Younes writes:
>> Anyway, I'll use whatever is decided...
>>
> Really? I thought you were an old, lazy and stubborn guy...
Lazy is the operative word. I am not contributing that much, so I cannot
complain. At worst I'll send patches to the list so that others apply
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
Anyway, I'll use whatever is decided...
Really? I thought you were an old, lazy and stubborn guy...
Lazy is the operative word. I am not contributing that much, so I cannot
complain. At worst I'll send
On Fri, Mar 06, 2009 at 07:29:54AM -0600, Bo Peng wrote:
> > Not quite true. In a git world, a bug fixing would _always_ happen in a
> > specific branch and be merged to the main repo when it's done;
>
> This is not that useful if we keep the one developer - one feature
> developing model. Right
Andre Poenitz wrote:
> On Fri, Mar 06, 2009 at 07:29:54AM -0600, Bo Peng wrote:
> > > Not quite true. In a git world, a bug fixing would _always_ happen in a
> > > specific branch and be merged to the main repo when it's done;
> >
> > This is not that useful if we keep the one developer - one
On Fri, Mar 06, 2009 at 06:52:41PM +0100, Pavel Sanda wrote:
> Andre Poenitz wrote:
> > the same way as LyX svn trunk is currently treated. You can push your
> > work pretty much in the same chunks as you would today.
>
> but the flamed point was not about _pushing_. rather it was about commit
>
Pavel Sanda sa...@lyx.org writes:
| Lars Gullik Bj?nnes wrote:
If there are interest I'll try to setup a git tree that you can clone and
set
up as a git-svn tree. (I'll even write up a wiki page to explain briefly
how
to do that.)
| this is already done on git.or.cz, though not
lar...@lyx.org (Lars Gullik Bjønnes) writes:
I'd like you to name some... I only know of a few and as of current they
seem to be of very little importance. I belive the benefit of not having
to handle the daily (or yearly) churn of chores is a really good thing.
Setting up automatic generation
Peter Kümmel syntheti...@gmx.net writes:
What about a 'evaluation'? Possible candidates are:
ww.sf.net
www.assembla.com
github.com
repo.or.cz
savannah, launchpad, tigris, or more generally
http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities
What we need to look at
Jean-Marc Lasgouttes lasgout...@lyx.org writes:
What we need to look at is the possibility to get all our data back if
we want to leave. Whasn't that a problem with sf.net?
In this respect, I'd favor hosting from free software projects like
alioth (debian), launchpad (ubuntu,although this is a
Jean-Marc Lasgouttes lasgout...@lyx.org writes:
| Peter Kümmel syntheti...@gmx.net writes:
What about a 'evaluation'? Possible candidates are:
ww.sf.net
www.assembla.com
github.com
repo.or.cz
| savannah, launchpad, tigris, or more generally
|
Jean-Marc Lasgouttes lasgout...@lyx.org writes:
| Jean-Marc Lasgouttes lasgout...@lyx.org writes:
What we need to look at is the possibility to get all our data back if
we want to leave. Whasn't that a problem with sf.net?
| In this respect, I'd favor hosting from free software projects like
|
lar...@gullik.org (Lars Gullik Bjønnes) writes:
What do you mean by get all our data back? I do not quite understand
how that can be a problem
Have access to our raw svn/git data to host it else where (but this is
probably moot with git). Have access to our bug database data to do
whatever we
Thursday 5 March 2009, 11:06 Lars Gullik Bjønnes wrote:
I took a look at sf.net and problems _may_ be:
...
- non developers cannot attach patches/files to bugs
http://sourceforge.net/tracker/?func=detailatid=21aid=2568036gro
up_id=1)!
Non-developers are able to create a new item in the
On 2009-03-04, Peter Kümmel wrote:
Lars Gullik Bjønnes wrote:
Bo Peng ben@gmail.com writes:
The bug database might be a problem...
| I know that many people dislike sourceforge but sourceforge supports
| pmwiki (our web), trac, and some project and bug tracking systems...
|
On Thu, Mar 05, 2009 at 12:22:58AM +0100, Lars Gullik Bj?nnes wrote:
Hi,
| I need to upgrade that server to Centos 5.2, but once that's done
You are aware that Centos 5.3 will be out in a couple of weeks?
In almost all cases that will be a rather smooth upgrade. I've some RHEL 5
here
1 - 100 of 222 matches
Mail list logo