Hello all,
Short version:
if you have a bug that has more than 1 patch, PLEASE, keep the in the
apply order
Long version:
As you all know (I hope!), i've developed a system to test patches
online. When you're a librarian, it's easy to try a patch in a few clics.
However, if a bug has more than o
Hello koha-devel,
I just updated the 3.8 release process with the schedule/planning of the
release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8
Here it is:
March, 23th (1 month before the release) = feature freeze.
April, 6th = strong feature freeze, string freeze
April 20th = starting rel
Le 06/03/2012 17:03, Ian Walls a écrit :
> Paul,
Ian,
> Has the work on Shibboleth required a refactoring of C4/Auth?
I don't think so, it's made like CAS auth afaik.
> It's sorely needed.
rewritting Auth IS something needed, definetly, but that won't be
through Shibboleth.
--
Paul POULAIN
htt
Hi Paul,
What is the exact procedure? All patches submitted before March 23 or
signed-off before March 23 are candidates for the 3.8 release? If so, how do
we separate them easily from the patches submitted later? What is strong
feature freeze exactly here?
About the commits: I would suggest
Le 08/03/2012 14:36, Marcel de Rooy a écrit :
> Hi Paul,
Hi Marcel,
> What is the exact procedure?
> All patches submitted before March 23 or signed-off before March 23
are candidates for the 3.8 release?
> If so, how do we separate them easily from the patches submitted
later? What is strong feat
On Thu, Mar 08, 2012 at 02:02:12PM +0100, Paul Poulain wrote:
> Le 06/03/2012 17:03, Ian Walls a écrit :
> > Paul,
> Ian,
> > Has the work on Shibboleth required a refactoring of C4/Auth?
> I don't think so, it's made like CAS auth afaik.
I am very interesed in C4/Auth rewrite since it's... mess
On Mar 9, 2012 1:59 AM, "Paul Poulain" wrote:
>
> Hello koha-devel,
>
> I just updated the 3.8 release process with the schedule/planning of the
> release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8
>
> Here it is:
> March, 23th (1 month before the release) = feature freeze.
> April, 6th =
Le 08/03/2012 18:30, Chris Cormack a écrit :
> Doing it in one hit only makes this better if it is possible to have git
> blame ignore this commit.
I don't think it's possible.
> I just want to go on record as disagreeing with this plan. But happy to
> abide by community decision I just reserve
On Mar 9, 2012 6:41 AM, "Paul Poulain" wrote:
>
> Le 08/03/2012 18:30, Chris Cormack a écrit :
>
> > Doing it in one hit only makes this better if it is possible to have git
> > blame ignore this commit.
>
> I don't think it's possible.
>
> > I just want to go on record as disagreeing with this pl
2012/3/8 Chris Cormack
> My counter proposal is tidy as you go. Fix code as you touch it.
>
> With vim (and other editors) you can easily tidy a block, doing that as
> code is changed would be my preference.
>
I'd prefer a "pay-as-you-go" approach as well. We could simply require all
work to be
2012/3/8 Chris Cormack
> Doing it in one hit only makes this better if it is possible to have git
> blame ignore this commit.
>
>
>
Interestingly enough there seems to have been a patch submitted to GIT to
do just this sort of thing, but it got dropped along the way:
http://git.661346.n2.nabble.
I agree with Chris C. and Chris N. - I think what we would win does not
outweigh the loss of history.
Katrin
-Ursprüngliche Nachricht-
Von: koha-devel-boun...@lists.koha-community.org im Auftrag von Chris
Nighswonger
Gesendet: Do 08.03.2012 19:26
An: Chris Cormack
Cc: koha-devel@lists.k
Thank you, Nick!
We're hosted by Equinox, so getting that php code in place would take
a bit of extra work for us.
I'm now thinking that we may better off just using a custom field for
this purpose.
If we stick w/ Amazon, their ASIN would be the best way to go. This is
the ISBN for most books, b
+1 to a gradual perltidy
2012/3/8 Fischer, Katrin
> **
>
> I agree with Chris C. and Chris N. - I think what we would win does not
> outweigh the loss of history.
>
> Katrin
>
> -Ursprüngliche Nachricht-
> Von: koha-devel-boun...@lists.koha-community.org im Auftrag von Chris
> Nighswonge
Doing a large updating commit does not cost us any history. It just counts
as an "update" to the code, even though none of the logic has changed.
This change would alter SLOC counts and such, messing with our statistics,
since we only want to measure intellectually significant contributions
(tidyi
* Ian Walls (koha.sek...@gmail.com) wrote:
>Doing a large updating commit does not cost us any history.A It just
>counts as an "update" to the code, even though none of the logic has
>changed.A A This change would alter SLOC counts and such, messing with
>our statistics, since we
Chris,
Right, with the colossal commit option, one could have to
1. Know the commit id of the change
2. git blame something
3. if that id comes up, then git checkout -b temporary
<>^
4. git blame again
The more history we pile on top of that, the longer it'll take git to
update t
Hi Paul, we have been caught off-guard by this schedule.
We have a lot of stuff to submit but March 23rd is too little time. If we
have 2 more weeks, we can get good stuff included. Possible?
Thanks,
Savitra Sirohi
Nucsoft OSS Labs
http://www.osslabs.biz
On Thu, Mar 8, 2012 at 6:29 PM, Paul Poul
18 matches
Mail list logo
